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.
- Why did you want to work in software development? …
- What skills do you think are important for a junior software developer? …
- What programming languages are you most familiar with? …
- How would you troubleshoot software bugs?
Junior Developer Interview Questions
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 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:
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:
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.
What steps do you take to improve UI design?
User experience is a critical aspect of software development, and this type of question can help the interviewer understand how you prioritize this concept in your design projects. Describe your experience with streamlining applications that lead to improved user experience and engagement.
Example: “First, I evaluate the application for ease of use and navigability, then I focus on creating sequential tasks, like following a sequence to shop for items, place items in an online cart and purchase items. I make the UI design as simple, direct and efficient as possible by emphasizing on end objectives and the actions users take to get there.”
