Career
How to Prepare for Your First Technical Interview
The technical interview terrifies students mostly because it is unknown. Once you understand what actually happens in the room, and what the interviewer is actually judging, preparation becomes a concrete checklist instead of vague dread. This guide is written for someone facing their first junior developer interview.
What a junior interview actually contains
For junior roles, most interviews combine four ingredients in some proportion. There are fundamentals questions, spoken questions about your primary language and tools: what is the difference between an array and an object, what does this keyword do, what happens when you type a URL and press enter. There is a coding exercise: a small problem solved live, on a whiteboard, editor, or shared screen. There is a walk through your projects, where "tell me about something you built" is almost guaranteed. And there are behavioral questions: how you handled a conflict, a deadline, a mistake.
Notice what is usually absent at junior level: the notorious algorithmic puzzles from big tech companies. Some companies use them, but most junior interviews at normal companies test whether you genuinely understand the basics you claim on your CV.
A four-to-six week preparation plan
Weeks 1–2: fundamentals. Take your CV and interrogate it line by line: everything listed there is fair game, and "I wrote React on my CV but cannot explain state" is the most common way juniors fail. Search for the standard interview questions for your language and answer them out loud, not in your head. Speaking reveals gaps that silent reading hides.
Weeks 3–4: coding practice. Solve easy problems on a practice platform: a steady thirty to fifty easy problems builds more junior-interview readiness than ten hard ones abandoned in frustration. Focus on arrays, strings, and loops. Practice typing code without autocomplete at least a few times, since some interviews still use plain editors or whiteboards.
Weeks 5–6: your story and mock interviews. Prepare a two-minute walkthrough of your best project: the problem, your solution, one difficulty you overcame, one thing you would do differently. Then have a friend interview you for thirty minutes, seriously, or record yourself answering. Every first interview is partly wasted on nerves, and a mock interview spends that waste for free.
During the interview: think out loud
The single most important behavior in a coding exercise is narrating your thinking. Interviewers cannot grade what they cannot see, and a silent five minutes reads as an empty five minutes even if your mind is racing productively. Say the obvious things: "First I want to make sure I understand the input... my first instinct is a loop here... this handles the normal case, but an empty list would break it." An imperfect solution reached through visible, sensible reasoning routinely beats a perfect solution produced in silence, because the interviewer is hiring your reasoning, not that one answer.
Ask clarifying questions before you start coding. It is not a sign of weakness; it is what good engineers do with every task, and interviewers deliberately leave problems slightly vague to see who asks.
When you do not know the answer
You will be asked something you cannot answer. This moment is itself part of the test. The failing responses are bluffing (experienced interviewers detect it in seconds and it poisons everything after) and collapsing into apology. The passing response is honest and forward-moving: "I have not used that, but based on the name I would guess it does X. Am I close?" Curiosity under pressure is precisely the trait that makes juniors worth hiring, since nobody expects a junior to know everything.
After the interview
Rejections will happen, and they are noisier than they feel: good candidates are rejected constantly for reasons of timing, budget, and internal politics that have nothing to do with them. Treat every interview as a diagnostic: write down each question you struggled with while it is fresh, and fix those before the next one. Most people's fifth interview is dramatically better than their first, for reasons that have little to do with additional study. The practical conclusion: start interviewing earlier than feels comfortable. The readiness you are waiting for is mostly built in the interviews themselves.