Hiring a developer is not decided in a single technical interview. It is a series of steps, each led by a different person with their own criteria: the recruiter checks your fit with the role, the tech lead your way of reasoning, the team the way you work with them. Preparing effectively means knowing which step you are at and what it is trying to measure. This article describes the most common process in France, how to revise depending on the type of employer, and the role your resume plays in the questions you will be asked.
The steps of a developer recruitment process
The number of steps varies with the size of the company and the level of the role, but the structure is found almost everywhere.
- The screening call. A recruiter, in-house or from an agency, calls you for about twenty minutes. They check your availability, your salary expectations, your stack and your interest in the role.
- The interview with the manager or tech lead. This is often the first technical conversation. It covers your background, your recent projects and a few in-depth questions on the stack.
- The technical exercise. Depending on the company, it takes the form of a timed online test, a take-home assignment, a live coding or pair programming session, or, for experienced and senior roles, a system design interview.
- The debrief or team interview. You meet two or three team members, present your exercise or discuss a real problem. Collaboration is assessed as much as technical skill.
- The final conversation. With a CTO, an engineering director or an HR manager: company culture, medium-term plans, offer conditions.
In a startup, steps 2 to 4 may take place within the same half-day. In a large group or an IT services company (ESN), the order sometimes changes: the HR interview comes first, and a client interview is added when you are hired for a specific assignment.
What each step assesses
Each interviewer has a scorecard, explicit or not. Knowing theirs lets you answer the right question.
The recruiter assesses fit: does the role match your level, your stack, your expectations and your timing? They will not make you code, but they will note whether you can explain simply what you do. Prepare a two-minute presentation of your background that a non-technical person can understand, and a realistic salary range.
The tech lead assesses depth. They want to know whether you understand what you use, or whether you apply recipes. Their questions often start from a point on your resume and go one level deeper with each answer: "Why PostgreSQL rather than a document database? How did you choose your indexes? What happens when two transactions modify the same row?"
The technical exercise assesses your method as much as the result. Code that works but cannot be read, without tests and without an explanation of the choices, is rarely scored well. Conversely, an incomplete but well-structured solution, whose limits you explain, may be enough.
The team interview assesses collaboration: how you react to a comment on your code, how you ask a question, how you break down a problem with someone else. Future colleagues mostly ask themselves whether they want to review your pull requests.
The final conversation assesses motivation and long-term alignment. It is also when the offer is negotiated.
More and more companies formalise these scorecards: the same questions for every candidate, criteria scored separately, decisions made by several people. If you want to understand this logic from the other side of the table, the structured interview method as recruiters practise it 🔗 explains how these scorecards are built and why they reduce bias.
Revising according to the type of company
You do not prepare in the same way for an IT services company, a startup or a large software vendor. Expectations differ on three points: the type of exercise, the level of detail expected and the weight given to autonomy.
In an IT services company
IT services companies often hire for specific client needs. The technical interview is generally shorter and covers the fundamentals of the required stack: object-oriented programming, mainstream frameworks (Spring, Angular, .NET), SQL, unit testing. A written technical questionnaire or an online test is common. Revise the basics of your main language, the SOLID principles and common design patterns, and be ready to explain how you adapt to a new client environment.
In a startup or scale-up
Startups look for developers who can deliver quickly and on their own across a scope. The exercise is often a case close to their product, to be done at home or in live coding. Revise API design, relational database modelling, testing and deployment. Also prepare examples of situations where you made a technical decision without the full context, and what you learned from it.
At a large software vendor or an international tech company
Processes there are longer and more standardised. You will find algorithm exercises (data structures, complexity), system design interviews for experienced profiles and structured behavioural interviews. Revise classic data structures (hash tables, trees, graphs) and complexity analysis, and practise telling your experiences using a situation, action, result pattern.
If the exercise takes the form of a project to hand in, our article on the take-home technical test details what the team looks at when reviewing.
Whatever the type of employer, reread the job ad line by line and list the technologies and practices it mentions: they are the most likely topics of the interview.
Your resume, the starting point for the questions
Many candidates revise generic lists of questions and forget the most likely source of questions: their own resume. The tech lead has it in front of them. They are going to use it.
So reread your resume as an interviewer would, line by line, and prepare an answer to three questions for each item:
- What exactly did you do? Your personal share, not the team’s.
- Why did you do it that way? The options you ruled out and the reason for your choice.
- What would you do differently today? A question leads ask almost systematically, to measure your perspective.
Every technology listed in your skills must be able to sustain five minutes of discussion. If it cannot, remove it before sending your resume, or specify your level. Our article on presenting your tech stack explains how to avoid this trap from the writing stage.
Every figure must also be explainable. "Response time cut from 1.8 s to 0.4 s" will immediately trigger the question: measured how, on which endpoint, under what load? The junior developer resume template shows figures of this kind, precise and defensible.
A clear resume also makes the interview easier to run: the interviewer quickly finds the experience they want to discuss. A resume editor that handles the layout for you lets you focus on the content, and produces a document that recruitment software reads without errors. You can rework yours in the editor before applying.
Talking about a project in depth
Almost every process includes a question such as: "Tell me about a project you are proud of." It is the most predictable question, and yet the one most often fumbled, because the candidate stays on the surface.
Choose a project in advance, with three criteria: you played a central role in it, it involves at least one real technical difficulty, and you can talk about it without breaching a confidentiality clause. Then prepare your story in successive layers.
- The context in thirty seconds: the product, the team, the goal.
- Your role: what you designed, coded, decided.
- The architecture: the main components and how they communicate. Practise drawing it on a whiteboard or in an online diagram tool.
- The difficulty: a performance, data consistency, integration or migration problem, and how you solved it.
- The result and your perspective: what the project changed, what remains imperfect, what you would change.
The interviewer will interrupt you to dig deeper. That is a good sign: they are looking for the limit of your knowledge. When you reach it, say so clearly ("I did not work on that part, but I assume that…") rather than improvising. A lead far prefers an acknowledged limit to an invented answer.
For a senior profile, add one dimension: how did you involve the team, document decisions, support the other developers? The tech lead resume template shows how to present these responsibilities without losing sight of the technical side.
The questions to ask the team
The end of each interview gives you the floor. Do not waste it on questions whose answer is on the company website. Good questions show your interest and give you useful information for your decision.
A few questions that work well with a technical team:
- On delivery: how does a production release work? How often? Who can deploy?
- On quality: how are code reviews organised? What role do automated tests play?
- On technical debt: which part of the code is the team least proud of, and is there a plan to deal with it?
- On on-call and incidents: who gets called when production goes down? How are post-incident reviews run?
- On onboarding: what will my first three months look like? When will I be able to ship my first change?
- On the team: how are architecture decisions made? How do product and engineering work together?
Write down the answers. They will help you compare two offers, and they will feed your final conversation if you move forward in the process.
Frequently asked questions
How long does it take to prepare for a technical interview?
It depends on how familiar you are with the stack and on the type of exercise. For a role close to your daily work, a few evenings are often enough: reread your resume, revise the fundamentals of the stack in the ad and rehearse the story of a project. For a process with algorithms or system design, plan several weeks of regular practice.
Do I need to know the classic questions by heart?
No. Reciting a memorised definition shows immediately, and the interviewer will ask a follow-up question. It is better to understand the concepts well enough to explain them in your own words and relate them to a situation you have experienced.
What should I do if I get stuck during an exercise?
Say so out loud and explain where you are: what you have understood, what you are trying, what is blocking. The interviewer can unblock you with a hint, and above all they note how you react to a difficulty.
Can I turn down a take-home exercise that is too long?
You can ask whether a shorter version exists or suggest another format, such as a pair programming session. Many companies are willing to discuss it, especially for an experienced profile. If they refuse, that is also information about their culture.