How to Impress in a Junior Developer Job Interview

This article will go through tips on how to ace a junior developer job interview and is written by Natasha Postolovski, a Graduate Software Developer at ThoughtWorks. You can follow her on Twitter: @npostolovski.

The Junior Developer job interview process can seem a little bit scary. For some Junior devs, this might be their first job interview… ever. For others, it may not be their first job interview, but possibly their first software development interview. You might have read horror stories about having to solve really hard computer science problems at a whiteboard, or even over the phone. This may be true of the most competitive companies like Google and Facebook, but for 99% of Junior developer roles, the interview process is more about demonstrating a passion for technology and a great attitude than it is about flexing your technical muscles.

If you love to code and have a solid grasp of the fundamentals, then it’s time for your first Junior developer interview!

Want to ace your technical interview? Schedule a Technical Interview Practice Session with an expert now!

The Interview Sequence

Junior developers will often proceed through multiple rounds of interviews. This will usually start with a phone or email conversation, and then through the following rounds, though not necessarily in this order:

• Coding Challenge
• Cultural Interview/Initial Conversation
• Code Challenge Review
• Technical Interview

Some companies merge these interviews together, while others might split them over multiple interviews.

It can be daunting to approach an interview process when you don’t quite know what to expect. Luckily, there are ways to be prepared.

Come Armed With Knowledge

Sites like Glassdoor allow you to gain a peek inside the interview process. Candidates, both successful and unsuccessful, can use the site to post feedback about their interview experience. Reading through the interview feedback for the company you’re applying to can help you gain an understanding of the interview sequence. You may be able to learn what kinds of interviews you’ll go through, and roughly how they will be structured. The point is not to ‘cheat’ and try to preempt interview questions, but simply to get a broad-strokes picture of what the interview process is like. If you know that the interview process involves a stretch of problem solving at the whiteboard, for example, you can practice this kind of interview with a friend or mentor in advance.

If people do share details of specific questions asked or challenges given, it’s best to prepare for similar kinds of problems and questions, but not to focus on that specific example. Different interviewers like to ask different questions, and companies regularly refresh the challenges given to prospective employees. How you approach and work through a problem is often more important than getting to a particular solution, and memorizing answers will harm rather than help with this.

Lastly, your point of contact at the company should be willing to give you a run-down of the different stages of the interview process. However, I’ve found that while they are usually willing to tell you the type of interview you’ll be doing, they’ll be cagey about the kinds of things you’ll be asked to do. This is why online research is so invaluable. When it comes to interviewing, knowledge really is power.

The Cultural Interview or Initial Conversation

This interview will feel most like a conversation. It may happen near the start of the interview process, or later on, once your technical potential has been established. The interviewer is trying to answer a few basic questions about you:

• Would you work well inside the existing team?
• Are you a nice person? Are you likeable?
• Do you seem to be passionate about technology?
• Do you seem smart?
• Can you communicate?

The interviewer can’t ask you these questions directly, so they will ask proxy questions to try to discover the answers about you. A few of the most common questions I’ve encountered are:

• What kind of technologies are you excited to learn more about?
• Can you tell us about a cool project you completed recently?
• What is your favourite programming language?

All of these are proxy questions. In truth, the interviewer is trying to figure out whether you truly care about technology. As a Junior developer, the extent to which you are curious about and excited by technology is a good predictor of your rate of skill growth over time. Interviewers will, in general, be more concerned with where they can see you in a year or two than your skills right now.

It’s important to come to a cultural interview with some ideas on how you would answer these questions. Be friendly, curious, and conversational. Do a little bit of research about the company before-hand, but also ask the interviewers questions to broaden your understanding.

Another question you should be prepared to answer is: why us? Interviewers want to know that there is something specific that drew you to their company, whether it is an ambitious mission, cool technology, or a great team. “I need a job and you were hiring” isn’t a very compelling reason… even if it’s true!

The Coding Challenge

Coding Challenges are a very common stage in Junior developer interviews. Some will involve coming up with the appropriate algorithm to solve a problem, others will focus more on object-oriented concepts and designing a system. Either way, there are a few really simple things you can do to leapfrog 90% of applicants. I’ve reviewed a bunch of coding challenges, and here are a few things that stand out when applicants include them.

• A comprehensive README. Include instructions for how to get your program running, and don’t make any assumptions about the system the reviewer will be running your program on. Try running your program from scratch guided only by your README. Then try it on a friend’s computer, preferably running a different OS! Lastly, a README is a fantastic place to share your thinking around your program. Address any limitations, and talk about how you would improve or extend upon your program if you had more time.
• Automated tests. Few Junior developers include automated tests with their coding challenge. It is so rare that it can instantly catapult you into consideration for the next round. If you don’t know how to write unit tests, here’s a guide to learning unit testing with Rails.
• Separation of concerns. Your program should not be entirely contained in one file. Separate the different parts of your program into classes or modules that have one responsibility. A good tip is this: try to describe what a particular class or module does. If your description involves the word ‘and’, it may be a good candidate to split out into smaller components.
• Write small methods/functions that describe what they do. Variable names should describe what the variable contains. Functions/method names should describe what the code within them does. And remember, you don’t win any points for short names, and unless you’re working with algebraic equations, single letter variable names should be avoided at all costs. Really well-named classes, functions/methods, and variables make comments unnecessary. Lastly, split large methods into smaller ones using the extract method refactoring technique. It will make your code much easier to read.
• Don’t gold-plate until your coding challenge is done. I often review coding challenge solutions that fail to pass with the provided test input, or just barely work, because the programmer sank a lot of time into trying to add unnecessary flexibility or extra features into the program before the base problem was solved. It’s clear that they ran out of time, half-finished the extra functionality, and slapped the program together just before the deadline. It’s much smarter to solve the problem at hand in the simplest way possible, then improve or extend on your solution if there is still time to do so. Sidenote: this is a good rule of thumb for software projects in general.

The Coding Challenge Review

It’s increasingly common for companies to call you in to review your coding challenge submission in person. This will almost always involve feedback, and may feel like the interviewer is trying to challenge your technical skills. However, for most Junior coding challenge reviews, the interviewer is trying to figure out something very important: how do you take constructive criticism? As a Junior developer working in a team, you’re expected to occasionally make mistakes, and to receive constructive criticism on your work. In general, it’s fine to make mistakes and take the wrong approach now and again, as long as you respond positively and are open to the feedback.

Here are the most important things to remember when an interviewer is giving feedback on your coding challenge:

• Listen to the feedback. As a Junior developer, this is a fantastic opportunity to get great feedback from a (likely) more senior developer. Enjoy the learning opportunity!
• Don’t get defensive. Even if you don’t agree, try to see things from the other person’s perspective.
• Reflect aloud on what it would look like if you implemented the feedback. Restating the feedback in your own words helps the interviewer see that you are practicing active listening and taking the feedback on board.
• Ask questions to deepen your understanding. If you agree with the feedback, this is a great way to gain a deeper understanding of why it could make your program better, and how you might implement it. If you disagree, it will help you to understand the interviewer’s perspective better, and to make a more informed decision about whether to adjust your habits, or chalk this one up to a matter of personal preference.

As part of a code review interview, you might also be asked to extend upon or refactor your program. For this reason, make sure to re-familiarize yourself with the program and the code you’ve written before you go into the interview. You may be asked to explain why you made a particular choice, or how a certain algorithm works. You want to have a better answer than “I don’t know” or “I don’t remember”.

The Technical Interview

This interview will usually consist of questions about technology, questions about your experience, and most likely, a session at the whiteboard.

Whiteboard coding interviews are polarizing in the developer community. Some people think the ability to hash out a problem at a whiteboard is a critical skill that all developers must possess. Others feel like the nerve-wracking circumstances are setting up less confident developers to fail. Like it or loathe it, problem-solving at the whiteboard is a recurring feature of most software development interviews.

Most interview processes will involve whiteboarding the main concepts or classes in a system, either a hypothetical system, or one you’ve designed in the past. It’s worth learning on how to draw UML diagrams prior to the interview, but don’t get caught up on the details. It’s more important that you come up with a good design at a high level than get caught up fretting about whether an attribute should be an int or a bigint.

Questions may be something like:

• Draw the main classes and functions/methods in a Scrabble.
• How would you design a database for a blog?
• If you had to build a Twitter clone, how would you design the program?

It’s a good idea to practice these kinds of questions on a piece of paper or with a friend prior to the interview. As a starting point, try to think about the nouns and verbs involved in your system. These can often be broken out into classes and functions/methods respectively.

Another common aspect of the whiteboard technical interview is being asked to write an algorithm to solve a problem. I’ve found that sorting problems are very common in Junior developer interviews, for example:

• Write code to sort a given array from smallest number to largest number, without using any convenience methods (i.e. #sort in Ruby)
• How would you reverse a given word without using any convenience methods (i.e. #reverse in Ruby).

These kinds of challenges can be tough, as we’re much more likely to use our favourite language’s convenience method for tackling such problems, rather than writing a solution from scratch. For this reason it’s important to spend time practicing these kinds of problems. Get familiar with using loops and conditionals in your programming language of choice, as they’re likely to be a key part of any algorithm you will be asked to write. You can practice solving these kinds of programming problems at a site like CodeWars.

Remember, though, that solving problems at a whiteboard and solving problems in your favorite text editor or Terminal shell are two different beasts. It’s important to practice coding at a whiteboard. If you don’t have a whiteboard handy, a piece of paper will suffice. Ideally, have a friend give you a problem to solve that you’re unprepared for in advance, then have them act as an interviewer as you try to solve the problem. This will help you to be calmer in the actual interview.

When the interviewer gives you your whiteboard challenge, it’s incredibly tempting to start drawing on the whiteboard immediately. Instead, pause, and use your first few strokes with the whiteboard pen to write down the problem. Clarify your understanding of the problem as you do so, and ask the interviewer questions to clear up any ambiguity.

You will usually have the option to write pseudocode (sentences that describe what code should do), or real, syntactically correct code. Trying to do a hybrid of both will just seem to the interviewer like sloppy code, so pick one approach and stick with it. It can be a good idea to start with pseudocode and then rewrite your solution as code once you’re confident in your solution.

Remember, you don’t need to come up with a perfect solution. At a Junior developer level, it’s more important for an interviewer to see that you can think through a problem, and communicate as you do so. Think aloud if possible, and if you need some time to stand and think, let the interviewers know. It’s perfectly fine to say “I’m just going to take a minute or so to think about this.” If it starts to get awkward, you can always say “Sorry, just another 30 seconds.” Long periods of silence are fine, as long as the interviewers know that you’re working on the problem, and not just totally stuck. Remember, if in doubt, just keep talking! Let the interviewers know that you are working hard on the problem, not staring at the whiteboard and hoping for a miracle.

If you’re struggling, the interviewer will often drop small hints to point you in the right direction. Listen to these, and run with them. The interviewer is throwing you a life-line. It won’t be seen as a failure to listen to and use what the interviewer is saying. However, if you ignore their help and keep focusing on your own thoughts or frustration, it might be.

I struggle most with this part of the interview process. Every time I’ve had to do a coding challenge at a whiteboard, I’ve felt that I failed miserably: either I didn’t come up with a solution in time, or struggled too much while getting there. And yet, each time, I’ve progressed to the next stage in the interview process. It’s important to remember that these challenges are designed to stretch you, to stump you, and even frustrate you. If you can stay calm, keep communicating, and gradually get to a solution — even if you receive a helpful nudge along the way—you’re doing just fine.

Remember: You’re Interviewing Them Too!

If you have the luxury of interviewing at multiple companies, it’s worth taking the time to make sure that your prospective employer provides a supportive environment for Junior developers. Here are some questions that can help you learn more about your prospective company. As an additional benefit, these questions show that you care about your career and your development, which isn’t a bad thing!

• How do developers on the team give each other feedback about their code? In my opinion, an environment where Junior developers are mostly pairing is excellent for learning. If the team doesn’t pair, developers should do regular code review, either through GitHub pull requests, or planned code review sessions. You won’t improve quickly unless you can regularly write code with others, see the code that others are writing, or get feedback on your code.

• How often does the team do pair programming? As a Junior developer, ‘most of the time’ is ideal, but ‘sometimes’ is the norm at many companies.
• What do you expect from a Junior developer? Answers based around learning, growing and curiosity are ideal. Answers around work hours, workload, bug fixing and increasing test coverage are not so ideal.

Go Forth and Conquer

Having participated in several Junior developer interviews, and more recently having been involved in them as an interviewer, I believe that following these tips will put you in the top 10% of Junior developer interviewees at many companies. Research, practice and preparation will give you a meaningful advantage against other candidates, and more importantly, the freedom to give the interview process your best effort.

Good luck, and go get hired!