How Junior Developers get hired. A Window Into the Mind of the Interviewer

In starting to write this article, I had the rather curious thought that interviews are, when you really stop to think about it, rather awkward.

You meet a complete stranger for the first time and immediately dive into an intimate conversation about your ambitions and past failures. Oh, and a casual unpacking of your deepest insecurities. All while you're expected to perform under intense pressure.

An apparently perfectly normal human activity. Things that humans do, eh.

And I would know, as over the last decade, I've spent a lot of time on both sides of the junior developer hiring process.

I've interviewed aspiring software engineers as a manager, looking for signs that they were ready to join a professional team. I've also seen the process from the candidate-preparation side, helping bootcamp students build the skills and confidence to approach those same interviews.

Totally normal behavior. Obviously.

A four-panel comic strip illustrating an awkward job interview. In the first panel, a nervous candidate named Ernesto sits across a desk from a panel of three corporate interviewers. The middle interviewer says, "Excellent. Let's begin. So Ernesto, tell us about yourself." In the second panel, Ernesto looks sheepish and nervously fidgets with his hands as he replies, "Well, I have JS experience. I know loops and arrays pretty well..." In the third panel, a female interviewer from the panel smiles politely and asks a shockingly intimate question as if it were completely casual: "That’s great, but what’s your biggest personal flaw?" In the final panel, a dramatic close-up shows Ernesto’s face frozen in wide-eyed terror, sweating profusely, with the sound effect text "GULP" at the bottom.

This article brings together some of the observations and reflections I've collected over the years.

I also thought I would do something a little different from the typical get-hired write-up, so I have included a few illustrative interview notes throughout the article. These are anonymised composites, shaped by broader interviewing experience rather than any current workplace or live hiring process. The aim is simply to give you as clear a window as possible into my mind as an interviewer.

If you're preparing to interview for junior software engineering roles, my hope is that it gives you a clearer view of the gap between learning to code and being ready to work as a developer.

Show us the evidence

When we interview software engineers, especially junior and mid-level candidates, we are not expecting perfection. We know people are still growing. We know they may not have seen every framework, every architecture pattern, every database design problem, or every messy production issue. We are not looking for someone who already knows everything.

What we are looking for is evidence.

Candidates should prepare their evidence. The best candidates make the interviewer’s job easier. They do not make us drag the evidence out of them. Build your case in advance! The interview is won in its preparation days before it takes place.

Your evidence could be:

The categories above are broad, but deliberately so. I do not think you should try to anticipate every question you will be asked. That is how you end up sounding robotic and unnatural. Instead, think like a lawyer preparing a case. Gather evidence from a variety of sources, know what each piece proves, and be ready to use it when the right question appears. Ultimately, we're the jury you want to win over.

Some of your strongest evidence might come from education, previous jobs, weekend work, volunteering, or situations outside of tech entirely.

Think back and use your imagination. A group project at college might have shown you can collaborate and take responsibility. A weekend job might show that you can handle pressure, deal with people, manage your time, or stay reliable when things get busy. A difficult assignment might show that you can research and improve after feedback.

Iceland supermarket from the front, a supermarket found throughout the UK

Interview note

Candidate is a lifelong learner. Has completed several certs and online courses, seemingly for kicks as much as career progression. Spoke about a dev internship where they were asked to investigate why a dashboard was loading slowly: not satisfied with just saying "it's simply an API issue", they explained how they checked the network requests and noticed the same data was being fetched multiple times, this led them to propose caching part of the response. Good example of taking an unfamiliar problem and breaking it down. Also mentioned that after feedback from a senior dev, they rewrote part of a component to make state management easier to follow. Strong evidence of coachability and improving through real work. Thumbs up!

Interview note

Candidate described a college group project where two team members became disengaged and repeatedly missed planning sessions. Rather than criticising them or ignoring the issue, the candidate helped reset expectations and redistribute the unfinished work, keeping the project moving without making the situation personal. Suggest they can take responsibility when group work becomes uneven.=

There's knowing and then there's knowing

We often meet candidates who have used a technology but do not really understand it.

We see it most when candidates talk around the answer. They mention several related concepts, but never directly answer the question.

They describe a “network layer”, “clean architecture” or “data pipeline”, but cannot explain what it actually does, why it matters, or how it works. They list tools from their resume, but struggle when asked for specifics.

That creates a credibility problem. If something is on your resume, you should be ready to discuss it. You do not need to know every tiny detail, but you should be able to explain the why, the how and the trade-offs. Hearing you talk trade-offs is especially music to our ears.

This is important because software engineering is not just typing code into an AI chat window. In today's world, writing the code is increasingly the easier part. A lot of the real work happens when breaking down and translating requirements, debating architectural trade-offs, defending your approach in code reviews and finding ways of explaining technical complexity to non-technical stakeholders.

If someone cannot explain their own experience in concrete terms, it becomes difficult to trust that they can operate smoothly in such an environment.

The candidates we like are specific. They can tell us quite clearly: 

They do not need to exaggerate.

Interview note

Could not respond to technical questions directly. They would often talk about five different things without really answering what was asked, which gave the impression of a lack of knowledge or confidence in providing clear answers

Interview note

Biggest concern is the resume. It lists strong and relevant experience, but they were not able to clearly explain what they actually did on those projects. Struggled to answer questions about past work directly, often went off-topic, rambled a bit, then hyper-generalised. Concern experience may look stronger on paper than it came across in conversation

Interview note

Never reached the code-writing phase. The candidate is highly verbose and seems to overthink. Was unable to make a firm choice when pushed to make simple engineering trade-offs

Show us honesty

Across all roles, the strongest candidates tend to have a few things in common, but the quality I notice soonest is not necessarily raw knowledge. It is honesty of character.

If asked about Docker and they have only used it once, they do not ramble through a vague answer about "containers and deployment and this and that and DevOps", they say something like "I don’t know Docker deeply yet, but I have used a Dockerfile to run a local Node app, so I understand the basic idea of packaging an app with its dependencies".

That kind of answer is much stronger than pretending otherwise.

A lot of candidates come in thinking an interview is only about answering the questions posed to you correctly. It is not. The answer matters, of course, but the way someone gets there usually tells us much more and it's important to just be honest.

Dishonesty manifests when candidates overstate their experience. They list tools they cannot explain. They submit incomplete work without clearly prioritising the requirements. It's all very predictable.

For the malevolent masterminds tempted to keep an AI assistant open on another screen, it's not quite the masterstroke many imagine. I have never sat in a remote interview where a candidate tried to rely on such tricks and did not immediately give themselves away. It's painfully obvious.

If you are worrying about nerves as a way to justify cheating, someone worth working for will give grace for nerves. In fact, I expect juniors eager to land their first role to be somewhat nervous.

I'd say take ownership of your skill level. It is okay to be a junior. It is okay to be growing. It is okay not to know something. But it is not okay to hide behind vague answers, careless submissions, or inflated claims.

The Bocca della Verità (Mouth of Truth) in Rome

Interview note

Primarily a front-end dev trying to bridge the gap into full-stack. They openly admitted to lacking depth on the backend, but expressed enthusiasm for deepening their understanding, "I have mostly worked on front-end development, but I have supported some backend work and I am still building depth there", let's proceed with an offer..

Don't fumble the take-home test

This is the infamous task given to some candidates during the hiring process to complete in their own time, and it's easy to blunder.

We've seen interviewees with good attitudes, polished resumes, and a lot of motivation, but then submit work where major functionality is not attempted.

Filtering is incomplete. Search is missing. No form validation. Acceptance criteria are misunderstood.

In those cases, the issue is not that the solution is imperfect. Imperfect is fine. The issue is that the submission fails to convince us you're able to translate requirements into usable products.

For a junior developer, we do not need to see the most elegant architecture in the world. We do not need a flawless implementation where every edge case is handled beautifully. But we do need to see clear care and attention to detail.

When most of the requirements are either missing or incomplete, it becomes difficult for us to say, "Yep, this person is ready to contribute to a real project".

Make sure you understand all of the code you submit, as we will ask you to walk through it. We will want to know why you made certain choices and in particular which edge cases you thought about. We love geeking out on that stuff.

Interview note

The submitted take-home assignment was flawless, but a fatal disconnect emerged during the live review when the candidate was completely unable to explain any of the logic behind their own codebase. They tripped over basic execution flows and appeared entirely unfamiliar with the hyper-optimized data structures used, strongly indicating the solution was copied wholesale from an AI assistant.

Interview note

Code quality was okay, but there were some oddities that raised concern. One method had detailed documentation while the others did not, one form called a method that did not exist, and some of the code did not work properly. There may have been AI usage, but nothing definitive. I would maybe pass them, but with caution.

Interview note

Most of the tasks were not even attempted. Felt like they spent maybe an hour tops on this. Filtering and search were clean, but the form submission was barely attempted and gave zero user feedback.

Don’t fumble the live test

This is the practical part of an interview, where the candidate is asked to solve a task in real time.

These often involve whiteboarding tasks, where candidates solve problems and explain their thought process at the same time.

So we are mainly looking for signs on how they approach the problem.

Getting stuck is not automatically a bad sign. Everyone gets stuck. What matters is how someone behaves when they are stuck.

One of the most common failure patterns I've noticed from my notes is when a candidate requires heavy prompting for every step. They can get to the solution eventually, but only because we've repeatedly guided them across the finish line. This creates uncertainty. The candidate has some knowledge, but lacks independence.

In a real work environment, that can become expensive. Teams can support and mentor people, but they still need engineers who can take ownership of a problem and move it forward. The truth is that in today's competitive job market, it's not unheard of for juniors to take such ownership. Expectations are really high.

Time management also matters. Some candidates are technically capable, but take so long to work through an answer that they never actually reach one. In a deadline driven industry, that can be a real concern.

Engineering often involves imperfect information. You rarely have unlimited time to research every option. At some point, you need to make a reasonable decision, explain your thinking, and continue.

A strong candidate can be honest without becoming passive. They might say, “I’m not fully sure yet, but I can see where the behaviour starts to go wrong, so I’d start by tracing that part and testing one assumption at a time.”

Interview note

..demonstrated excellent problem-solving maturity when hitting a roadblock during the technical round. However, did not become passive, attempted to lay out a step-by-step strategy to trace the issue and test their assumptions. Highly positive signal for autonomy and real-world troubleshooting skills. Recommend proceeding to next round.

Interview note

Decent tech capability but poor pacing. Got bogged down overanalysing every option, froze up, and ran out of time before actually reaching a solution.

Have a conversation with us

An interview need not be a one-sided conversation, nor should it be.

Ask questions. Ask about the problem, the assumptions, the constraints, and the direction you are thinking of taking.

In a live technical exercise, we are not expecting you to silently disappear into your own head. We want to see how you think, and good questions are one of the clearest ways to show that.

Look for cues that present opportunities to ask questions.

For example:

Those sort of questions do not make you look weaker. They usually make you look stronger.

Software engineering is collaborative, and real work rarely arrives as a perfectly complete problem with every requirement neatly defined upfront. Good engineers know how to build rapport, speaking to the right people and fishing for the information they need.

The strongest candidates treat live exercises like a working session. They do not need to perform or narrate every keystroke, but they bring the interviewer into their reasoning.

That does not mean you need to be loud, extroverted, or overly charismatic. Some excellent engineers are quiet and reflective. But you do need to ask questions when the problem has given you a clear reason to.

Arnold Borisovich Lakhovsky’s The Conversation, c. 1935

Interview note

Good communicator, with a decent grasp of the technical language needed for the discussion. Test walkthrough was strong and the candidate's diagramming made their approach easier to understand. JS clearly a bit rusty and code writing took a while, but enough there for a soft thumbs up

Presenting yourself

"Present yourself well" or "show your best side" is the well-intentioned cliché teachers or family members have tended to advise us going into job interviews.

But before you eye-roll at Captain Obvious here, let me explain what presenting your best side actually looks like from our side of the hiring desk.

For starters, we don't necessarily expect you to see you in shirt and tie, we'd just prefer you don't come in wearing a sweatsuit. Maybe I'm just old-fashion, but I don't think you can go wrong with a clean shirt and jacket.

If you're interviewing remotely, make sure the space behind you is clean. If your background looks like a bomb went off in a laundromat, it simply shows a lack of care. This should be common sense, but I've long since run out of fingers to count how often it actually happens.

How you carry yourself matters immensely. You might expect a technical role to judge you strictly on your hard skills, but that is simply not how the real world operates.

The vast majority of candidates are genuinely nice people, but being nice doesn't automatically make you approachable. Approachability is built on tiny social cues that tell us you're genuinely glad to be there. It means greeting people with a smile, looking at the camera and not a second screen, and actually reciprocating during the initial small talk. When an interviewer asks how your week is going, an approachable person doesn't just mumble "fine", they pass the conversational ball back. People really connect with you when you show an interest in them.

Sure, it can feel a little performative or forced at times. But if you observe how humans interact, you'll find a lot of it is responding to various social cues, such as offering a bit of validation when someone tells you about their day.

Showing some humanity does pay massive dividends simply because, at the end of the day, people want to work with someone they actually enjoy talking to.

You don't need to be Jimmy Fallon, but if you struggle with small talk, try to bake some basic interactions and role-play into your preparation.

There are literal volumes written about how the first five minutes dictate the entire outcome. Interviewers make instant assessments and spend the rest of the meeting trying to confirm them. If they like you initially, they look for reasons to like you more. A poor first impression can be hard to recover from.

Interview note

Nice enough, but very flat throughout. No real energy, little engagement, and hard to tell if they actually wanted to be there. Quiet is fine, but this came across more detached than reflective. Would be hesitant putting them in front of clients.

Interview note

Strong culture fit. Easy to chat with, good energy. Showed genuine interest in the role and the people on the call. Would need mentoring technically, but very promising from a communication and attitude standpoint.

Bringing it all together

I certainly don't speak for all interviewers, but the ones I've seen generally have a similar thought process. I do hope, therefore, that I've helped make the whole thing a little less mysterious.

Remember, good interviewers are not trying to catch you out. If they are, that probably tells you something about the place itself. Most of the time, they are trying to answer a fairly simple question: can this person:

  1. Contribute to the team
  2. Keep learning
  3. Communicate clearly
  4. Work independently

Every senior developer was a junior once, so we know firsthand just how wide the gap is between learning to code and actually being ready to work in a professional environment.

It can feel frustrating, especially when you have already put in a huge amount of effort just to get to the interview stage. But the gap is not impossible to cross.

You cross it by building evidence. You cross it by understanding your own work. You cross it by being honest about what you know and what you do not.

You cross it by showing people that, even if you are still early in your career, you are someone worth investing in.

And if all else fails, remember this one comforting thought: the interviewer is probably also finding the whole thing as awkward as you are.