The Modern Technical Interview Playbook

You passed the HR round. Your CV survived the initial screening. Now comes the round most developers dread: the technical interview. And here’s the paradox. Most candidates prepare for the wrong thing.

They spend weeks on LeetCode. They memorize sorting algorithms they haven’t used since university. Then they sit in the interview, solve the coding task cleanly, and still get rejected. What happened?

The technical interview doesn’t test whether you can code. The company already knows that from your CV and work experience. It tests how you approach problems, how you communicate while thinking, and whether you ask the right questions before diving in. Those who treat the interview as an academic test lose to candidates who treat it as a business conversation.

This guide covers the five technical interview formats most commonly used at German tech companies, what each one actually evaluates, and the concrete strategies you can use to win every round.

The Context Trap: Why Good Developers Fail🔗

The most common reason for rejections in technical interviews isn’t the code. It’s the missing context.

Imagine this scenario: You get a system design task. “Design a URL shortener.” You jump right in, drawing load balancers, databases, caching layers. After 45 minutes you have an impressive architecture diagram. And a rejection.

Why? Because you didn’t ask a single question. How many URLs per second? How long do the shortened URLs need to remain valid? Are there compliance requirements? The interview wasn’t testing your technical knowledge, it was testing whether you understand that every architectural decision depends on requirements you need to clarify first.

This context trap exists in every format. In take-home assignments, candidates deliver perfect code but forget to explain why they made certain trade-offs. In pair programming, they solve the problem but in silence, without involving the interviewer in their thought process. In PR reviews, they comment on indentation errors and miss the absent error-handling strategy.

The pattern is always the same: the technical competence is there, but the ability to embed it in a business context is missing. And that’s exactly what separates the candidate who gets the offer from the one who receives a rejection without concrete feedback.

The Five Formats You Need to Know🔗

German tech companies don’t all use the same interview format. Startups often favor pair programming or take-home assignments, corporations prefer structured coding tests, and scale-ups frequently combine multiple formats. The good news: there are only five fundamental formats, and if you understand each one, you can prepare for anything.

Most hiring processes combine two to three of these formats. A typical flow: first an online coding test as a filter, then either pair programming or a take-home, and for senior roles an additional system design round. Knowing which format awaits you changes your entire preparation.

Format 1: The Async Coding Test🔗

What to Expect🔗

You receive a link to a platform like HackerRank, Codility, or CoderPad. The tasks are algorithmic: sorting arrays, parsing strings, traversing graphs. You typically have 60 to 90 minutes for two to three tasks.

This is the round that most closely resembles LeetCode, and at the same time the round where most candidates make the fewest mistakes. The tasks are rarely more complex than “Medium” on LeetCode. The company doesn’t want algorithm geniuses. It wants to filter. Out of 200 applications, maybe 50 can be invited to the coding test, and 15 to 20 of those should advance.

How to Win🔗

The biggest mistake is starting to code immediately. Read the problem statement twice. Identify the edge cases before writing your first line: empty arrays, negative numbers, strings with special characters. Many platforms evaluate not just whether your code works, but whether it covers all edge cases.

Focus on clean naming. Variable names like temp, x, arr signal that you treat the code as throwaway. Variables like filteredUsers, maxRetryCount, isEligible signal production habits.

Time management is crucial. If you’re stuck on a task after 20 minutes, move on to the next one. One fully solved task and one half-solved one is better than one perfect one and two empty ones.

What Most People Get Wrong🔗

Over-engineering. A 90-minute async test is not the place for design patterns, dependency injection, or custom utility classes. Solve the problem directly. The elegance of your solution is measured by readability, not abstraction.

Format 2: The Take-Home Assignment🔗

What to Expect🔗

You receive a task that resembles a real work problem: building a small API, implementing a frontend with specific requirements, writing a data import process. You typically have three to five days, sometimes a week. The estimated work time is three to eight hours.

This format is popular with German startups and mid-sized companies because it’s closer to actual work than an algorithm test. It doesn’t test whether you can traverse a graph under time pressure, but whether you write code that someone else can still understand and maintain six months later.

How to Win🔗

The take-home has a hidden evaluation criterion that appears nowhere in the task description: your README. A take-home without a README is like a pull request without a description. The reviewer (your future colleague) opens the repo and immediately wonders: What does this do? How do I start it? What decisions did the person make and why?

Your README should have three sections:

Setup instructions. How the reviewer gets the project running. Docker Compose is ideal because it requires no dependencies on the local machine. A simple docker-compose up and the project runs.

Architecture decisions. Why did you choose this stack? Why this database schema? Where did you deliberately avoid complexity, and where would you have decided differently in a production system?

Trade-offs. What would you do differently with more time? What’s missing that would be needed in a production environment? This honesty is a strong seniority signal. A junior developer submits code and hopes it’s good enough. A senior developer explains where the limitations are.

What Most People Get Wrong🔗

Investing too much time. If the task estimates four hours and you’re still adding features after eight, you’ve missed the point. The task evaluates your ability to make pragmatic decisions within limited time. Delivering a gold-plated project signals that you’ll overrun tickets in daily work.

The other common mistake: no tests. You don’t need 100% coverage. But delivering a project entirely without tests is a red flag at any experience level. Three to five meaningful tests for the core logic show that you see testing as part of the development process, not as a chore.

Format 3: Live Pair Programming🔗

What to Expect🔗

You sit with a developer (your potential future colleague) in a video call or in front of a shared screen. You solve a problem together. It could be a bug hunt, a feature implementation, a refactoring, or a small task from scratch.

This format is especially popular with German startups because it comes closest to daily work. It tests not just whether you can write code, but whether people want to work with you.

How to Win🔗

Think out loud. This is the most important rule in pair programming, and simultaneously the hardest to implement. Many developers are used to solving problems quietly in their heads. In the interview, the interviewer needs to be able to follow your thought process. Not because they want to help you (though that happens too), but because they’re evaluating how you approach problems.

Concretely, this means: “I see that the function returns an integer, but the caller expects a string. My first instinct would be to change the return type, but let me first check whether other places use the same return value.”

This isn’t talking to yourself. It’s professional communication. You’re showing that you check impacts before making changes. You’re showing that you work systematically rather than guessing.

Equally important: show how you handle feedback. When the interviewer says “Have you considered a different approach?”, that’s not a hint that your approach is wrong. It’s an invitation to demonstrate flexibility. The best response: “Interesting, what do you have in mind?” Then weigh whether the alternative approach is a better fit, and explain your assessment.

What Most People Get Wrong🔗

Silence. Typing for ten minutes without saying a word is the biggest red flag in pair programming. Even if you’re thinking, say so: “I’m currently considering whether we need a map or a set here. Give me a moment.” That’s a hundred times better than silence, because now the interviewer knows you’re thinking, not stuck.

The other mistake: completely ignoring the interviewer. Pair programming is a dialogue. When the interviewer asks a question or makes a suggestion, respond to it. Candidates who block the interviewer’s input signal that they’re difficult to work with in a team.

Format 4: The PR / Code Review🔗

What to Expect🔗

You receive a pull request with code that you need to review. Sometimes it’s real production code (anonymized), sometimes it’s written specifically for the interview, with intentional bugs and areas for improvement. You have 30 to 45 minutes to write your comments and then discuss them with the interviewer.

This format is becoming increasingly popular in Germany, especially for mid-level and senior positions. It tests something no coding test can capture: how do you behave when evaluating someone else’s work?

How to Win🔗

The most important resource for this format is the Code Review Pyramid. The concept: the lower an issue sits in the pyramid, the more important it is. API design and architecture form the base. Implementation details and performance sit in the middle. Code style and formatting are at the top, least important.

The most common mistake in PR review interviews is focusing on the top of the pyramid. Indentation, naming conventions, missing semicolons. Most companies automate these things with linters and formatters. If your review consists only of such nitpicks, you signal that you can’t see the big picture.

Focus your energy on the base:

API semantics. Are the endpoints sensibly named? Does the POST request return the correct status code? Is input validation missing?

Error handling. What happens when the database connection drops? Is there retry logic? Are errors logged, or do they disappear silently?

Security. Are user inputs escaped? Are there SQL injection vectors? Are secrets exposed in the code?

Architectural impact. Does this change introduce a circular dependency? Does it break the existing interface? Is it backward compatible?

Phrase your comments as questions, not commands. “Could a race condition occur here if two requests come in simultaneously?” comes across as more competent than “This is wrong, you need a lock here.” Both identify the problem. But the question additionally signals empathy and collaboration, qualities a future colleague should bring.

What Most People Get Wrong🔗

Only commenting on negatives. A good code review also contains positive remarks. “Nice abstraction here” or “Good decision to extract this as a separate service class” shows that you recognize good code, not just bad code. This sounds trivial, but it’s a strong signal. Teams want colleagues who acknowledge good work, not just find mistakes.

Format 5: System Design🔗

What to Expect🔗

You receive an open-ended task: “Design a notification system”, “How would you build a real-time chat application?”, “Design an architecture for an e-commerce checkout.” You have 45 to 60 minutes to sketch and discuss a solution.

This format appears mainly for mid-level and senior positions. For junior roles, it’s sometimes replaced by a simplified variant: “Explain how you structured the architecture of your last project.”

How to Win🔗

Ask first. Before you draw even a single box on a whiteboard, ask clarifying questions. Not as performance, but because the answers will fundamentally change your design.

The most important questions:

• “How many users should the system serve? Hundreds, thousands, millions?”
• “What latency requirements exist? Real-time or is slight delay acceptable?”
• “Does the system need to build on existing infrastructure? Which cloud provider do you use?”
• “Are there regulatory requirements? GDPR, data residency in the EU?”

These questions show something no architecture diagram can: you understand that technology doesn’t exist in a vacuum. Every architectural decision is a business decision. A system for 100 users looks fundamentally different from one for 10 million.

After clarifying the requirements, work top-down. Start with the high-level overview: client, API gateway, services, database. Then dive deeper into the components where you’re strongest or that are most critical for the task. You don’t need to design every component in detail. The interviewers want to see that you can set priorities.

The Brownfield Rule🔗

Most company projects are not greenfield developments. You’re not building on a blank slate. You’re integrating into existing systems. Showing that you understand this is an enormous signal.

Instead of saying “I would introduce a new database here”, ask: “What database do you currently use? Can we co-use the existing instance, or is there a reason to set up a separate one?” This shows that you understand the cost of complexity. Every new component you introduce into a system needs to be maintained, monitored, and operated. Experienced developers know this.

What Most People Get Wrong🔗

Drawing too much, talking too little. System design is a conversation, not an architecture workshop. The interviewer doesn’t want to watch you complete a diagram for 45 minutes. They want to discuss with you. “I would use Redis as a cache here because the read load is significantly higher than the write load. Alternatively, we could put a CDN layer in front, but that would make cache invalidation more complex. What do you think?”

That’s the difference between a candidate who can do system design and one who demonstrates it.

The Meta-Strategy: What All Formats Have in Common🔗

Regardless of format, three principles apply in every technical round.

Ask Questions Before You Start🔗

In every format, the first question you ask is worth more than the first line of code you write. In the coding test: “Can the input be empty?” In pair programming: “Are there existing tests I shouldn’t break?” In system design: “What does the current load look like?” Questions signal that you understand that clarifying requirements is a developer’s most important task.

Communicate Your Thought Process🔗

Silence is your enemy in every interview format. Even when you’re thinking, say what you’re thinking. “I’m currently considering whether a recursive approach would be more efficient here, or whether I should take the iterative variant to avoid blowing up the stack.” This gives the interviewer insight into your thinking and the opportunity to give you a hint if you’re heading into a dead end.

Show Pragmatism, Not Perfection🔗

No interviewer expects a production-ready solution in 45 minutes. What they expect: that you know where the limitations of your solution lie, and that you communicate them. “In a production system, I would add retry logic and a circuit breaker here. For the purposes of this interview, I’ll skip that and focus on the core logic.” That’s a stronger signal than trying to implement everything and ending up with a half-finished pile of code.

Preparation: The Concrete Plan🔗

Find Out What Awaits You🔗

Before investing even a minute in preparation, find out which format the company uses. The job posting sometimes gives hints. Kununu reviews and Glassdoor interview reports are often more informative. The most direct approach: ask the recruiter or HR person during the screening call. “Can you describe how the technical interview round works?” is a perfectly legitimate question that every company will answer.

How to strategically use recruiters as an information source is covered in detail in our guide to recruiter intelligence.

Practice the Right Format🔗

If you know pair programming awaits you, solving a hundred LeetCode problems won’t help much. Instead, practice thinking out loud while coding with another person. If a system design interview is coming up, draw three to five different architectures on a whiteboard and explain them to someone outside the tech field. If you can explain your approach to a non-technical person, you’ll be able to explain it to an interviewer too.

The Preparation Timeline🔗

For most developers, two to three weeks of focused preparation is enough. Not eight hours a day, but one to two hours, consistently.

Week 1: Refresh the fundamentals. Data structures, algorithms, Big-O notation. Not because you need them daily at work, but because they come up in coding tests. Solve ten to fifteen LeetCode problems at “Medium” level in your target language.

Week 2: Format-specific preparation. If system design is coming up, work through three to five classic tasks (URL shortener, chat system, news feed). If pair programming is ahead, practice with a friend or colleague. If a take-home is likely, build a small project with a clean README and tests.

Week 3: Mock interviews. Real practice under realistic conditions. Set a timer, turn on the camera, simulate the situation with another person. This is the part that helps the most and that almost nobody does.

How CodingCareer Prepares You for the Technical Interview🔗

Knowing the theory from this article gets you a good distance. But there’s a gap between “I know I should think out loud” and actually doing it when a stranger is on the other side of the video call and you’re nervous. You only close that gap through practice under realistic conditions.

CodingCareer’s mock tech interviews are conducted by developers who have themselves led and passed technical interviews at German companies. The session simulates the actual format: 45 minutes of live coding or system design, followed by 15 minutes of detailed feedback. You learn not just whether your solution was correct, but how your communication came across, where you forgot context, and what signals you unconsciously sent. The session is recorded so you can analyze it afterwards.

The Junior Kickstart package combines application strategy, CV optimization, and tech interview preparation including LeetCode coaching for career starters. For experienced developers aiming for a senior position or a salary jump, The Salary Jump covers tech interview prep, system design preparation, and salary negotiation. The High-Pay Tech Strategy package goes further: two mock interviews (tech and system design), advanced salary negotiation, and personal branding.

The pay-on-success pricing model ensures CodingCareer’s incentives align with yours. You pay a reduced rate upfront and the rest only when you get the job. If you don’t get hired, the coach doesn’t receive their full fee.

Book your free 15-minute diagnostic call and find out which interview formats await you and how to prepare for them effectively.