Job Interview Advice for Junior Developers

I know a lot of senior developers will be moving with the current round of layoffs, but this is also a good time for less experienced developers to move into the disrupted spaces. There are slightly more elephant traps at interview time for junior devs, as they are seen as more of a risk. Senior devs can depend on raw experience and word of mouth. The biggest perceived problem with juniors is their inability to place their experience in context, and that naturally melts away after a few years. So this post focuses more on what juniors should look for when chasing software engineering and similar roles.

Like most people in their late career, I’ve been on both sides of the line — whether traveling across the city to spot a missing semicolon in a test, organizing interviews or rifling through CVs. While the purpose hasn’t changed, the industry is far more turbulent now. I’m not going to talk about the obvious. Yes, do some code katas if you don’t regularly code on demand, and yes, do your homework on the company or startup you are seeing. Find out how many stages the interview process has and prepare for the behavioral and technical parts.

Getting an interview in the first place will involve luck with the timing — luck you can improve by spending more time advertising yourself. But bear this in mind: With companies now pivoting, junior devs with a basic grounding may seem like a better value bet than pricier seniors with skills in an area that might not be central by next year. If you have a foot in another industry completely, you might also be much more interesting. Use your CV to paint an intriguing picture of yourself.

The Process

Don’t read too much into any one interview procedure — it may well be new, and the people doing it might be quite unfamiliar with it. In general, the interviewer is interested in how you express what you know, not what you don’t know. I’ve certainly met hard exceptions to this, but that is out of your hands. What is of value is your ability to separate what you do from the utility it offers.

I’m sorry if this sounds like Nietzsche, but self-knowledge is vital. Think about what you have experienced across the whole spectrum of development — from design, planning meetings, source code, repository use, testing, build scripts, deployment and observability. You may well be invited to comment on or question the process that the company uses. On the one hand, if you think you have been exposed to something more detailed than what they are using, say so. On the other hand, show interest in an area that you don’t know but would like to know more about.

Coding Tests

Deep down, everyone realizes that most coding tests are too artificial to be a dependable guide. But they do act as valuable filter for teams looking for talent. Good managers can pick up on your level of experience without seeing you code, even from the way you talk about problems. Practical enthusiasm is always welcome; staid cynicism may also be acceptable — know your audience. If you had to do a code exercise before the interview, you should expect to talk about how you did it. Did you go for simplicity or efficiency? Try not to harrumph if you are asked to write Fizzbuzz yet again — screening is screening. Comply and move on.

I know candidates do complain that their open source work is often downplayed in terms of valid experience; this is just a reflection on everyone’s different attitude to work. It is probably wiser to treat coding done outside of a paid job as part of your total experience, as opposed to a valuable subsection on its own.

Numbers

Real-world figures and estimations are often used to quiz applicants. I remember one consultancy firm made everyone do a full comprehension test, partly to check English skills, but also partly to ensure the candidates’ understanding of basic business terms. If you read something like the Economist magazine, you will pick up a clear way to understand and express business terms without having to sacrifice your soul to Mammon. You are not paid to write code for the sake of it; you do need to connect it to the business at any level of employment. Common estimation questions such as “how many trees are there?” are entirely designed to make sure you can apply structured reasoning and recognize the validity of your own answer. Naturally, questions may well be more aligned with engineering issues.

In a related manner, try to have some idea about what financial gains were made by a project you were on. I know this feels icky for some and often completely obscure. Just try to throw around a few solid facts and figures.

Behind the Faces

Remember the audience you are talking to. Human resources personnel are very different to the dev guy sitting in the interview with them. You won’t be working with anyone in HR, but they are the gatekeepers. In smaller outfits, there will probably be a manager type and a dev guy. It doesn’t hurt to empathize with how their views differ.

Make sure you are comfortable with all the parts of the agile development cycle, not just the bits your team happened to pick up in your last project. I have never used pull requests, but they are de rigueur in may places. Similarly code reviews. Retrospectives might seem pointless to you, but how else do you improve a process? Don’t assume that what your team called DevOps or Kanban is exactly the same as what everyone else does. One of the biggest snags in an interview — I think the most common — is when the interviewee shows little enthusiasm for an aspect of development the interviewer happens to thinks is important. Your negative hot take on a mainstream process, especially without experience weighing in behind you, may well be seen as a sign of rigidity.

Larger companies will generally use some older technologies that they treat as more unmovable than you might, or they might believe a change to something more modern would not be impactful. Typical would be poorly managed relational databases or rusty Microsoft solutions. This might annoy you, but it might truly be peripheral.

Your Skills

Exclusive mastery of a single language is usually considered slightly odd, especially if you show little enthusiasm for any others. Even if the company states they “only use Rust,” that doesn’t mean the person interviewing you has only ever used Rust, or thinks it is marvelous. At least be aware of the strengths and weaknesses of your favored tools; by all means show you are a fan, but don’t be a cultist.

When the interviewer asks how you would tackle a problem, don’t forget you will be working in or with a team, and possibly within a corporate matrix. So responding “I would go and do this” is fine in theory, and that is certainly how things work on the bridge of the Starship Enterprise. But in an actual company, you take tasks, talk with product managers, or at the very least start a thread on Slack. Does the company even give you ready access to those tools you think you will need to solve the problem?

Culture and Contacts

Frequently an interviewer will know someone from where you worked; don’t be afraid to touch base on shared colleague contacts. Even the smallest detail about people can satisfy quite a lot of trust issues — it proves you were there and aware. Laying out a slightly edgy opinion may be unwise, but it proves you can be vulnerable and yet share a little. If you are rude about a good friend of the interviewer, they are more likely to just laugh it off — pretending you can’t remember someone might seem respectful, but also a bit closed off. Are you really taking notice of who is around you?

An interview is a very good time to check the culture of the company as well as the work. Remember, a project is temporary whereas culture probably won’t change. Don’t be afraid of asking questions like “I’m Muslim, where can I pray?” or making observations like “I notice the workplace is very quiet.” Yes, interviewers are comfortable employing people like themselves, but they will thank you for showing them any blind spots. The remote-vs.-office debate is ongoing for most organizations, so don’t assume that the current strategy is somehow the last word on the matter.

Finally, think of yourself as a potential crew member on a pirate ship; you’ve done a bit of hoisting the mainsail, firing the cannons and checking the rigging. If you can show that you are still interested in unexpected battles, don’t get seasick and have no problems with parrots, then you might get the chance to find some buried treasure.

Ready for the next phase in your junior developer career? Experience growth with Junior Developer Part Time Jobs!