In short
- A software engineer interview usually has several rounds, and each one tests something different. Prepare per round, not with one big list.
- In coding and system design rounds, the interviewer can only assess the reasoning you say out loud. A correct answer given in silence tells them little.
- Behavioral and team-fit rounds count too. Prepare real stories with a clear result, just as you prepare algorithms.
Contents
- How a software engineer interview is structured
- Recruiter screen questions
- Coding interview questions
- System design interview questions
- Behavioral interview questions for engineers
- Team and culture fit questions
- Interviewing for a software engineer job in Germany
- Practise each round out loud
- FAQ
You solve the problem at home in twenty minutes. In the interview, someone watches, the clock runs, and you go quiet for five minutes before writing the first line. The knowledge was there. The interviewer just could not see it.
This guide sorts the most common software engineer interview questions by round: recruiter screen, coding, system design, behavioral and team fit. For each round you get typical questions, what each one tests, and how to prepare. Three illustrative example answers show what a strong answer sounds like.
How a software engineer interview is structured
The number and order of rounds differ between companies, team sizes and seniority levels. The pattern below is common, not a fixed process. Ask the recruiter which rounds you will have. That question is normal and saves you guesswork.
| Round | Typical format | What it tests |
|---|---|---|
| Recruiter screen | 20 to 30 minute call | Motivation, basic fit, salary range, availability |
| Coding | Live coding or a take-home task | Problem solving, data structures, code quality, communication |
| System design | Whiteboard or online diagram | Architecture, trade-offs, scaling, handling vague requirements |
| Behavioral | Conversation with a manager or senior engineer | Ownership, collaboration, conflict, learning from mistakes |
| Team and culture fit | Meeting the team or a lead | How you work day to day, what you need, your questions |
Junior roles often lean more on coding. Senior roles usually add more weight to system design and to behavioral questions about decisions and influence.
Recruiter screen questions
The recruiter screen is short and often not technical. It decides whether you move on, so treat it as a real interview.
| Question | What is being tested |
|---|---|
| Tell me about yourself. | Whether you can summarise your background in two minutes, focused on this role |
| Why are you interested in this role? | Whether you read the job ad and have a specific reason |
| What tech stack have you worked with most? | Whether your experience matches the core requirements |
| What are your salary expectations? | Whether you are within the budget for the role |
| When could you start? | Notice period and availability |
Prepare a two-minute version of your background that ends with why this job is the next logical step. Have a salary range ready that you have researched for the role and location.
Coding interview questions
Coding rounds test more than whether your code runs. Interviewers watch how you get there: do you clarify the problem, choose a sensible approach, name the complexity and test your own code?
| Question | What is being tested |
|---|---|
| Reverse a linked list. | Pointer handling, edge cases such as an empty list or a single node |
| Find duplicates in an array. | Time vs space trade-offs, for example a nested loop vs a hash set |
| Check if two strings are anagrams. | Choosing the simplest correct approach, asking about case and whitespace |
| Detect a cycle in a linked list. | Knowing the fast and slow pointer technique and why it saves memory |
| Find the kth largest element. | Picking the right tool, such as a heap, instead of sorting everything |
How to work through a coding question
- Restate the problem in your own words.
- Ask about inputs, constraints and edge cases before writing code.
- Name a simple approach first, then a better one, with time and space complexity.
- Write the code while explaining each step.
- Walk through one normal case and one edge case by hand.
Interviewers often leave a question vague on purpose. Asking clarifying questions is part of the task, not a delay.
The interviewer can only assess the reasoning you say out loud.
Example answer: find duplicates in an array
The example below is illustrative. It shows how a strong spoken answer sounds, not a script to memorise.
"Before I start: can the array be modified, and is memory limited? A nested loop would work in O(nΒ²) time, but it gets slow on large inputs. With a hash set I can do it in O(n) time and O(n) extra memory. If extra memory is not allowed, I could sort first: that is O(n log n) time and no extra structure. Which constraint matters more here?"
The answer names three options, gives their cost and asks the interviewer to choose.
How to prepare for coding rounds
Do not try to memorise individual problems. Learn the recurring patterns instead: two pointers, sliding window, hashing, binary search, breadth-first and depth-first search, heaps and dynamic programming. Once you recognise the pattern, most problems become variations.
Practise while speaking. Solving silently at your desk builds a different skill from the one the interview assesses.
System design interview questions
System design rounds are open on purpose. There is no single correct answer. The interviewer wants to see how you structure a vague problem and how you reason about trade-offs.
| Question | What is being tested |
|---|---|
| Design a URL shortener. | Clarifying requirements, key generation, choosing a data store, read-heavy scaling |
| Design a news feed. | Fan-out on write vs on read, caching, accounts with many followers |
| Design a rate limiter. | Algorithms such as token bucket, where to place it, shared state across servers |
| How would you scale a service from 1,000 to 1,000,000 users? | Reasoning in stages and naming the bottleneck at each stage |
| Design a chat system. | Real-time connections, message ordering, offline delivery |
A five-step frame for any design question
- Clarify requirements: who uses it, what it must do, expected scale.
- Sketch the high-level design: main components and how data flows.
- Go deeper on one or two parts: data model, API, the hardest component.
- Discuss trade-offs: consistency vs availability, cost vs latency.
- Name failure points and what you would monitor.
Example answer: design a rate limiter
The example below is illustrative and shortened. A real answer would take much longer and include a diagram.
"First, a few questions: are we limiting per user or per IP, and how many requests per minute? Is this one service or many? I would start with a token bucket, because it allows short bursts but keeps the average rate fixed. I would place it at the API gateway, so every service is protected in one place. With several gateway instances, the counters need shared state, for example in an in-memory store. That adds a network call per request, so the trade-off is accuracy against latency. If a few extra requests are acceptable, local counters with periodic sync would be faster."
In system design, the trade-off you name matters more than the technology you pick.
Behavioral interview questions for engineers
Many engineers spend weeks on algorithms and an evening on behavioral questions. That is a risk: these questions show how you work with people, handle pressure and take ownership. They are usually best answered with the STAR method: Situation, Task, Action, Result.
| Question | What is being tested |
|---|---|
| Tell me about a technical disagreement with a teammate. | Persuading with evidence, keeping the relationship intact |
| Describe a production incident you helped resolve. | Staying calm, debugging method, follow-up to prevent repeats |
| Tell me about a time you learned a new technology quickly. | Learning approach and how fast you became productive |
| Describe a time you disagreed with a deadline or product decision. | Raising concerns professionally, then committing to the decision |
| Tell me about a mistake you made. | Honesty, ownership, what you changed afterwards |
Example answer: a technical disagreement
The example below is illustrative, not taken from a real candidate.
- Situation: A teammate and I disagreed about adding a message queue between two services.
- Task: We needed one decision before the design review that week.
- Action: I built a small benchmark of both approaches under the expected load and shared the results in the review, including where my option was weaker.
- Result: The team chose the queue. I wrote a short decision record so later engineers could see why.
The strong part is the action: it is specific, it uses data instead of opinion, and the result shows what changed.
Before the interview, prepare five to seven real stories that cover conflict, an incident, ownership, a mistake and learning something new. Then you adapt a story to the question instead of inventing one under pressure.
Team and culture fit questions
This round often feels like a conversation. It still counts. The team wants to know how you work day to day and whether you would work well together.
| Question | What is being tested |
|---|---|
| How do you approach code reviews? | Giving and receiving feedback constructively |
| How do you work with product managers and designers? | Collaboration beyond engineering |
| What kind of team environment helps you do your best work? | Self-awareness and fit with how this team works |
| How do you handle unclear requirements? | Asking questions early, making assumptions visible |
| What do you want to learn in your next role? | Motivation and whether the role can offer that |
At the end you will usually be asked if you have questions. Prepare two or three specific ones, for example: "How does the team decide what to refactor?" or "What does a typical first month look like in this role?"
Your questions at the end are part of the interview, not a formality.
Interviewing for a software engineer job in Germany
The rounds above apply in Germany too. A few topics come up more often or need extra preparation:
- Salary expectations: you may be asked for a figure early, sometimes already in the application. Name a researched annual gross range.
- Notice period: German employment contracts often have notice periods of several weeks or months. Know yours, because it decides your start date.
- Probation period: a probation period (Probezeit), often up to six months, is standard in German contracts. It is not a sign of distrust.
- Language: many tech teams work in English. Still, be ready to say honestly how good your German is and how you use it at work.
- Work permit: if you need a visa, say so clearly and early. Recruiters can plan around it.
Practise each round out loud
Reading questions prepares your knowledge. The interview tests whether you can explain that knowledge clearly while someone listens. You only close that gap by answering out loud.
A TalentVP mock interview has seven questions. The first is an opening question, and in the last one you ask the questions. The five in between are generated from the job title, your seniority, the job ad and your previous answers. You can type or speak your answers. Spoken answers are transcribed and assessed as text. Interviews run in English, German or Turkish.
After each answer you get a score from 0 to 100, strengths, areas to improve and a model answer. You can choose STAR, PAR or CARL as the answer structure. Your dashboard shows past interviews and how your scores change. A free account includes your first mock interview.
A short preparation plan
- Ask the recruiter which rounds you will have.
- For coding, practise patterns while speaking, and state the complexity every time.
- Walk through one complete system design out loud, from requirements to trade-offs.
- Write down five to seven STAR stories and practise them until each takes about two minutes.
- Prepare two questions for the team.
For behavioral rounds in depth: How to Answer Behavioral Interview Questions Using the STAR Method explains each step with examples.
