BettercallPaul Software Engineer Interview Guide

The 60-second brief

Candidate reports describe BettercallPaul only through its engineering role. The Software Engineer title covers Senior Software Engineer and Software Architect levels, and the reports speak of technical operations and a service landscape without naming a product, customer or technology stack. The responsibilities candidates describe are hands-on development, code reviews, mentoring junior engineers, spotting technical debt, and working with product managers and cross-functional teams to turn business goals into technical plans. Treat the company's products as unknown and prepare for the engineering work itself.

This guide is for engineers interviewing for a Software Engineer position at BettercallPaul, from experienced developer up to senior or architect level. It covers the three reported rounds, the three behavioral questions candidates report, the reported topic areas (software architecture, backend engineering, algorithms and data structures, technical communication) and a seven-day plan.

Candidates report three stages over roughly 3-5 weeks: Technical Screening, Coding Evaluation and Deep-Dive Discussions. The three questions reported by title are all behavioral, and the technical content is described by topic area rather than by problem.

Focus areas

• Software Architecture
• Backend Engineering
• Coding Challenges / Algorithmic Problem Solving

Overview

Reports describe a loop of three stages over roughly 3-5 weeks: Technical Screening, Coding Evaluation and Deep-Dive Discussions. The three questions candidates report by title are about judgment, not puzzles: whether salary is the most important benefit, a time you defended a technical architectural decision, and how you handle ambiguous or shifting requirements. Because no coding problem is reported by name, your coding preparation has to come from the topic areas rather than from a known question list.

The topic areas candidates list are software architecture, backend engineering, coding challenges and algorithmic problem solving, data structures and algorithms, and technical communication. The example scenarios reported alongside them are concrete: walk through a recent technical challenge and the trade-offs you made, refactor legacy code while the system stays up, design for a stated number of concurrent requests, and keep data consistent across distributed services. Each one is a structured answer you can rehearse: state the constraints, name two or three options, pick one, say what it costs, and say how you would check it works.

Reports name Senior Software Engineer and Software Architect as levels, and the requirements candidates describe are core backend technologies, distributed systems and architecture design, with cloud-native infrastructure, CI/CD and leading a project from concept to deployment as extras. No programming language is named, so do the coding practice in the language you know best and be ready to explain why you wrote it that way. Plan your time around three things: two deep project stories, a short set of architecture trade-off comparisons you can give without notes, and regular timed coding practice with the complexity and tests said aloud.

The BettercallPaul interview process

Candidates describe three stages, with the whole process taking roughly 3-5 weeks. Each stage is reported with a one-line description only, so the preparation below is built from the reported topic areas and example scenarios.

Technical Screening

Candidates describe Technical Screening as an initial assessment of your technical skills and knowledge. No further format detail is reported, such as whether it is live or written, so prepare for a broad check. Be ready to summarise your recent backend and architecture work, defend the main choices in it, and answer fundamentals questions across the listed areas: software architecture, backend engineering, and data structures and algorithms. Practise giving a short answer first, then adding the trade-off.

What to demonstrate

• Breadth of technical knowledge across the reported topic areas
• How clearly you can summarise your own recent work
• Whether your technical choices come with stated reasons

How to prepare

• Write a one-paragraph summary of each of your last two projects: the data store, the service boundaries and the one decision you would defend.
• Rehearse short comparisons of SQL against NoSQL and of a monolith against microservices, each ending with the use case that tips the choice.
• Refresh complexity for the structures you use daily: hash maps, heaps, balanced trees, queues and sorted arrays.
• Practise stating the cost of a design choice in the same breath as the choice.

Coding Evaluation

Candidates describe Coding Evaluation as hands-on coding tasks that demonstrate your coding abilities. No language, platform, task count or take-home format is reported, so be ready to write working code in your strongest language. The reported topic areas that fit this stage are coding challenges, algorithmic problem solving, and data structures and algorithms, together with complexity analysis and production-ready code. If you get stuck, say your reasoning aloud, which is the tip candidates repeat.

What to demonstrate

• Working code on a hands-on task
• Choice of data structure and algorithm, with complexity stated
• Readable code and the edge cases you test

How to prepare

• Run every practice problem the same way: restate the input, give the brute force, improve it, state time and space, then list tests.
• Keep a standing test list: empty input, one element, duplicates, maximum size, and the input that hits the branch you just wrote.
• Practise debugging a distributed-system symptom aloud, since debugging strategies for complex distributed systems are a reported topic.

Deep-Dive Discussions

Candidates describe Deep-Dive Discussions as in-depth conversations about your past projects and experiences. A reported tip is to bring at least two deep-dive examples from your own work, one about a technical failure and one about a significant system design challenge. Build each as a technical narrative: the context, the constraints, the options you rejected, the decision, the result and what you would change. The reported example scenarios, such as refactoring legacy code without downtime or keeping data consistent across services, are good material for these stories.

What to demonstrate

• Depth of your account of past projects and experience
• The reasoning behind your technical choices
• How you explain technical concepts to different audiences

How to prepare

• Write both deep-dive stories with numbers attached: load, latency, error rates, team size or time saved, whichever you can defend.
• For each story, list the two alternatives you rejected and the constraint that ruled them out.
• Prepare a plain-language version of one architecture decision, the way you would explain it to a product manager.
• Outline how you would refactor a legacy component while it stays in service: a seam, a flag or a parallel run, a rollback path and a way to measure.

Where candidates lose points

Treating the salary question as a trap and giving a slogan or a dodge

Take a position in one sentence and back it with a real career decision where you weighed pay against scope, team or learning. Rehearse it in German and in English, and keep it about priorities, not a negotiation.

Describing an architectural decision without naming the alternatives you rejected

For the story about defending a decision, name the constraint, two options you turned down and the reason for each, who disagreed, and what evidence settled it. 'It was the standard approach' is not a defence.

Giving a design answer with no trade-off attached, such as picking NoSQL, microservices or a cache with no stated cost

Attach a cost to every choice as you make it: what the pick makes harder, where data can be stale, what fails when a dependency is down. Practise on SQL against NoSQL, monolith against microservices, and consistency across services.

Going quiet when stuck in the coding evaluation, or finishing with no complexity and no tests

Narrate your reasoning, say the brute force and its cost before improving it, then state time and space and list your tests: empty, single element, duplicates, maximum size.

Telling project stories in the plural so your own contribution cannot be separated from the team's

For each deep-dive story, write down what you decided, what you built and what you would change. Have one technical failure and one design challenge ready, each with a number.

Questions & practice

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

1. One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
2. Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
3. Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
4. If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

• The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
• How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

• A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
• Where does the fingerprint get computed relative to request decompression and the body-size limit?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

• The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
• How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

• Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
• Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

Tell us about a time you had to defend a technical architectural decision.

Medium · Behavioral and Values

Approach

1. Pick a decision you owned that had real alternatives, such as keeping a modular monolith instead of splitting into services, or choosing a relational database over a document store. Open with the constraint that forced the choice (consistency requirement, expected load, team size, deadline) in one or two sentences.
2. Name at least two options you rejected and give each a concrete trade-off. Splitting into services adds network hops, partial failure and cross-service consistency work (sagas or a transactional outbox), while a monolith couples deploys and scaling. A relational schema gives multi-row transactions and joins. A document store gives flexible schemas and key-based reads, but joins move into application code.
3. Show the evidence you used: a load test or prototype with the numbers it produced, latency or cost estimates, and a written decision record (context, options, consequences). Say who challenged the decision and state their strongest argument fairly before you explain why you still held your position.
4. Explain how the disagreement ended: what you conceded, who made the final call, and the measurable condition that would trigger revisiting it, such as a throughput threshold, a team-size change or a new consistency requirement.
5. Close with the outcome you measured after it shipped and what you would change now. If the decision later proved wrong in part, say so and say what you reversed. Defending a decision includes knowing when to drop it.

Follow-up

• What data would have changed your mind, and did you check that data after launch?
• If traffic grew tenfold or the team doubled, would the same decision still hold, and what would you change first?
• How did you explain this trade-off to a stakeholder without a technical background?

Publish rate-limit and deadline semantics the edge actually enforces

Easy · rate limiting · backpressure · retries

The edge API serves about 3k requests/second steady and 9k at peak against a 400 ms p99 budget, with an explicit bounded concurrency limit per instance. Limits exist per principal and per tenant. Callers are a partner integration running nightly bulk loads and a browser app. Specify the counting algorithm and window, which limit a request is charged against, the headers a well-behaved client reads, the status and body when a limit is hit, how that differs from the response when an instance is shedding load, and what each caller does with each.

Approach

1. Choose the counter and name its failure mode. Fixed windows admit nearly twice the limit across a boundary - a full burst at the end of one window and another at the start of the next. A token bucket states sustained rate and burst separately, which is exactly what a nightly bulk load needs. A sliding-window counter is more faithful and costs more state per key. State the choice and the burst it permits.
2. Charge each request against both keys and reject on the stricter. The tenant limit protects the shared primary, which absorbs roughly 1.2k writes/second in total; the per-principal limit stops one credential inside a tenant from consuming that tenant's whole allowance. The tenant is the fairness unit for the same reason it is the leading column of every index.
3. Advertise limit, remaining and reset for the binding key on every response, not only on rejections, so a client can pace before it is refused. Pick one naming scheme - the RateLimit-* draft fields or an X-prefixed set - document the units, and never change them afterwards.
4. Separate two rejections that look identical to a naive client. 429 means this caller exceeded its own share and Retry-After is a real schedule it should obey. 503 means the instance is at its concurrency bound and shedding, which is a statement about the server; a fleet-wide 503 retried on a fixed delay resynchronises every client into one stampede, so full jitter is mandatory there and the delay is the client's guess, not ours.

Follow-up

• One tenant stays under its limit and still degrades everyone else during a backfill. What changes - the limiter, the worker concurrency caps, or both?
• How are counters kept correct across 20 to 40 stateless instances, and what does your answer cost per request?

Exports duplicate a row range about once a week

Hard · leases · clock skew · idempotency

Roughly once a week an export writes a file containing a duplicated range of rows. The affected job_run rows show attempt = 1, status = succeeded, one started_at, and a lease_owner naming a different host from the one whose logs show the job starting. Leases last 30 seconds and are heartbeated every 10 from inside the handler; lease_expires_at is computed on the worker and compared against the database's now(). Find the mechanism, and give a fix that holds even if you cannot fix the clocks.

Approach

1. Start from the fact that eliminates the obvious answer. attempt = 1 means no retry was recorded, so this is not a re-run after failure; two workers ran the same row concurrently and the takeover path never touched the counter. lease_owner naming a host other than the one that started the job is the same statement from the other side.
2. Enumerate the mechanisms that cause a premature takeover, then find the signal that separates them. Either the lease genuinely expired because the heartbeat did not fire, which is what happens when the heartbeat runs on the handler's own thread and the handler makes a long blocking call, or it only appeared expired because two clocks disagree, since lease_expires_at is written from the worker's clock and evaluated against the database's. The discriminator is the distribution: incidents clustered on the longest exports indict the heartbeat, incidents clustered on one host indict skew. Measure both, and measure each host's offset against the database directly.
3. Read the reclaim query precisely. In PostgreSQL now() is transaction start time, not statement time, so a reclaimer holding a long transaction compares against an older timestamp than expected; clock_timestamp() is the statement-time function. This is worth ruling in or out before you redesign anything, because it changes which rows look expired.
4. Remove the second clock rather than trying to synchronise it. Issue and extend the lease in the database, with lease_expires_at = now() + interval '30 seconds' in both the claim and the heartbeat, so exactly one clock is ever compared and worker skew stops mattering to this predicate.

Follow-up

• The displaced worker has already streamed half the file to object storage. What makes that side effect safe to repeat?
• You now count takeovers. What alert fires on that counter, and at what threshold?

Suggested practice checklist

The plan follows the three reported stages and the topic areas candidates list.

Day 1 — Map the loop and inventory your projects

• Write the three reported stages (Technical Screening, Coding Evaluation, Deep-Dive Discussions) and the five reported topic areas, then rate yourself on each.
• List your four strongest projects and, for each, the data store, the main trade-off and one measurable result.
• Pick the two projects you will use as deep-dive stories, one with a failure and one with a design challenge.

Deliverable: A one-page loop and topic map with self-ratings, and a project inventory with the two chosen deep-dive projects.

Day 2 — Architecture trade-offs and concurrency

• Write a one-page comparison of SQL and NoSQL for a service you know, ending with the use case that tips each way.
• Write the same for a monolith against microservices, covering deployment, failure isolation and team ownership.

Deliverable: Two one-page trade-off comparisons and a written design outline for the concurrent-requests scenario.

Day 3 — Backend data and live migrations

• Work the practice SQL problem on denormalising tenant onto revisions and backfilling it live, and write the rollout steps in order.
• Work the practice SQL problem on finding version gaps and relay lag with window functions.
• Write a half-page on keeping data consistent across two services: what you accept as stale and how you detect divergence.

Deliverable: Two solved SQL problems, an ordered live-backfill plan, and a half-page consistency note.

Day 4 — Timed coding with complexity and tests

• Solve the practice problems on diffing a projection against the primary and on collapsing a redelivered event batch into per-aggregate high-water marks, saying your reasoning aloud.
• Solve the practice problem on canonicalising a request body into a stable idempotency fingerprint.
• After each solution, write the time and space complexity and a test list covering empty input, one element, duplicates and maximum size.

Deliverable: Three solved coding problems, each with stated complexity and a written test list.

Day 5 — Debugging and refactoring without downtime

• Work the practice debugging problem about exports that duplicate a row range about once a week, and write your investigation as an ordered list of checks.
• Outline how you would refactor a legacy component while it stays in service: seam, flag or parallel run, rollback and the metric you would watch.
• Write the failure story you will use in a deep dive, covering cause, impact, fix and what changed afterwards.

Deliverable: A debugging write-up, a refactoring outline with rollback, and a written failure story.

Day 6 — Behavioral answers out loud

• Record spoken answers to the salary question, the question about defending a technical architectural decision, and the question about ambiguous or shifting requirements. Do the salary answer in German and in English.
• Replay each recording and cut anything that is not your own decision, the reasoning or a result.

Deliverable: Three recorded and trimmed answers, with the salary answer in both languages, and one written review comment.

Day 7 — Full dry run

• Run a mock in the reported order: a ten-minute project summary, one timed coding problem aloud, then a deep dive on one of your two stories with someone challenging each choice.
• Explain one architecture decision in plain language, as you would to a product manager.
• Write the two questions you most want to ask the team about their architecture and delivery.

Deliverable: A completed mock with notes on the weakest answer, plus two questions to ask.

Behavioral and project-story preparation

The three behavioral questions candidates report cover how you rank pay against other parts of a job, how you justify an architectural decision under challenge, and how you work when requirements are unclear. A reported tip is to prepare at least two deep-dive examples, one with a technical failure and one with a significant design challenge. Rehearse each answer with a real story, the options you weighed and a result you can put a number on.

1. Tell us about a time you had to defend a technical architectural decision.
2. Walk us through a recent technical challenge you solved and the trade-offs you made.
3. How do you approach refactoring legacy code while maintaining system uptime?

Ist Gehalt das wichtigste Benefit?

Medium · Behavioral and Values

Approach

1. Answer the question you were asked: take a clear position in the first sentence, such as 'pay matters, but it is not the main thing that decides whether I stay,' instead of dodging or reciting a slogan. A flat yes or no with no reasoning is the weakest version.
2. Give one real decision from your career as evidence. Say what the pay was, what else was on the table (the scope of the work, the architecture you would own, the people, learning, flexibility), and what you picked and why. A true story beats a values statement.
3. Separate pay as a baseline from pay as the deciding factor. For example, say fair pay removes a reason to leave, while the problems you work on and the ownership you get decide how much energy you bring.
4. Keep it about priorities, not a negotiation. Do not open with a number or a demand. If asked about pay directly later, answer that separately.
5. The question is reported in German, so rehearse the answer in both German and English and keep it short enough to say naturally.

Follow-up

• Would you take a lower salary for more architectural responsibility, and how much lower?
• What did you give up the last time you changed jobs, and was it worth it?
• What would make you leave a well-paid job?

How do you handle situations where requirements are ambiguous or shifting?

Medium · Behavioral and Values

Approach

1. Open with a one-line definition of the situation: a requirement that was vague or kept changing, who owned it, and what was at stake. Then spend most of the answer on what you did, because the story has to show your method.
2. Show the sequence: ask what outcome or decision the request serves, write down your assumptions and get them confirmed, and split the work so the part you are sure about ships first and the uncertain part waits.
3. Show how you protected the design from the change: an interface or module boundary around the part likely to move, a feature flag, a schema change that can be added later, and tests on the stable part.
4. Show communication with product managers or other stakeholders: what you reported, how you stated the cost of a late change, and how you recorded the decision so it did not resurface.
5. Close with the result and a number (rework avoided, release date kept, defects found). The mistake that sinks this answer is either waiting for a perfect specification or building silently on guesses, so show you did neither.

Follow-up

• How do you tell a legitimately shifting requirement from scope creep?
• What did you do when two stakeholders wanted different outcomes?
• Tell me about a time an assumption you made turned out to be wrong.

Turn a code review disagreement into a decision

Easy · code review · optimistic concurrency · communication

A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

Approach

1. Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
2. Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
3. Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
4. Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.

Follow-up

• Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
• The author says clients cannot handle a 409. How do you check whether that is true?