How do you interview junior developers for a potential hire?
Posted by Chuu@reddit | ExperiencedDevs | View on Reddit | 40 comments
I have a reputation as a good interviewer. In general my approach is just ask questions about technical and non-technical problems I've struggled with in the past to see what they come up with and their though process, with one or two 'do you know how to actually implement this' relevant programming problems also taken from real world scenarios.
The thing in common though is they were all Senior devs, which both has a huge effect on the baseline technical and industry knowledge I expect and also what level I expect to be able to converse and communicate with them on areas unfamiliar to me.
I've been asked to be part of the interview process for protentional Junior hires, and I am not sure how well this approach will work. Any advice for how to interview devs for a Junior position, and how it differs for Senior positions?
umtala@reddit
Look for people who show an ability to learn quickly.
Test them on a level playing field. Set them a task in an uncommon programming language, one that you're sure they don't know, and let them use basic reference material.
Many people prepare for interviews by rote memorizing your stack, I know I do. You want to burn past all of that and get to the core of their programming ability rather than simply give the job to the candidate who had the most time to prepare. Preparation only proves that someone had nothing better to do!
It's also good to ask them if there's some type of programming unrelated to the role that they enjoy doing just for fun. Intrinsic motivation is a very good signal for juniors, whereas seniors might have been programming long enough (and have families) such that they don't want or can't to do it in their spare time.
Antique-Stand-4920@reddit
- Gauge their initiative, interest, and curiosity by asking about projects they've worked on, even if it is a random thing they did for a grandparent. I don't like to rely what a person says they are interested in. I'm more interested in what they've actually done.
- Ask them about difficult situations they faced and how they dealt with it. These situations don't always have to be about software.
- Pay attention to their honesty. If they say, "I don't know," that's a better sign than just them BSing their way through.
- This can be a gray area, but if they mention them, ask them about their hobbies. Sometimes a hobby can involve skills that can complement technical skills.
FlowOfAir@reddit
Say it louder for the people at the back.
Of course you don't want people who will answer "I don't know" at everything, but if they seem to have a solid grasp of the basics, despite having a few holes here and there, then that's good enough. And honesty > perfection; you want a report who has decent work ethics, you can train skills, but you can't train someone out of being an ass.
In other words, don't shoot for perfect. Shoot for good enough.
jmking@reddit
I'd argue that "I don't know" isn't a good answer if it isn't followed by "...but here's how I'd find out".
FlowOfAir@reddit
Agree. I would be a little less rigid, recent graduates don't have the experience to understand this is how they should respond, so maybe nudging them a little and asking "well how would you find out?" can probably give a better insight.
jmking@reddit
Oh, I agree 100%
I meant that they'd have to have an answer to "how would you find out". However, if someone wants to kill it in a new grad interview, making that part of their answer is 100% a way to stand out.
Zestyclose-Sky1818@reddit
how do you handle if they haven't worked on projects
Rosenvine@reddit
I have always been a favor of doing a packet style interview. Where you ask the same questions every time and can compare the results. When you are interviewing juniors, I find it helps to give them a few softball questions to start with and mixed in as needed. as they sometimes can use the confidence boost to be able to work through the harder questions, I don't actually write down their answers to the softballs as they are just a chance to get them feeling okay enough to get through the process. You also should focus a bit on making sure their level of self direction fits your culture and make sure they don't have the "Wonder Kid" syndrome where they are going to cause issues with other engineers.
Senior is more about going through work history, and making sure they actually know how to do the things they say they do.
Ok-Armadillo-5634@reddit
I like to throw them in the deep end and see how they solve a problem they never encountered. I don't really care if they can solve it. I just want to see them at least make a damn attempt. 80% will just give up without even trying now. About 10 years ago only maybe 5% would just give up. I literally tell them just don't use ai and google and that I actually expect them to actually be able to solve it.
NeedleworkerMean2096@reddit
the difference between junior hires in the past and now is interesting- the current ones will juts tell you they don't know even without an attempt
Alainx277@reddit
No google? Do your devs not have internet access at work?
Ok-Armadillo-5634@reddit
Actually no a lot of time lol. I work in defense with security clearance needed now. That is not the reason though, like I said I want to see how they problem solve on their own. It evens the playing field for people with physics and mathematics degrees also.
ShapedSilver@reddit
That’s interesting. I worked in defense as an intern and I was allowed to use the internet, but not on the same computer I did dev work on. I had two. So one would be open to the code and the other would be open to SO (not posting anything just reading posts similar to my issue)
Ok-Armadillo-5634@reddit
Depends on the clearance level there are some where you get checked in by a guard and searched no watches or any electronic devices typically SCI and Top. Everything is air gapped. Most secret level work doesn't need air gapped. Did you have to do a polygraph? Since you were an intern I really doubt you were doing compartmentalized work.
jonmitz@reddit
I just had an interview where I was not allowed to use MDN to look up obscure web semantics. mother fucking MDN. not ai, not even good.
Ok-Armadillo-5634@reddit
Did they actually expect you to just know it? I only ask for psuedo code especially since it's going to be on notepad or whiteboard or something during the interview.
hippydipster@reddit
You've been interviewing people to find out if they know what you know. You get a yes or no answer to that question, but its the wrong question, as it doesnt really tell you if the person knows a lot or a little, or whether they're competent, good at learning new things, etc.
You need to interview to find out what they know. Good people know a lot (still releative though, juniors relative to juniors, seniors to seniors). Quality people generally know more than others. They learned more because they're good at learning, have ambition to learn, curiosity, etc. You'll only find that out by interviewing them in a way that let's them reveal what they know, even if its not something you knew to ask for specifically.
kevinossia@reddit
The same way I interview anyone else.
I scale my interview loops up and down in difficulty to reflect the requirements for the position. But the questions tend to be mostly the same.
chikamakaleyley@reddit
ask them to talk about a project they made, it could be even outside the skillset of the job in question
the real ones will nerd out and go as deep into detail as you want to take it
it's their first engineering job, and for many their first actual job coming out of college is going to be a culture shock - top of the class or just barely managed to grad.
you just want someone who has like, genuine curiosity and interest in technology, not 'i built this app because someone on reddit said it would improve my portfolio'
chikamakaleyley@reddit
PS if not obvi already, this is just one part of the candidate assessment
xsdf@reddit
Give them a real world task, have extra requirements in pocket if they finish much earlier but expect them to take the entire interview to brute force it.
Pay attention to how they break down the problem. Do they ask clarifying questions? How do they handle getting stuck? Are they good at debugging and switching approaches or do they hit a wall and spin their wheels? Are they familiar with the language? Do they communicate well? Are they honest, no BS answers?
Big things are ability to debug without hand holding, excitement for role, growth potential, and culture fit. They will lack experience, so it's more appropriate to check if they can learn and grow quickly
titpetric@reddit
I have a relaxed criteria for juniors. Discuss programming language/stack familiarity, what kind of programming they enjoy, how they feel about tests, how they would organize work for a typical task you deal with. Consider their interest and overlap with what your roadmap is.
If your idea is they should be able to code somewhat, go through a technical round where they demo their use of the programming language, or you just kind of confirm they know what npm is, how dependencies are managed. An assesment will tell you (and them) the areas they are familiar with, or areas they need investment in.
I can probablly tell you better how to grow a junior, than how to hire one. I remember reviewing a stack of CVs once, and if it's any comfort, 2/3rds of the CVs were not passing a checklist of requirements. Stupid stuff too, like not putting contact info into the CV, one guy was very verbose with his 8 page life story, etc. ; just choose a guy/gal who's communicative and seems to know the coding process, and if that fails, find them at your local meetup, reach out to the right circles if you want a better pick (user group aka meetup.com if that still alive)
Mike312@reddit
When I interviewed juniors, the main thing I looked for was whether or not they actually seemed interested in programming, because I feel like someone who is interested in programming is more willing to learn and apply themselves.
We got a lot of applicants whose whole resume was "CS major" - no career history in or out of programming, no side projects, no personal projects or portfolio, the only examples of their work were school projects.
The ones we short-listed for interviews were ones that had outside projects. One guy was building Twitter bots (back when you could do that) and had a couple other interesting things he was working on. A couple had built their own portfolio website - which is to say the candidates we didn't bother with didn't even have a personal website they built. A couple had weird specific niche programs or had dabbled with home automation or hobby-specific systems.
As for the actual interview itself. I'd ask them to explain one of those projects to me in under 10 seconds - basically an elevator pitch; I want to know if you can condense an often-complex system into a sentence or two.
I'd also ask
Chuu@reddit (OP)
> We got a lot of applicants whose whole resume was "CS major" - no career history in or out of programming, no side projects, no personal projects or portfolio, the only examples of their work were school projects.
Honestly this attitude kind of bugged me when I was first looking for a job. I always excelled in my classes and went into CS because I was very into computers in general in high school. But carrying 18 credit hours and also taking some grad level classes my senior year I just did not have time for personal projects.
Mike312@reddit
I double-majored and worked part-time, though I mostly did 12- or 15-credit semesters. At least you had summers off - I just worked full-time then.
But - and this might be location-dependent - we had a lot of people in their mid-to-late-20s applying, so for some of them, it may have been JC classes or a bootcamp instead of specifically a CS degree.
There was one guy in particular I'm thinking of, late 20s, taking JC courses in the evening, but was driving trucks for a beverage distributor at the time, had a son he was taking care of. He still found time to hack together a couple really cool Python projects plus doing a ton of Arma mods. He got dropped from 2nd round the first time we interviewed him, and I reached out to let him know the job had been re-posted and we ended up hiring him the second time. Great programmer, brought a ton of unique knowledge to the team.
Ghi102@reddit
It's kind of annoying being on the receiving end, but asking them to do a small constrained coding problem can filter out some phony applicants. Something like FizzBuzz, or slightly more complex, but still relatively simple.
I have had some applicants really struggle handling basic coding tasks. I also want to emphasize again that it should be simple and straightforward. The type of task that should take them at most 15 mins to type up, that genuine applicants can just type a solution without having to think too too hard on the solution.
Bonus points if you can find small discussion points about their code.
Salt_Candidate8080@reddit
The biggest things I look for in juniors are: motivation, initiative, enthusiasm, creativity, and willingness to learn new things.
LineageBJJ_Athlete@reddit
Hire based on what you feel they can become. Not what they are currently. Potential is currency with juniors.
engineered_academic@reddit
Initiative, attitude, and coachability are things you need to index for
teerre@reddit
Certainly depends on the role. There are roles that the main thing is having some specific knowledge and that triumphs anything else
If that's not the case, the main thing I look for is how they communicate and how they think. Domain knowledge can be taught, a good attitude is much harder
IME it's also easier than it seems. Some candidates are just obviously good. Teaching in the outreach program of your university while contributing to a famous open source project? Very likely good
Modman1618@reddit
Don't ask them questions that do not pertain to their role. For example, asking a junior candidate random leetcode questions. Are those questions directly applicable to their job description?
Ask questions that gauge their interest, overall experience level, and ability to work with other devs and non-technical people. Sure, having some programming experience is necessary but at the junior level, they will need quality mentorship to move forward in their careers
Agitated_Marzipan371@reddit
If they have a degree you can ask them basic algorithms questions to see if they learned anything
aerrin@reddit
I think one thing to remember about juniors is that you will get individuals in a variety of places on the Dunning-Kruger spectrum. This can be part of what makes it tricky - because the confident individual may actually be less knowledgeable than the one full of doubt and nerves. It can be nerve-wracking to live-code on a shared screen even if you are experienced in pair programing and are confident you know what you're doing. It can be DEBILITATING if you're not. I'd think about ways to alleviate this.
I was hired in my first software job \~4 years ago as a self-taught developer, and I'm pretty good at my job and learning new things - but I'm pretty sure if I'd had to write code in front of people during my interview I might have died. Instead I did a short take home challenge (perhaps more difficult in the age of AI). I really liked that because it gave me a bit of time to think and use tools like Google. The test also asked me a bunch of questions about things I considered while writing, different ways I might have approached it, and I think discussing THOSE is what was really helpful to my interviewers. They didn't just focus on my code, they focused on my process and the questions I asked and was thinking about while writing it.
We also looked at code I had written for a hobby project, and this was really great because I was really able to explain what I'd done, and they could see how I coded without the pressure of doing something live. If they have a repo you can look at, ask them to give you a tour of it and walk you through how they designed it/made decisions. I think this is an excellent way to get an idea of someone without the pressure of live coding.
lordnacho666@reddit
Yes it's hugely different.
A senior conversation is simply sparring about things that someone who is actually senior knows. This or that technology, pros and cons, what's your opinion, blah blah. And it's very easy to know if someone has touched on the things you need, what areas they've focused on. You can't really make it up, you'll run out of generic things to say if you don't have the experience.
A junior conversation is about motivation. Often they don't even know what they applied for, they just know it makes a lot of money and they would like some.
Your number one question is: "What do you think this job IS?"
People who can't answer that are, sadly, out the door. There's a lot of kids who could learn on the job, of course. But your risk is they start the job, find out what it is, and decide it isn't for them. You've then spent the time of a senior mentor on them for half a year, down the tubes.
It's secondary whether the person is highly skilled. College grads are smart. You don't need to put them through a million LeetCode questions. If there's something they didn't cover on their course, but they want to learn it, they will learn it. Whether the guy learns it is the check of motivation. There aren't really that many dev/STEM jobs where a guy has a degree, but he's so dumb that despite being motivated he can't do it.
So for the motivation part, find out how deep it is. Can they talk about what they understand the business to be? Did they read any books about it? Do they have any understanding of how the industry works? Do they have a clue about what the day-to-day might look like?
Lastly, communication. They can't learn anything if they can't be part of a team. As a dev, they will need to be able to ask proper questions from people, while having an imperfect understanding of the area. Can they navigate that ambiguity? If they've built something, which often will be an awful mess, can they talk through what they've done? Can they be honest about where they don't understand something? For this section, maybe walk through something they built, or some sort of design you want them to think about.
Make it something big enough that nobody can really understand it all. Weed out people who are trying to confidence trick you into thinking they figured it all out, and weed out people who are paralyzed with fear of being wrong. You want someone between humbly contemplative and confident but malleable. Someone you can talk to and they offer some resistance, not zero or infinite.
CelebrationWitty3035@reddit
What? No Leetcode??? 😂😂
PixelPhoenixForce@reddit
junior developers in 2026? wow
ThoughtfulPoster@reddit
We're still doing college recruiting. Maybe the doom and gloom will come for us all, but it's not a wasteland everywhere.
_hephaestus@reddit
I’d start with the expectations and work backwards from there. Generally the expectations are for juniors to come in as eager sponges for knowledge and growth, but sometimes upper management looks at them for cheap labor to grind away blindly with LLMs and that’s a very different approach to the role. Pragmatically look to the people whose team they’d be joining, find what they’re eager to teach, and what they’ll be annoyed at if the junior hasn’t figured something out in 6 months.
crazylikeajellyfish@reddit
I think that for juniors, the trick is that you're trying to assess instincts and perspective more than experience.
It forces you to spend more time on coming up with a technical question that has decent complexity but is completely self-contained, where the candidate doesn't need to know anything other than what they've been given. That way, previous experience building real-world systems stops being so important. I like "open book" interviews where the candidate can use Google, although not LLMs, because it lets you see their research and debugging process.
Temporary-Air-3178@reddit
An easy or medium problem from Leetcode. Could also throw in some oop or other knowledge questions.