Stop Testing, Start Trying: Why Berlin's Hiring Process is Broken

Every engineer I hired at HERE Technologies and Uber is still there. In the Bay Area, where average engineering tenure is 18 months, that is not a coincidence. I did not achieve it with coding tests. I achieved it by hiring for judgment and investing in people after the hire.

I want to talk about what is broken in Berlin's hiring process, why AI has made the brokenness impossible to ignore, and what a saner approach looks like. This is not a theoretical argument. I have been on both sides — as an engineer who passed and failed screens, and as the person running them. The process was already wrong before ChatGPT launched. Now it is indefensible.

---

The Coding Test Was Always a Bad Signal

LeetCode was designed for computer science students studying data structures and algorithms. It measures whether someone can, under time pressure and artificial constraints, implement a binary search tree reversal or a dynamic programming solution to a knapsack variant. This skill is useful approximately never in production engineering.

I have worked with engineers who aced every screen and could not debug a race condition under real load. I have worked with engineers who would have failed every screen and built systems I still think about as examples of good design. The correlation between LeetCode performance and actual engineering judgment is weak to nonexistent. A decade of hiring data from companies who actually track this — Google included — confirms it.

The argument for screens was always probabilistic: even if they are noisy, they filter the tail. Fine. But that argument assumed the signal was something a candidate couldn't manufacture without the underlying skill. That assumption died sometime in 2023.

The defenders of coding tests now argue you should administer them with cameras, lockdown browsers, or live supervision. This treats senior engineers like exam cheats and creates an adversarial dynamic before the first day of work. You have already told this person, before they sign an offer, that you do not trust them. You are surprised when they leave in 14 months.

There is a more fundamental problem: the test is optimizing for the wrong thing. You are not hiring someone to pass tests. You are hiring someone to build things, make calls under uncertainty, mentor junior engineers, and stay when the project gets hard. None of that shows up in a LeetCode score.

---

The Job Description Is Fiction

I have written JDs. I have read hundreds of them. They are a snapshot of what someone believed the role required at a single moment in time, usually before any of the actual constraints of the project were known. By the time a candidate interviews, the role has drifted. The team composition has changed. The technical priorities have shifted. The JD describes a job that will not exist when the person starts.

The average JD asks for five to eight years of experience in a technology that has existed for three. It lists seventeen requirements for a role that one person cannot realistically fill. It was written by a recruiter who received a bullet-point list from an engineering manager who had 20 minutes to spare. It has been circulating on LinkedIn for six weeks without a single edit.

What you actually need when you hire an engineer is someone who can walk into the building, figure out where the fires are, and pick up a hose — without being told which fire is theirs. That is not a skill you can screen for with a requirements checklist. It is a disposition. You find it by talking to people, not by filtering resumes for keyword density.

The ten projects you need someone for in year one do not always exist when you write the JD. You are hiring for the range of judgment and curiosity someone brings, not for a fixed specification. Treating the JD as a filter means filtering for people who match a spec that is already obsolete.

---

Retention Beats Filtration. Every Time.

The Bay Area's average engineering tenure is 18 months. I have heard executives describe this as a feature — "fresh blood," "new energy," continuous turnover keeps the culture from going stale. This is cope. It is the rationalization of people who have given up on building something stable.

When a senior engineer leaves, they take with them:

• The context for every architectural decision made in the last two years
• The relationships with the rest of the team that make disagreements productive rather than destructive
• The implicit knowledge of what was tried, what failed, and why
• The mentorship relationship they had with two or three junior engineers who now feel abandoned
• Six months of the next person's productive time while they come up to speed

The total cost of losing a senior engineer is not the recruiter fee. The recruiter fee is a rounding error. The real cost is the tribal knowledge gap: the six months before the replacement is producing reliably, plus the knowledge that is simply gone — the kind that lived in one person's head and never got written down because there was never time.

Industry estimates put the total cost of replacing a senior engineer at one to two times annual salary. For a Berlin senior at €100K, that is €100-200K per departure, not counting the morale impact on the team that watched them leave. Every engineer who stays for four years instead of two has saved you that cost and compounded it with four years of deepening context.

The engineers who stayed at HERE and Uber stayed because they were treated as investments, not as fungible labor. They stayed because their curiosity was fed, because they were trusted with real problems, because the environment rewarded judgment over compliance. None of that came from the hiring process. All of it came from what happened after the hire.

You cannot buy retention with a better screening funnel. You build it after the offer letter.

---

Why Do You Want This Job? It's Money. That's Fine.

At some point in almost every interview process, someone asks the candidate why they want this particular job. The expected answer involves passion for the product, excitement about the company's mission, and cultural alignment. The real answer, for most people, is that they need to pay rent and this job offers a reasonable salary and a manageable commute.

There is nothing wrong with that answer. Work is a transaction. The engineer provides labor, judgment, and time. The company provides compensation and, ideally, interesting problems and good colleagues. Both sides know this. Performing enthusiasm about the company mission is a theater that wastes everyone's time.

Culture is not something you evaluate in an interview. Culture is something you build together over years of working through hard problems, disagreements, and the small moments where someone chose to help rather than ignore. You cannot buy cultural fit with a behavioral interview question. You cannot assess it in 45 minutes with a stranger.

What you can assess in an interview is whether this person asks good questions, whether they can explain their past decisions clearly, whether they are honest about what they do not know, and whether they seem like someone you would want to sit next to through a production incident at 2 AM. Those are the things that matter. They are not particularly well-served by "tell me about a time you showed leadership."

Stop screening for performance. Start screening for partnership. The difference is whether you are trying to catch someone out or trying to find out if you want to work with them.

---

If Their Resume Covers More Than a Year, They Already Survived a Trial

A candidate with four years of continuous employment at a previous company has already proven something meaningful: they were trusted, they produced, they got along with people well enough to stay, and they survived whatever crises that company went through. That is real information.

Making that person sit through a six-stage coding marathon to prove themselves again is not due diligence. It is signaling that you do not trust your own ability to read a track record. It is optimizing for the appearance of rigor over the substance of it.

Better questions do more than better tests. Ask them what they are most proud of building and why. Ask them what they got wrong and what they would change. Ask them what they are genuinely curious about right now. Ask them what kind of environment brings out their best work and what kind of environment kills it. Listen to how they answer, not just what they say. The answers will tell you more about judgment, honesty, and self-awareness than any algorithm problem.

The goal is not to verify that someone can perform under artificial stress. The goal is to find out whether working together would be good for both of you. That requires a conversation, not an examination.

---

The Berlin Comp Gap Is About to Close. Are You Ready?

In March 2026, Google opened its AI Center in Berlin-Mitte. The EU committed €5.5 billion to Germany through 2029 for AI infrastructure and research. This is not abstract. This is the beginning of a compensation inflection point that is going to force every Berlin tech company to reckon with what they are actually paying their engineers.

The numbers are not a secret. They are on levels.fyi. They are uncomfortable to look at if you are running a Berlin-scale startup:

Level	Berlin (typical)	FAANG Bay Area	FAANG Berlin (incoming)
Senior Engineer	€70–90K	$350–500K	€130–160K
Staff Engineer	€110–140K	$750K–1M+	€200–250K
Principal / Distinguished	€150–190K	$1.2M+	€300K+

The Bay Area gap has always been rationalized as a cost-of-living differential. Berlin is not cheap anymore. A three-bedroom apartment in Prenzlauer Berg costs what it costs in Amsterdam or Barcelona now. The cost-of-living story does not hold the way it used to.

What Google's Berlin presence signals is that the demand side of the Berlin engineering market is about to get dramatically more competitive. When a Staff engineer can choose between €130K at Google Berlin and €110K at your Series B, your hiring process had better be significantly more pleasant than Google's — not more onerous. Your culture, your mission, your ownership structure, your ability to make fast decisions — those are your differentiators. A six-stage LeetCode funnel is not.

The companies that adapt their compensation and their hiring approach now, before the pressure peaks, will be able to hire the engineers they want. The companies that wait will be competing for whoever is left.

---

The Recruiter Math Does Not Work

Standard recruiter commission in Berlin is 15 to 20 percent of first-year salary. On an €80K hire, that is €12,000 to €16,000 — paid to someone for sending you a resume and scheduling a call. On a €130K Staff engineer, that is €19,500 to €26,000. For an introduction.

I understand why this model exists. Hiring is time-consuming. A recruiter who surfaces ten good candidates saves you time you do not have. But the transaction optimizes for throughput and speed, not for fit and longevity. The recruiter gets paid whether the person stays for six months or six years. Their incentive is to close the placement, not to find someone who will still be there in three years.

There is an alternative: pay for the thing you actually want, which is a team that works.

A trial engagement costs roughly €10,000 per month. You get the actual output of the person's work, in your actual environment, with your actual codebase, alongside your actual team. At the end of 30 days you know things about this person that no amount of screening could have told you. The trial pays for itself in information value alone, before you count the work product. If it works out, you have a €10K cost to acquire someone with 30 days of verified context. If it does not work out, you have saved yourself the 18-month cost of the wrong hire.

For companies who need to rebuild or scale a team and want to stop throwing money at a broken process: a direct engagement with an experienced hiring manager — someone who has built teams at Uber and HERE, who has been on both sides of every screen, who knows what good judgment looks like in practice — costs less than three standard recruiter placements and delivers a team designed to stay. That is the math I offer at Westover Labs. You can see what it looks like at westoverlabs.de.

---

Culture Is Built, Not Bought

The best teams I have been part of did not happen because someone screened for "culture fit" in round three of an interview loop. They happened because a group of people who were curious, honest, and willing to disagree got into a room together with a hard problem and stayed there long enough to figure it out.

Culture is the pattern of how people behave when the official policy does not cover the situation. It is what happens when the system goes down at 11 PM on a Friday. It is what happens when the technical decision is genuinely unclear and two smart people disagree. It is what happens when a junior engineer makes a mistake. None of that is visible in an interview. All of it becomes visible in the first six months of working together.

You cannot hire culture. You can hire people who are likely to build something good together, and then create the conditions for them to do it. That means being clear about what you actually believe, giving people real problems and real ownership, being honest when things are hard, and paying people what they are worth so that money is not a constant low-grade source of resentment.

The companies that figure this out — and there are some in Berlin doing it well — do not talk much about culture. They talk about the work. The culture is the residue of the work done well together over time. You cannot buy it in a screen. You cannot install it with a culture deck. You build it, day by day, with the team you chose and the decisions you made after you hired them.

---

What to Actually Do

If you are a CTO, a hiring manager, or a founder who has read this and recognized your own process in the problems I've described, here is what I would do differently:

• Replace the coding screen with a paid take-home project tied to a real problem your team is working on. Pay for the work. You get better signal and you treat the candidate like a professional.
• Cut the number of interview rounds. Three is usually enough: one conversation to establish mutual interest, one technical discussion focused on past work and decisions, one conversation with the team they would join. Six rounds is not rigorous — it is insecure.
• Ask better questions. "Tell me about a decision you made that you still think about" generates more information than any algorithm exercise.
• Use trials when the role is senior and the risk is high. A 30-day paid engagement is better information than a six-stage process and cheaper than the wrong hire.
• Review your compensation against levels.fyi before you post the role, not after you lose a candidate to Google Berlin.
• Invest in the first 90 days as aggressively as you invested in the hire. The person who joins with good judgment and curiosity but without context will leave if you do not give them the context quickly enough.

None of this is complicated. Most of it is just treating engineers like adults who have alternatives, because they do.