AlixPartners Software Engineer Interview Guide

The 60-second brief

AlixPartners is a consulting and corporate services firm. Candidates describe engagements built around corporate transformations, restructuring and urgent modernization work, with engineers building specialized platforms, client-facing applications and internal tools alongside consultants, data scientists, business analysts and product managers. Two job titles appear in candidate reports for this role: CCSI Systems Lead Engineer and Full Stack AI Senior Developer. The first is described as a lead position that adds technical project leadership, mentoring and management of outside vendors or contractors; the second leans toward AI-driven applications. Day to day, the reported work is turning loosely specified business needs into technical specifications and working software, writing tested code, reviewing peers' code and contributing to architecture decisions about scalability and security.

This guide is for software engineers interviewing at AlixPartners, whether for a full-stack, AI-focused or systems-lead position. It walks through the five reported rounds, gives worked answer structures for the behavioral and project-delivery questions candidates report, and points the technical and architecture questions at the stack candidates describe: Java, C#, Python, JavaScript or TypeScript, AWS or Azure, Docker and Kubernetes, and SQL and NoSQL databases.

Candidates report five rounds over roughly four to six weeks: a recruiter screen, a hiring manager discussion, an engineering team discussion, a cognitive and personality testing stage, and an interview with an internal staff psychologist.

Focus areas

• Full-stack development
• Cognitive/psychometric testing
• Personality assessment

Overview

The loop splits into two halves that need different preparation. The first three rounds are conversations about your background and technical work. The last two are an assessment stage and a psychologist interview, and they are what separates this loop from a typical product-company process. Candidates describe the testing stage as mandatory and as a gate before the final interview, so a strong technical showing does not make up for skipping it.

The reported question list reflects that split. One group is cognitive and psychological: how you define success, your career journey and the decisions behind it, an urgent task with ambiguous requirements, and balancing careful planning against fast execution. A second group is technical and architecture design: a system you built from scratch, integrating AI and machine learning models into a full-stack application, high availability and data integrity, speeding up a slow legacy database, and managing technical debt under deadline pressure. A third group is behavioral and project delivery: explaining a technical issue to a business stakeholder, conflicting requirements from two sources, unfamiliar technology, and competing high-priority deliverables.

The technical questions are open-ended and experience-based, so they are answered from projects you have actually run. Pick one or two systems you can describe end to end, including the numbers, the failure modes and what you would change. The behavioral questions reward the same discipline: one story per question, with your own decision at the center and the cost of that decision stated.

Candidates also report that the testing stage covers logical reasoning, quantitative aptitude and verbal comprehension under tight time limits, and that the psychologist stage covers work style, motivations and career history. Practice for both is cheap and specific: timed puzzle sets, and a written career narrative with a reason attached to every move.

The AlixPartners interview process

These are the five stages candidates report, in the order they report them, over about four to six weeks. Some accounts run longer, so ask your recruiter what comes next after each stage.

Recruiter Screen

Candidates describe a screening call with a recruiter about your background and fit for the role. It is the first place your career story gets told out loud, and the same story is revisited later in the psychologist interview, so keep this version short and consistent with what you will say then. Also settle which position you are being considered for, since the reported titles range from a systems lead role to a full-stack AI developer role.

What to demonstrate

• Whether your background matches the position being filled
• How clearly you summarize your career and your reasons for moving between roles

How to prepare

• Write a two-minute version of your career with one reason attached to each move, and keep the wording of the reasons stable for later rounds.
• List which of Java, C#, Python, JavaScript or TypeScript, AWS or Azure, Docker, Kubernetes, SQL and NoSQL you have shipped with, so you can answer stack questions precisely.
• Ask which title the opening carries and what the remaining stages are, and note the answer.

Hiring Manager Discussion

This is a conversation with the hiring manager about your technical background and how it lines up with the role. It is a discussion, not a named coding exercise, so the useful preparation is two or three projects you can narrate with their decisions and trade-offs. The reported duties include translating ambiguous business requirements into specifications, which makes stories about unclear scope and stakeholder communication a natural fit.

What to demonstrate

• Technical background relative to the position
• Alignment between your experience and the work described for the team

How to prepare

• Prepare two projects you owned, each with the decision you made, the alternative you rejected and what it cost.
• Rehearse the question about handling an urgent task with ambiguous requirements, using a project where you wrote down your assumptions.
• Prepare to explain one technical issue in business terms, as in the stakeholder-communication question.

Engineering Team Discussion

Candidates describe a discussion with the engineering team to go deeper on technical skills and fit. The technical areas reported across the process are system architecture for cloud-based systems, API and integration design, and AI and data engineering. Scenarios candidates mention include a real-time ingestion pipeline, moving a monolith toward microservices and diagnosing a production database bottleneck. Treat the stage as a design conversation: bring a system you built and be ready to extend it.

What to demonstrate

• Hands-on engineering skills and design judgment
• Fit with the engineering team

How to prepare

• Build a 5-minute walkthrough of a system you designed and deployed: requirements, components, data flow, failure handling and what you would change.
• Outline where a model call sits in a full-stack request path: timeouts, fallbacks, versioning and monitoring.
• Write a short list of availability and data-integrity measures you have actually used: backups, replication, idempotent writes, constraints.

Cognitive and Personality Testing

Candidates describe a testing stage made of online and paper-based cognitive, personality and education assessments, and call it a mandatory gate before the final interview. The cognitive material reported is logical reasoning (pattern recognition, abstract reasoning, sequences), quantitative aptitude (fast arithmetic, reading data, basic algebra) and verbal comprehension (reading a passage and drawing conclusions), with spatial reasoning less common. Some offices add standardized education tests. Reports say tight time limits are the main difficulty, and that the personality portion is built to catch inconsistent answers.

What to demonstrate

• Logical reasoning, quantitative and verbal ability under time limits
• Consistency of your answers across the personality portion

How to prepare

• Do timed practice sets in each of the three reported areas, logging every miss by type so you can fix the pattern, not the item.
• Practise reading a table or chart and doing the arithmetic by hand, since some tests are paper-based.
• For the personality portion, answer as you really work. Reports warn that inconsistent answers show up, so there is no benefit in guessing a preferred profile.

Psychologist Interview

The final stage is an interview with an internal staff psychologist about work style, motivations and career history. Reported topics are your career story and the reasons behind each transition, whether you lean toward tasks or toward people, and how you define success. Candidates mention scenarios such as a major setback and what it taught you, conflict with stakeholders who have competing priorities, and your preferred working environment and handling of high-stress situations. Your answers here should match what you said to the recruiter and the hiring manager.

What to demonstrate

• Work style, motivations and career history
• Self-awareness about setbacks, conflict and high-stress situations

How to prepare

• Write your career narrative with a reason, a lesson and an outcome for each transition, and include one real setback.
• Write a definition of success that your past choices actually support, with two examples.
• Prepare a conflict story where stakeholders wanted different things, and say how you decided and what you gave up.
• Reread your stage 1 and 2 answers and remove any contradictions before this interview.

Where candidates lose points

Preparing only for technical conversations and treating the testing stage as an afterthought

Candidates describe the cognitive and personality stage as mandatory and gating. Run timed sets in logical, quantitative and verbal reasoning for several days, and log each miss by type.

Telling a career story where each move is just a date and a title, with no reason

Write a reason, a lesson and an outcome for every transition, plus one real setback, and check that the reasons match what you told the recruiter and the hiring manager.

Answering the personality items to match a profile you imagine is wanted

Reports warn that inconsistent answers stand out. Answer as you actually work, and make sure your interview stories describe the same working style.

Answering the legacy-database question by jumping to indexes or a rewrite

Give a safe order: measure first (slow query log, query plans, locks, hardware limits), fix the biggest cost with the lowest risk, test on a copy, keep a rollback, and say how the client's daily operations stay running throughout.

Behavioral stories about 'we' with no decision of yours, or stress stories that are all-night heroics

Name the decision you owned, what you cut or deferred, who agreed, and what it cost. Describe a specific stress habit, not a claim of calm.

Questions & practice

Describe a situation where you had to complete an urgent task with highly ambiguous requirements.

Medium · Cognitive & Psychological Evaluation

Approach

1. Choose a story where the requirements really were unclear and the deadline was real, and state both in the first two sentences.
2. Show the concrete steps. I wrote my assumptions down, confirmed the two or three that would be expensive to get wrong with whoever owned the outcome, and made the reversible calls myself without waiting.
3. Explain how you limited rework. Examples: ship a narrow first version, keep likely-to-change values in configuration rather than code, put the uncertain behaviour behind a feature flag, and keep a visible list of open questions.
4. Close with a measurable result and one assumption that turned out wrong, including how quickly you caught it and what it cost.
5. Mistake that sinks it: a story where you waited for perfect clarity, or where you guessed silently and the stakeholder only found out at delivery.

Follow-up

• Which assumption turned out to be wrong, and what did fixing it cost?
• How did you decide which questions were worth interrupting the stakeholder for?
• What would you have done if the person who owned the requirement could not be reached?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

1. Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
2. Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
3. State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
4. Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

• The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
• Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

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?

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?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

1. Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
2. Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
3. For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
4. State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

• A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
• How do you honour an erasure request while resource_revision.actor_user_id still references this table?

How do you define success in your professional career?

Medium · Cognitive & Psychological Evaluation

Approach

1. Give a definition you can check, not a slogan: for example, 'I count a project as a success when what I built is in daily use and the number it was meant to move actually moved.' Name the measure you use.
2. Back it with two stories: one where you met your own definition, and one where you missed it, plus what you changed afterwards.
3. Show how the definition has changed over your career, for example from personal output (features shipped) to outcomes for the team or client. That shift shows self-awareness better than a fixed answer does.
4. Keep it consistent with your career walkthrough and your answers about stress and priorities. Candidates report that the personality assessments check whether answers are consistent.
5. Mistake that sinks it: a vague answer ('making an impact', 'being happy') with no measure, or one defined only by title and pay.

Follow-up

• Tell me about a time you succeeded by that definition but still felt dissatisfied.
• Who else gets a say in whether your work was a success?
• What would make you leave a role that meets your definition?

Walk me through your personal and professional journey, and explain the key decisions that shaped your career.

Medium · Cognitive & Psychological Evaluation

Approach

1. Go in chronological order, but build the story around three or four decision points. For each one, give the options you had, what you chose, why, and what it cost you.
2. Keep the description of each role brief and spend the time on the reasons for each move. Give the reasoning you had at the time, not a neat story you put together afterwards.
3. Include one setback or wrong turn honestly and say what you do differently because of it. Make sure dates and gaps match your CV, and explain gaps plainly.
4. End by linking the story to this role: delivery work alongside consultants and analysts, and the languages and cloud platforms you have used (Java, C#, Python, TypeScript, AWS or Azure), but only the ones you have actually used.
5. Rehearse a short version and a longer one, so you can go deeper on any single decision without losing the thread.

Follow-up

• Which career decision would you reverse, and why?
• What did you learn from the role that went worst?
• Why are you looking to move now rather than a year from now?

How do you balance the need for meticulous planning with the necessity of immediate, rapid execution?

Medium · Cognitive & Psychological Evaluation

Approach

1. Decide by reversibility. Decisions that are hard to undo get planned up front: the data model and schema migrations, public API contracts, security and access control, and anything that touches client data. Reversible ones, such as UI details and internal code structure, get shipped and adjusted.
2. Put a time limit on planning. Write a one-page design note listing the options, the choice and its main risk, and run a short spike to settle the biggest unknown before committing.
3. Name the guardrails that make fast execution safe: automated tests in CI, feature flags, staged or canary rollouts, and a rollback plan written before release.
4. Give one example of each mode from your own work: a time careful planning prevented an expensive mistake, and a time shipping early taught you something no amount of planning would have.
5. Avoid claiming you always get the balance right. Name the side you lean towards by default and how you correct for it.

Follow-up

• Tell me about a time you under-planned and paid for it.
• How do you tell a stakeholder who wants speed that a change needs more design time?
• How do you decide whether a decision is reversible?

Walk me through the architecture of a complex system you designed and deployed from scratch.

Medium · Technical & Architecture Design

Approach

1. Start with the problem, the users and the numbers: request rate, data volume, latency target and the hard constraints (compliance, budget, deadline). Then sketch the parts: clients, API layer, services, data stores, queue or async workers, and external integrations.
2. Trace one write request and one read request end to end. Justify each store: a relational database where multi-row transactions and constraints matter, a NoSQL or cache layer where the access pattern is key lookups at volume.
3. Cover how it ran in production: containers and orchestration (Docker, Kubernetes) and the cloud (AWS or Azure) only if you used them, the CI/CD pipeline, and observability (metrics, structured logs, traces, alerts tied to user-facing symptoms).
4. Explain how failures were handled: timeouts on every outbound call, retries with exponential backoff only for idempotent operations, and idempotency keys on writes so a retry cannot double-apply.
5. Separate what you personally designed and built from what the team did, and name one trade-off you would make differently today.

Follow-up

• What breaks first if traffic grows ten times?
• How did you test it before the first real users arrived?
• If you rebuilt it today, what would you change and why?

How do you approach integrating AI and machine learning models into existing full-stack applications?

Medium · Technical & Architecture Design

Approach

1. Put the model behind its own service with a versioned contract (input schema, output schema, model version returned in every response) so the application never imports model code. Choose a synchronous call when latency is low enough, or a queue plus worker plus status endpoint or webhook when it is not.
2. For LLM features: keep prompt templates in version control, validate structured output against a schema and retry or reject when it fails, set timeouts and rate limits, and define a fallback (a rule-based default or a disabled feature) for when the model is down or returns nothing usable.
3. Handle data deliberately. Do not send client data to a third-party model API without approval, redact personal data where needed, and log inputs and outputs for evaluation under access controls and a retention limit.
4. Evaluate before and after release: an offline test set with agreed metrics, then shadow mode or a feature-flagged canary, then monitoring of latency, error rate, cost per request, input drift and user feedback.
5. Edge cases: training-serving skew (features must be computed the same way in both paths), low-confidence outputs routed to human review, and caching identical requests to control cost.

Follow-up

• How would you roll back a model whose output quality drops but which never throws an error?
• How do you test a nondeterministic LLM feature in CI?
• How do you keep inference cost bounded as usage grows?

What strategies do you use to ensure high availability and data integrity in enterprise-grade software?

Medium · Technical & Architecture Design

Approach

1. Start with targets: an availability SLO, plus RPO (how much data you can lose) and RTO (how long recovery may take). Every later choice follows from those numbers.
2. Availability: remove single points of failure with several stateless instances behind a load balancer across availability zones, plus health checks and autoscaling. Use a database with a standby replica and automatic failover.
3. Replication trade-off: synchronous replication keeps RPO near zero but adds write latency, while asynchronous replication can lose recently committed writes on failover. Reads from replicas can be stale, so route read-your-own-writes paths to the primary.
4. Integrity: wrap multi-row changes in ACID transactions, enforce rules in the database (foreign keys, UNIQUE, NOT NULL, CHECK) as well as in code, use idempotency keys on writes, and use a version column for optimistic concurrency.
5. Recovery and cross-system consistency: point-in-time recovery with restores that are actually tested, audit logs, reconciliation jobs, and a transactional outbox instead of dual writes to a database and a message broker. Add timeouts, retries with backoff and jitter, and circuit breakers.

Follow-up

• An asynchronous replica is promoted after the primary fails. What happens to writes that were acknowledged but not yet replicated?
• How would you prove a backup can actually be restored?
• How do you keep two systems consistent without a distributed transaction?

Explain how you would optimize a slow, legacy database that is critical to a client's daily operations.

Medium · Technical & Architecture Design

Approach

1. Measure before changing anything. Find the queries with the highest total time (pg_stat_statements in PostgreSQL, Query Store in SQL Server, the slow query log in MySQL) and record baseline timings for the business workflows that depend on them.
2. Read the execution plans (EXPLAIN ANALYZE in PostgreSQL; it really runs the statement, so wrap writes in a transaction and roll back). Look for full scans of large tables, row estimates far from actual counts (stale statistics), nested loops over large inputs and sorts spilling to disk.
3. Apply fixes in order of risk. First refresh statistics. Then rewrite queries: N+1 calls from an ORM, functions wrapped around indexed columns, SELECT *. Then add composite indexes matching the filter and sort (equality columns before range columns), checking the extra write cost of each index.
4. Bigger levers once queries are tuned: caching hot reads, moving reporting to a read replica, partitioning large tables by date, and archiving old rows.
5. Protect daily operations while you work: test on a restored copy with production-sized data, build indexes online where the engine allows it (CREATE INDEX CONCURRENTLY in PostgreSQL), change one thing at a time, and confirm backups and a rollback path first. Also check lock contention and connection-pool exhaustion.

Follow-up

• The query is fast in staging but slow in production. What are the likely causes?
• The new index sped up reads but slowed the nightly load. What do you do?
• When would you stop tuning and move the workload to a replica or a warehouse instead?

How do you manage technical debt when working on tight project timelines?

Medium · Technical & Architecture Design

Approach

1. Separate deliberate debt from accidental debt. When I take a shortcut for a deadline, I record it with an owner, the cost it creates and the trigger for paying it back, so it cannot quietly become permanent.
2. Draw the line by cost of reversal. Never cut corners on security, data integrity, the schema or public API contracts. Accept shortcuts in UI polish, internal duplication or a manual operational step.
3. Contain the shortcut: put it behind an interface so it can be replaced without touching the code that calls it, and keep tests on the paths that matter even when the rest is thin.
4. Pay it back steadily: fix debt when work next touches that code, set aside capacity in every iteration, and explain the cost to non-technical stakeholders in their terms (slower delivery, repeat incidents) rather than as code quality.
5. Give one real example: the shortcut, why it was the right call at the time, what it later cost, and how it was paid back.

Follow-up

• Tell me about debt you took on that you later regretted.
• How do you get a manager or client to fund paying debt back?
• How do you handle debt in a legacy codebase you inherited rather than created?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

1. Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
2. Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
3. Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
4. The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

• Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
• How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

The plan follows the loop: story and career narrative first, then timed cognitive practice, behavioral stories, architecture and database answers, and a full run-through that mirrors the psychologist stage. Reported questions are attached to the days that practise them.

Day 1 — Career narrative and definition of success

• Write your career as a timeline, with the reason you made each move and what it taught you, plus one real setback.
• Write a definition of success in three or four sentences, backed by two decisions from your past that show it.
• Say both aloud and trim until the career story fits in two minutes.

Deliverable: A one-page career narrative with reasons, a setback, and a written definition of success, each rehearsed aloud once.

Day 2 — Timed cognitive practice

• Do one timed set each of logical reasoning (patterns and sequences), quantitative problems (arithmetic and reading a table) and verbal comprehension (short passages with conclusions).
• Redo the quantitative set on paper without a calculator to match the paper-based format candidates report.
• Log every miss by type, then redo only the missed types.

Deliverable: Three scored timed sets and an error log naming the two weakest question types.

Day 3 — Urgency, ambiguity and balancing speed with planning

• Outline a story for the urgent task with ambiguous requirements: the assumptions you wrote down, who confirmed them and what you built first.
• Outline the extreme-deadline story with the cut list, the stress habits you used and what was deferred.
• Write a two-sentence position on balancing planning against fast execution, with one example where you planned too much and one where you moved too fast.

Deliverable: Three written story outlines (ambiguous urgent task, deadline delivery, planning versus execution), each with the decision you owned and its cost.

Day 4 — Stakeholders, conflicting information and priorities

• Outline the story of explaining a technical issue to a non-technical stakeholder: impact first, options, recommendation, confirmation.
• Outline the conflicting-requirements story, with both versions written side by side and the person who confirmed the answer.
• Outline the unfamiliar-technology story and the multiple-priorities story, then say each aloud once.

Deliverable: Four story outlines with one decision, one trade-off and one measurable outcome each, spoken aloud once.

Day 5 — System architecture and availability

• Prepare a walkthrough of a system you designed and deployed: requirements, components, data flow, deployment, and failure handling, with a diagram you can sketch from memory.
• Write your high-availability and data-integrity toolkit with a real example for each: replication and failover, backups and restore tests, idempotent writes, constraints and transactions.

Deliverable: A sketched architecture walkthrough, a one-page availability and integrity checklist, and one completed idempotency exercise.

Day 6 — Legacy database, AI integration and technical debt

• Write a step-by-step plan for speeding up a slow legacy database that cannot go offline: measure, find the top costs, change with a rollback, verify.
• Outline where a model call fits in an existing full-stack app: sync or async, timeout and fallback, versioning, evaluation and monitoring.
• Write how you decide which technical debt to take on under a deadline and how you schedule its repayment.

Deliverable: A legacy-database plan, an AI integration outline, a technical-debt rule of thumb and two completed practice exercises.

Day 7 — Full run-through in psychologist-stage order

• Record yourself giving the career story, your definition of success, a setback, a stakeholder conflict and your preferred working environment with how you handle high-stress situations.
• Listen back and mark any place where your reasons or working style contradict each other or your earlier stories.
• Re-do the weakest two answers, then do one more timed set from the testing practice.

Deliverable: One recorded run-through, a list of contradictions fixed and one re-timed cognitive set.

Stories for the project and psychologist stages

The behavioral and psychological stages are about how you work: how you handle deadlines, ambiguity, conflict and setbacks, and whether your account of your own career holds together. Candidates report that the psychologist interview covers work style, motivations and career history, and that stakeholder conflict and high-stress situations come up. Use one story per prompt, put your own decision at the center, state what it cost, and keep the stories consistent with each other.

1. Describe a situation where you had to complete an urgent task with highly ambiguous requirements.

Tell me about a time you had to deliver a project under extreme time constraints and how you managed your pers

Medium · Cognitive & Psychological Evaluation

Tell me about a time you had to deliver a project under extreme time constraints and how you managed your personal stress.

Approach

1. Choose a project with a hard external deadline and a real consequence for missing it, and say plainly what the deadline was and what depended on it. Pick one where you made the scoping calls, not one you were handed.
2. Show the triage: you split the work into must-ship, can-follow and cut, got the cut list agreed in writing with the person who owned the outcome, and protected the critical path first (the part that would break the delivery if wrong).
3. Describe how you shipped in slices that could be checked early, such as a thin working path first, tests on the critical flow, and a rollback or feature flag, rather than finishing everything at the last minute.
4. Answer the stress half concretely: the habits you actually used, such as fixed work blocks, one status channel instead of constant interruptions, sleep protected the night before a release, and a short check on whether tiredness was affecting your judgment. 'I stay calm' is not an answer.
5. Close with the cost and the repayment: what you deferred, how you logged it, and when it was fixed. The story that sinks this answer is all-night heroics with no scoping and no mention of what slipped.

Follow-up

• What exactly did you cut, and who agreed to the cut?
• What did the stress do to your decisions, and how did you notice?
• If you ran the same project again, what would you change in the first two days?

Describe a time when you had to explain a complex technical issue to a non-technical business stakeholder.

Medium · Behavioral & Project Delivery

Approach

1. Choose an issue with a business consequence, such as a data mismatch in a report, an outage, a slow nightly job or a migration risk, so that the listener has something to decide and not just something to understand.
2. Lead with the impact and the decision needed, then give the cause in one sentence with an analogy from their world. Use their units (money, days, customers affected, risk of a missed deadline), not latency or error rates.
3. Offer two or three options with cost, risk and time for each, and give your recommendation. Do not hand over a lecture and leave the choice to them without a recommendation.
4. Confirm understanding by asking them to say back what they will do, then follow with a short written summary. State what you cut from the explanation and why.
5. The mistake that sinks this story is jargon, or the opposite: simplifying so much that the stakeholder could not make the decision.

Follow-up

• How did you know they understood, and what did you do when they did not?
• What if the stakeholder rejected your recommendation?
• How would you shorten that explanation to two sentences for a senior executive?

How do you handle a situation where a technical manager and a recruiter give you conflicting information about

Medium · Behavioral & Project Delivery

How do you handle a situation where a technical manager and a recruiter give you conflicting information about project requirements?

Approach

1. Do not pick the more senior voice by default and do not guess. First write down the exact conflict side by side: which requirement, what each person said, and what depends on the difference (scope, stack, location, level, start date or deadline).
2. Separate who owns what. The technical manager is the source on technical scope, while a recruiter or coordinator often relays information second-hand and owns logistics. Ask the person with ownership to confirm the item, ideally in writing, instead of relaying messages between the two.
3. Tell both people what you found, neutrally and without blame: 'I received two versions of X, here are both, which is correct?' Copy the confirmed answer back to everyone so the record is shared.
4. While waiting, keep working on whatever is not affected by the conflict, and record the open item as an explicit assumption with a date to revisit.
5. The mistake to avoid is quietly building to one version and discovering the other at delivery, or complaining about the recruiter instead of resolving the question.

Follow-up

• What would you do if the manager was unreachable and the deadline was today?
• What if the written confirmation contradicted work you had already built?
• What would you change so that requirements reach you from one source next time?

Tell me about a time you had to step into a project with unfamiliar technologies and quickly deliver results.

Medium · Behavioral & Project Delivery

Approach

1. Pick a real case in which you joined a codebase or stack you did not know and had a deliverable with a date. Name the technology and the gap honestly, for example moving from Java to C#, or from AWS to Azure, or from REST services to a model-serving setup.
2. Describe how you shortened the ramp-up: identify the smallest slice of the stack needed for the first deliverable, find the person who owned the code and ask for a walkthrough, read the existing tests and the last few merged changes, and get the project running locally on day one.
3. Show the first delivery as a thin vertical slice with early review, not a long study period. Say what you deliberately chose not to learn yet.
4. Be specific about what you got wrong. Describe one misunderstanding, how a review or a test caught it, and what you changed in how you learn.
5. State the result with a concrete outcome (what shipped, by when) and what you left documented for the next person. Overclaiming expertise sinks this answer.

Follow-up

• What was the biggest misunderstanding you had in the new stack, and how did you find it?
• How did you decide what not to learn at first?
• How did you make sure code you only partly understood was safe to ship?

How do you prioritize tasks when you are assigned multiple high-priority deliverables simultaneously?

Medium · Behavioral & Project Delivery

Approach

1. Start by listing every deliverable with its deadline, who is waiting on it, what happens if it slips, what it blocks and a rough effort. If everything is truly urgent, this table is what reveals the real order.
2. When two items still conflict, ask the owner of the outcome, usually your manager or the stakeholders together, to rank them. Priority between competing business needs is their call, and your job is to present the trade-off clearly, not to decide silently.
3. Sequence the work: unblock others first, then highest consequence per hour of effort. Where possible negotiate scope or split deliverables so that part of each lands on time, instead of working longer hours on all of them.
4. Tell stakeholders early what will slip and to when, and re-check the order at fixed points, because priorities move. Give a concrete example with the actual items and what you traded.
5. The weak versions are 'I do them all' with no trade-offs, or ranking privately and letting a stakeholder find out their item slipped.

Follow-up

• What if two stakeholders each insist their item comes first?
• What if your estimate was wrong and you are going to miss one deadline?
• When would you hand something off or ask for help, and how would you do that?