Over the years I've interviewed and spoken with many junior developers. One thing I've noticed is that most candidates worry about the wrong things.
Many juniors spend weeks memorizing framework-specific details, algorithms, or interview questions they found online. They worry about getting stuck during a coding exercise or being asked a question they don't know the answer to. Meanwhile, the candidates who leave the strongest impression are usually the ones who communicate clearly, think out loud, and aren't afraid to admit when they don't know something.
Technical knowledge matters, of course. Nobody expects a frontend developer to know nothing about JavaScript, frameworks, testing, or architecture. But after interviewing many candidates, I've learned that technical knowledge is rarely the only thing being evaluated.
Most of my interview experience comes from working with Dutch companies and teams, ranging from startups to large enterprises. While every company has its own interview process, I've noticed the same themes returning over and over again.
The interview starts before the interview
Most candidates think the interview starts when they join the call. In reality, it starts much earlier.
Before I speak to a candidate, I've already spent time looking at their CV. Of course I'm interested in work experience, but that's only part of the story. I'm also interested in someone's background. What education did they follow? What internships did they do? Did they have side jobs while studying? Have they worked on personal projects outside of school or work?
I'm not looking for a perfect career path. In fact, some of the most promising developers I've met had fairly unconventional backgrounds. What I'm trying to understand is whether somebody shows curiosity, initiative, and a willingness to learn.
A CV often reveals more than candidates realize. Someone who worked while studying, actively looked for opportunities to gain experience, or spent time building things outside of mandatory school assignments usually demonstrates a certain level of discipline and work ethic. That doesn't automatically make them a great developer, but it does tell me something about their mindset.
I'm usually not looking for the perfect answer
One of the biggest misconceptions about technical interviews is that interviewers are looking for perfect answers.
Personally, that's rarely what I'm looking for.
When I ask questions about testing, architecture, code quality, or technical decisions, I'm usually far more interested in the reasoning behind an answer than the answer itself. I want to understand how somebody approaches a problem, how they make decisions, and whether they understand the trade-offs involved.
Many candidates worry about not knowing enough. The reality is that it's often quite easy to tell the difference between someone who understands a topic reasonably well, someone who has only heard about it briefly, and someone who is completely unfamiliar with it. I don't need perfect answers to make that distinction.
What I find much more interesting is whether somebody can explain their thinking. Why would you choose one solution over another? What are the advantages and disadvantages? How would you approach a problem you've never seen before?
The "how" and "why" behind an answer usually tell me more than the answer itself.
The strongest candidates are rarely the ones who know every answer. They're usually the ones who can explain how they think.
Questions I almost always ask
Although every interview is different, there are a few questions that I find myself asking again and again. Not because there is a perfect answer I'm hoping to hear, but because the answers often reveal how somebody thinks, learns, and collaborates.
How do you keep your knowledge up to date?
Technology changes quickly, especially in frontend development. New frameworks, browser features, tools, and best practices appear every year, and nobody can keep up with everything.
I'm not expecting candidates to spend every evening reading technical articles or watching conference talks. What I do want to see is some level of curiosity. Whether that's reading blog posts, experimenting with side projects, watching YouTube videos, or discussing technical topics with colleagues doesn't really matter.
The exact answer is rarely important. The willingness to keep learning is.
What do you do when you're stuck?
Every developer gets stuck. It doesn't matter whether you've been working for six months or fifteen years.
I've had candidates tell me they would spend days trying random solutions until something worked. Others immediately said they would ask a senior developer. Neither extreme is ideal. What I'm usually looking for is somebody who investigates the problem first, documents what they've tried, and then asks for help when they're genuinely blocked.
I'm usually looking for balance. Strong developers are able to work independently, but they also know when it's time to ask for help. Software development is a team effort, and knowing when to collaborate is just as important as being able to solve problems on your own.
What role does testing play in software development?
This question often reveals more than candidates expect.
I'm not necessarily looking for somebody who knows every testing framework or can explain the differences between unit tests, integration tests, and end-to-end tests in great detail. What I'm interested in is whether somebody understands why testing exists.
For me, testing is about confidence. It allows developers to make changes without constantly worrying about breaking existing functionality. Candidates who understand that usually have a healthier view on maintainability, refactoring, and long-term ownership of software.
The exact tools you've used matter less than your understanding of why testing is valuable.
What if you don't know the answer?
Almost every junior developer worries about this.
The reality is simple: nobody knows everything.
In fact, during most technical interviews I expect candidates to encounter at least one question they don't know the answer to. That's completely normal.
The worst thing you can do is panic and start inventing an answer. Most interviewers have enough experience to recognize when somebody is guessing. A confident but incorrect answer is usually far less impressive than an honest acknowledgement that you don't know.
Saying "I don't know" is perfectly acceptable.
Even better is saying something like: "I'm not sure, but this is how I would approach finding the answer."
That tells me far more about your potential as a developer than a memorized answer ever could. Software development is full of situations where you don't immediately know the answer. Being able to reason through a problem is often more valuable than already knowing the solution.
Dealing with nerves and impostor syndrome
You're probably more prepared than you think
One thing I've noticed over the years is that many junior developers underestimate themselves.
I've interviewed candidates who were visibly nervous, convinced they weren't good enough, and apologizing for gaps in their knowledge before the interview had even properly started. Ironically, some of those candidates ended up performing extremely well.
The truth is that most developers experience some form of impostor syndrome, especially early in their careers. When you're constantly surrounded by experienced colleagues, conference talks, technical blogs, and social media discussions, it's easy to feel like everyone else knows more than you do.
What many candidates don't realize is that interviewers see this all the time. Feeling unprepared doesn't necessarily mean you are unprepared.
Interviews aren't exams
What candidates often forget is that interviewers aren't expecting juniors to perform like seniors.
Nobody expects you to know every framework, every design pattern, or every JavaScript feature ever released. What interviewers are usually trying to determine is whether you can learn, communicate, collaborate, and grow over time.
An interview isn't an exam where every answer is either right or wrong. It's a conversation. The company is trying to understand who you are as a developer, but you're also trying to determine whether the company is the right place for you.
I've hired and recommended developers who couldn't answer every technical question I asked. What stood out wasn't their knowledge, but their ability to reason through a problem, ask good follow-up questions, and be honest about what they didn't know.
A few nerves are completely normal. In my experience, they usually mean you care. And caring about your work is often a much stronger signal than knowing the perfect answer.
Final thoughts
After interviewing many junior developers, I've learned that the strongest candidates are rarely the ones who know every answer.
They're the candidates who communicate clearly, stay calm when they don't know something, ask thoughtful questions, and show genuine curiosity. They're willing to explain their reasoning, comfortable admitting uncertainty, and eager to learn from the people around them.
Technical skills might get you invited to the interview, but your mindset often determines whether you get the job.
The next time you walk into a technical interview, remember that nobody expects you to know everything. The real question isn't whether you have all the answers today, but whether you'd be somebody the team wants to work with and learn from six months from now.
