A junior developer's interview performance is not just about whether they can solve the problem. The same candidate, given the same problem, can lose the offer through behaviour and earn it through behaviour. Interviewers are deciding many things at once.
Here are the patterns I have watched cost otherwise solid candidates the offer, and the fixes that are cheap to make.
Mistake 1: starting to code before understanding the problem
The candidate hears the question, sees a pattern, and is typing within twenty seconds. Three minutes in, they realise they misunderstood, and now they are visibly flustered with a half-written solution.
The fix:
- Repeat the problem back in your own words
- Ask three clarifying questions, even when the problem seems obvious
- Confirm the expected input and output with a small example
- Sketch the approach in words before touching the keyboard
This costs you 90 seconds and signals professional discipline. Interviewers love it.
Mistake 2: silence while thinking
The candidate goes quiet for two minutes, then suddenly types a complete solution. The interviewer has no idea how they got there. The solution turns out to be correct; the candidate fails the interview anyway because the signal of thinking was missing.
The fix:
- Narrate your thinking as you go
- Articulate the trade-offs you are considering
- When you make a choice, explain why
- When you are stuck, say so, then describe the dead ends you are eliminating
Most interviewers are not testing whether you can solve the problem in silence. They are testing how you think out loud, because that is what working with you will feel like.
Mistake 3: claiming knowledge you do not have
The interviewer asks if you have used X. You haven't, but you have heard of it, so you say "yes, a bit." Three follow-up questions later, the bluff is obvious. The interviewer now distrusts the rest of your answers, including the ones that were actually true.
The fix: be honest, fast. "I haven't used X, but I have used Y which seems similar. Could you tell me a bit about it and I can guess at the trade-offs?"
Honesty about not knowing something is taken as a senior trait. Faking it is taken as a junior failure mode.
Mistake 4: not testing your own code
You finish the function. The interviewer says, "Looks good. Are we sure it works?" You hesitate, run it in your head, and the interviewer prompts: "What happens if the input is empty?" You realise you did not consider it.
The fix:
- Walk through your code with a normal input before claiming you are done
- Then walk through it with edge cases — empty input, single-element input, very large input, negative numbers if applicable
- Explicitly list the edge cases you are checking, even when you decide they are not applicable
Mistake 5: avoiding rather than learning when stuck
You hit a wall. Instead of admitting it, you start writing pseudocode, then bigger pseudocode, then "let me come back to that." The interviewer watches you procrastinate for ten minutes.
The fix: when you are stuck, say so. "I am not seeing how to handle this case. Can you give me a hint?" Asking for help, especially after demonstrating you have tried, is treated as a strength.
Mistake 6: overoptimising before solving
You can see a fancy O(n log n) solution but you have not yet got the obvious O(n²) one working. You spend twenty minutes architecting the fast version, do not finish, and have no working code to show.
The fix: get something working first. Mark it as the naive approach. Discuss the optimisation. Implement the better version only if there is time. A working naive solution beats an unfinished optimal one in 95% of interviews.
Mistake 7: poor variable names and code organisation
Your code works. The variables are x, x2, temp, and arr. The interviewer is now reading the code thinking about what it would be like to merge a pull request from you.
The fix: name variables for what they hold, not what they are. userIds beats arr. maxStreak beats temp. Use functions to break up logic. Add a one-line comment at non-obvious bits.
This is purely behavioural. The same algorithm with clear names reads as senior; with poor names it reads as junior even when the candidate is mid-level.
Mistake 8: not asking questions at the end
The interviewer asks, "Do you have any questions for me?" You say, "No, I think you've covered everything." They tick the "lacks curiosity" box.
Three good questions to have ready:
- What does a typical week look like on this team?
- What is the team currently working on, and what is the biggest open challenge?
- How does the team handle code review and mentorship for juniors?
These are not just polite. The answers tell you whether you actually want the role.
Mistake 9: poor recovery from a bad answer
You give a wrong answer. You realise it. Instead of fixing it, you double down, defending the wrong answer because admitting fault feels worse.
The fix: when you realise you were wrong, say so. "Actually, I think I was wrong about that — the correct answer is…" This is treated as a strength. Pretending you were right is treated as a weakness.
Mistake 10: failing to follow up
You finish the interview, walk out, and never contact the company again. Three days later they make an offer to the candidate who sent a polite thank-you note.
The fix: within 24 hours, send a short email or LinkedIn message to your interviewer. Thank them, reference one specific thing from the conversation, restate your interest. It takes five minutes and tips close races your way.
Related: what hiring managers in Port Harcourt actually look for in juniors
