AssessFirst Software Engineer Interview Guide

The 60-second brief

AssessFirst makes psychometric assessment software. Organisations use it to recruit and develop people based on personality, motivations and potential, and predictive analytics sit behind its results. Candidates describe the Software Engineer job as keeping the company's technical infrastructure running and extending it, building and optimising features on the assessment platform, and working with product managers and leadership so that engineering work matches the company's HR technology goals. Candidates report that no single stack is listed and that it can vary by team.

This guide is for Software Engineer candidates preparing for the AssessFirst loop. Most of the reported questions are about self-awareness, motivation and career growth, so a large share of the guide covers your personal narrative: what your assessment results say about you, a short pitch, a proudest-achievement story and a credible answer on avoiding stagnation. The other share covers the technical interviews. No specific technical questions are reported for them, so the guide prepares engineering fundamentals broadly and explains how to walk through your own past work.

Candidates report four stages over roughly 3-5 weeks: a Personality Assessment, a Talent Acquisition Interview, a series of Technical Interviews with technical leads, and possible Leadership Meetings focused on cultural fit and values.

Focus areas

• Professional communication (concise pitch)
• Prioritization of relevant skills
• Behavioral interview (past achievements)

Overview

Candidates describe this loop as unusual for an engineering role because it opens with a personality and motivation assessment before any interview. They also report that later conversations often come back to its results. Every question reported for this role is about you rather than code: what you thought of the tests, whether you will stagnate, what you are proudest of, why you fit the position, and when you can start. Treat the assessment as the first chapter of a story that every later stage keeps reading.

The technical part is real but thinly reported. Candidates describe a series of interviews with technical leads that check core engineering fundamentals and problem-solving logic, and they say the stack can vary by team. Since you cannot narrow it down to a language or framework, prepare in the language you write best. Cover the usual working-engineer material: data structures and complexity, writing and fixing SQL, debugging a production symptom, and designing an endpoint that copes with retries. Be ready to explain one system you built in enough depth that a technical lead can probe your decisions.

Time pressure is a reported theme. Candidates report that some stages are time-constrained and that your self-presentation should fit in under ten minutes, which leaves room for conversation. They also report keeping time at the end for their own questions. Practise a pitch you can deliver without notes. Pick the three or four skills most relevant to the posting rather than walking through your whole CV, which is what the reported topic of prioritising relevant skills comes down to.

The work itself sits on an assessment product, so a sincere, specific reason for wanting to build software that evaluates people's personality and motivations will help in the fit and leadership stages. Candidates report that these can include the CTO or CEO. Have one concrete idea of why the problem interests you and one question about where the product is going.

The AssessFirst interview process

These are the four stages candidates report, in the order they describe. The leadership meetings are reported as possible rather than guaranteed.

Personality Assessment

Candidates report that the process starts with an assessment of personality and motivations, not with an interview. They also report that the results often become a starting point for later conversations, and that interviewers ask about them. Approach it candidly. Answer as you behave on an ordinary working day rather than as the candidate you imagine is wanted, because any gap between your answers and how you describe yourself later is hard to explain. Afterwards, write down what you remember of the items and, if results are shared with you, which findings fit and which you would qualify.

What to demonstrate

• Your personality profile and motivations as the assessment captures them
• A self-description that later interviews can build on and question

How to prepare

• Take the assessment in one quiet sitting and answer each item as you actually work, not as you would like to work.
• If you see your results, write two findings you agree with, each with a work example, and one you would qualify, with the situation where you act differently. This prepares the reported question about the tests you took.
• Note your honest reaction to the experience itself (length, clarity of the items, how easy it was to answer truthfully) so you can give balanced feedback if asked.

Talent Acquisition Interview

Candidates describe an interview with Talent Acquisition about your fit for the role. No questions are attributed to this stage specifically. A fit conversation is where your pitch, your motivation for the company, the skills you would highlight and practical points such as your start date get tested. Candidates report that some stages are time-constrained and that a self-presentation should fit in under ten minutes, so arrive with a pitch you have timed rather than a CV walkthrough.

What to demonstrate

• Fit for the role as you present it
• A clear, concise account of your background and motivation

How to prepare

• Write a three-part pitch (what you build now, one result with a number, why assessment software interests you) and time it out loud until it fits well under ten minutes.
• Map the three posting requirements you match best to a one-line proof each. That table answers the reported ideal-candidate question.
• Settle your notice period, booked leave and any relocation steps so the start-date answer is one sentence.

Technical Interviews

Candidates describe a series of interviews with technical leads that evaluate technical competence. They report checks on core engineering fundamentals and problem-solving logic, and say the stack can vary by team. No specific technical questions are reported, so prepare broadly. Write correct code in your strongest language while explaining your reasoning, state the complexity, and be ready to defend the design decisions in a project you shipped. Talk through edge cases before running anything, and say which trade-off you chose and why.

What to demonstrate

• Working knowledge of programming fundamentals and problem-solving
• Ability to explain and defend technical decisions to technical leads

How to prepare

• Solve the interval-overlap (peak concurrency from lease records) and rolling failure-rate practice problems in your strongest language, stating time and space complexity.
• Write the window-function and join fan-out SQL practice queries, and talk through the stalled-table debugging scenario from symptom to fix.
• Prepare a walkthrough of one system you built: its components, one trade-off you made, one failure you handled and what you would change.

Leadership Meetings

Candidates report possible meetings with leadership members about cultural fit and values, and say these can include the CTO or CEO. Expect the conversation to stay at the level of motivation, values and long-term direction rather than code. Bring a specific reason for wanting to work on software that assesses personality and potential, a view of where you want your career to go, and questions about the product and the engineering team's current challenges.

What to demonstrate

• Alignment with the company's culture and values as candidates report it
• Motivation for the company's product and your long-term trajectory

How to prepare

• Write a short motivation statement on why software for psychometric assessment interests you, using one concrete aspect of the product rather than general praise.
• Prepare your growth story: one plateau you noticed, what you changed, and what this role would stretch in you.
• Write three or four questions for leadership about product direction and the engineering team's current challenges, and keep time at the end of the conversation to ask them.

Where candidates lose points

Answering the personality and motivation assessment as the ideal candidate, then describing yourself differently in the interviews that follow

Candidates report that later conversations often use the assessment results as a starting point, so an inconsistent self-description is exposed quickly. Answer candidly, and before the next stage reread any results you received. Prepare one work example for each finding you agree with and an explanation of the context for any finding you would qualify.

Turning the self-introduction into a chronological CV walkthrough that eats the conversation

Candidates report that some stages are time-constrained and that a self-presentation should fit in under ten minutes. Build the pitch around the few skills the posting needs most, with one measurable result each, and rehearse it with a timer until you can stop cleanly without notes.

Telling the proudest-achievement story in 'we' terms, so it is unclear what you did or why it matters to you

Structure the story as stakes, your own actions, the obstacle and the outcome. Then spend real time on why it is the achievement you are proudest of, because that reason is the point of the question. Say 'I' for your part and credit others by role.

Treating the technical interviews as a formality because the rest of the loop is about fit

Candidates report that this stage checks core fundamentals and problem-solving with technical leads, and no specific questions are reported to narrow your study. Practise coding, SQL, a debugging walkthrough and a small endpoint design in your strongest language. Prepare to defend the decisions in one project you built.

Reaching a leadership meeting with no specific reason for wanting to build assessment software and no questions to ask

Write a motivation statement tied to a concrete aspect of what AssessFirst builds, plus questions about product direction and the team's current challenges. Candidates report keeping time at the end for their own questions, so plan for it rather than letting the conversation run out.

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?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

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?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

1. Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
2. Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
3. Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
4. Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

• The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
• A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

When will you be available to start?

Easy · Logistics and Practicality

Approach

1. This is logistics plus a quiet check on professionalism: give a concrete date or range, explain what drives it, and show you'll honor your commitments to your current employer.
2. Work out your real constraint beforehand: the notice period in your contract (commonly a few weeks to three months, sometimes longer, depending on country and seniority), a promised handover, pre-booked leave, and any relocation or visa steps.
3. Answer in one line with a real date, e.g. "My notice period is four weeks, so I could start in early March; I want to hand over my current project properly."
4. If there is flexibility, say what could move the date, such as a shorter notice period or offsetting it with untaken leave where your employer agrees. If you're between jobs, give the earliest date you can actually be ready.
5. Tie the date to the offer: "I can start X weeks after I sign the written offer and hand in my notice." Resign only once any conditions, such as reference checks, are cleared, and mention pre-booked holidays now so the start date doesn't need renegotiating.

Follow-up

• Could you start earlier? Say you'll ask, and confirm a new date only once your current employer has agreed in writing to release you early.
• Are you interviewing elsewhere? Answer honestly and briefly, share any hard deadline as a fact, and say what makes this role your preference if it is.
• Could you do anything before your official start? Check your current contract, which often restricts working for others during notice; light prep such as reading public docs is usually fine.

Design the bulk write endpoint a migration script retries blindly

Medium · batch api · partial failure · idempotency

A customer's migration script pushes 2 million resources through POST /v1/resources:batch, up to 500 items per call, and retries any call that errors or times out. Within a call some items fail validation, some collide with rows that already exist, and some succeed. Specify the request and response shape, whether a batch is atomic or per-item, how idempotency works for the call and for each item, the status code for a mixed outcome, the size and item-count limits with their error codes, and exactly what the script does after a timeout mid-batch.

Approach

1. Choose atomicity deliberately and price it. All-or-nothing means one transaction holding locks for the whole batch on a primary already absorbing about 1.2k writes/second, which bounds batch size by lock duration, and it turns one bad row into 499 rejections the script must resend. Per-item partial success is the right default for a migration, and the contract's job is then to make a partial outcome impossible to miss.
2. Require a client-supplied id on every item and echo it in every result. Deriving a per-item key from the array index breaks the first time the script resends a batch with the failures removed: the indices shift, previously-succeeded items acquire new keys, and they are created a second time.
3. Key the effects at two levels. The call's Idempotency-Key covers an exact resend of the same bytes; per-item keys of (tenant_id, client_item_id) make a partially-applied batch safe to resend whole. Resending an identical batch must reproduce the same per-item results, not 500 conflicts the script has to interpret.
4. Answer a mixed outcome with one status plus per-item detail: 200, or 207 borrowed from WebDAV if you prefer it - document whichever you pick - carrying an array of client_item_id, per-item status, and either resource_id or an error code from the same taxonomy the single-item endpoint uses. Reserve 4xx for the request as a whole: unparseable body, too many items, payload over the limit (413). Put a failed count at the top level so that even a script checking only the cheapest thing cannot conclude success while rows were dropped.

Follow-up

• At 500 items per call, what is the wall-clock time for 2 million rows, and what pacing do you publish so the migration does not become an incident?
• One item in every batch fails with the same code. How does the script discover that without a human reading logs?

Every query on one table stalls for forty seconds mid-deploy

Medium · lock contention · ddl · migrations

During a release on PostgreSQL, every query touching resource times out for about 40 seconds and then recovers with no intervention. The release ran one migration, ALTER TABLE resource ADD COLUMN archived_reason TEXT, and the migration log shows it completing in 6 ms. Unrelated tables showed no change in error rate. Explain how a 6 ms statement caused a 40-second stall, give the ordered checks you would run on a live system to confirm it, and give the migration procedure that prevents a repeat.

Approach

1. Separate the statement's duration from the lock's duration. ADD COLUMN with no default is a catalogue-only change and genuinely runs in milliseconds, but it requires ACCESS EXCLUSIVE, and it cannot acquire that until every transaction already touching the table has finished.
2. Account for the queueing, which is the part that surprises people. A lock request that is waiting blocks later requests for conflicting modes behind it rather than letting them overtake, so one long-open transaction holds the DDL and the DDL holds all the traffic. The stall length is set by the longest open transaction, not by the size of the change.
3. Confirm on a live system in this order: pg_stat_activity for that table ordered by xact_start, looking for the oldest transaction and specifically for state = idle in transaction; then pg_locks where granted = false to find the waiter; then join them on pid to name blocker and blocked. pg_blocking_pids() does that join for you and is the fastest single call.
4. Prevent rather than merely time it better. Set lock_timeout to a second or two on the migration session so the DDL abandons the queue after a bounded wait and is retried, instead of holding it for as long as the oldest transaction lives. Be exact about what that buys: queries arriving during the wait still queue behind the pending ACCESS EXCLUSIVE request, so each attempt costs them up to one lock_timeout of added latency. The outage goes from 40 seconds to about one second per attempt, not to zero. Also run migrations away from deploy-time peaks, and put a statement timeout and an idle-in-transaction timeout on the analytics role that opens the long transactions.

Follow-up

• The same release also wants NOT NULL on that column. What is the sequence that gets there without a long lock?
• Your lock_timeout retry fails ten times in a row because the analytics transaction is always open. What do you change?

Suggested practice checklist

The plan follows the reported loop. Days 1-3 cover the assessment and the personal-narrative questions candidates report, days 4-6 build the technical fundamentals the technical-lead interviews check, and day 7 covers leadership, logistics and a full mock.

Day 1 — Map the loop and work through your assessment results

• List the four reported stages and, beside each, write which of your stories or skills it will draw on; mark the stage you feel least ready for.
• Reread any personality or motivation results you received and write two findings you agree with, each tied to a work example, plus one you would qualify with the context where you act differently.
• Answer the question about the personality and motivation tests out loud, covering both the experience of taking them and what the results said, then cut anything that sounds like flattery or dismissal.

Deliverable: A stage map with your weakest stage marked, a one-page results sheet (two agreed findings, one qualified finding, examples), and a recorded answer about the tests.

Day 2 — Build a concise, timed pitch

• Write a self-introduction in three parts: what you build today, one result with a number, and why software for psychometric assessment interests you.
• Record it and trim it until it fits comfortably under the ten-minute limit candidates report, leaving room for conversation.
• Pick the three posting requirements you match best, write a one-line proof for each, and answer the ideal-candidate question out loud from those three lines.

Deliverable: A timed pitch recording, a three-row requirement-to-proof table, and a spoken ideal-candidate answer built from it.

Day 3 — Pride and growth stories

• Choose your proudest achievement and write it as stakes, your actions, the obstacle and the outcome, plus two sentences on why it matters to you more than the alternatives.
• For the stagnation question, write one plateau you noticed and what you changed, two learning habits you actually keep, and one skill this role would stretch.
• Rehearse both answers aloud, replacing every vague 'we' with what you personally did.

Deliverable: Written and rehearsed answers to the proudest-achievement and stagnation questions, each ending in a concrete outcome.

Day 4 — Coding fundamentals in your strongest language

• Solve the lease-record overlap problem by sorting start and end events and sweeping to find peak concurrency, stating O(n log n) time and how you break ties when one lease ends exactly as another starts.
• Solve the rolling failure-rate problem with a per-destination sliding window (a deque of timestamped outcomes plus running counts) and explain eviction and the low-traffic case.
• Solve the projection-diff problem by reading both sides in key order and merging them, or by batching lookups, instead of issuing one point read per row.

Deliverable: Three working solutions, each with a complexity note and the edge cases it handles.

Day 5 — SQL and a production debugging walkthrough

• Write the version-gap and relay-lag query using LAG over a per-entity ordering, and test it on an entity with a single row and one with a skipped version.
• Fix the tag-and-share join fan-out by aggregating each child table before joining, and explain why the row count multiplied.
• Talk through the stalled-table incident out loud: confirm the queries are waiting on a lock, identify the schema change holding or queued for it, and explain how to run that migration safely next time.

Deliverable: Two tested queries and a written step-by-step debugging sequence for the stalled-table incident.

Day 6 — Design and your own project deep dive

• Design the bulk write endpoint that a migration script retries blindly: idempotency keys per item, per-item results, a batch size cap and defined behaviour on partial failure.
• Pick one system you built and outline its components, one trade-off you made, one failure you handled and one thing you would change.
• Write a short motivation statement on why you want to build software that assesses personality and potential.

Deliverable: A one-page design for the bulk endpoint, an outline for a project walkthrough, and a written motivation statement.

Day 7 — Leadership, logistics and a full mock

• Work out your notice period, booked leave and any relocation steps, and say your start-date answer in one sentence tied to signing the offer.
• Write three or four questions for leadership about product direction and the engineering team's current challenges.
• Run a full mock covering your pitch, one behavioral story, one coding problem and your questions, then redo the weakest part.

Deliverable: A one-sentence start-date answer, a list of leadership questions, and notes from a completed mock with the weakest part redone.

Behavioural preparation

Every question candidates report for this loop is about self-awareness, motivation and growth, and candidates say assessment results often frame these conversations. Rehearse stories that match how your assessment describes you, keep each story short, and make sure it shows what you did and why it mattered to you.

1. Introduce yourself and your background, keeping to the skills most relevant to this role.
2. Why do you want to build software that assesses people's personality and motivations?

What do you think about the personality and motivation tests you took?

Medium · Behavioral and Culture Alignment

Approach

1. This tests self-awareness and candor: can you reflect on a description of yourself without flattering the test or getting defensive? Cover two layers: what taking the tests was like and, if you saw your results, what they said about you.
2. Before the interview, reread any results or feedback you received and pick one or two findings that rang true, each with a concrete work example (e.g. "it said I prefer autonomy; I did my best work owning a migration end to end").
3. If a result surprised you, nuance it instead of rejecting it: personality and motivation results describe preferences and tendencies, not skill, and behavior shifts with context. Explain the situation where you act differently.
4. Give constructive feedback on the experience itself: length, clarity of the items, how easy it was to answer honestly, and how the results were shared with you, if they were. Frame each point as an observation plus a suggestion, not a complaint.
5. Avoid both extremes: gushing ("it was spot on") sounds ingratiating, and calling psychometrics pseudoscience sounds closed-minded.
6. End on an action: how one insight changes the way you work with a team (e.g. "knowing I decide fast, I now write a short design note and ask for objections before committing").

Follow-up

• How would a teammate describe you, and would it match the tests? Name one trait they would confirm and one they would qualify, each with a short work example.
• Did you answer as you are or as you'd like to be? Be honest, name an item where you hesitated and why, and explain why candid answers are the only useful ones.
• Should tests like this drive hiring decisions? Argue they are one input next to structured interviews and work samples, better for shaping questions than as a sole pass/fail filter.

How are you certain that you will not stagnate in your career?

Medium · Behavioral and Culture Alignment

Approach

1. This tests whether you own your growth or expect a job to hand it to you. Don't claim certainty; reframe honestly: nobody can guarantee it, but you have a repeatable habit and a record of acting when you plateau.
2. Lead with evidence: one moment you noticed you had stopped learning and what you changed (moved to a harder area, joined on-call, picked up a new layer of the stack). Spotting and acting on a plateau is the core of the answer.
3. Name two or three concrete habits rather than ten vague ones, e.g. reading the source of libraries you depend on, writing postmortems, a quarterly review of what you learned, asking stronger engineers to review your code.
4. Quantify what past growth produced, e.g. "became the go-to reviewer for the data layer within six months" or "learned Go and shipped a service in it within a quarter". Outcomes make the habit believable.
5. Look forward: name one or two skills this role would stretch, drawn from the job description, and how you'd measure progress in a year, e.g. owning a service end to end including its on-call.
6. Avoid the answers that backfire: "I'm a fast learner and passionate" with no proof, a list of courses and certificates with nothing applied, or hinting you'll leave if promotion doesn't come quickly.

Follow-up

• What would stagnation look like for you in this role? Name two early signals you'd watch for, such as only solving familiar problems or code reviews no longer teaching you anything.
• What have you learned in the last six months? Name one specific skill, how you learned it, and where you used it on real work.
• What would you do if this role stopped challenging you? Say you'd raise it early with your manager and propose a stretch project before considering a move.

What is the one thing you have done in your professional or personal life that you are most proud of?

Easy · Behavioral and Culture Alignment

Approach

1. This tests your values: what you count as success reveals what drives you, so the choice of story matters more than its size. Pick one achievement where your own actions were decisive and you can say why it matters to you.
2. Prefer a story with real difficulty and clear ownership: rescuing a stalled project, building something from zero, getting a junior colleague to independence. A personal one (e.g. a career switch into software) works if the persistence it shows transfers to work.
3. Tell it in four beats: the stakes in two sentences, what you did ("I" for your part, "we" for the team's), the obstacle that nearly stopped you, and the outcome, then say why this beats the other achievements you considered.
4. Spend real time on why you're proud; that is the actual question. "Because I kept going after the first two approaches failed" and "because the people I trained now run it" say very different things about you.
5. Make the outcome concrete: what was different afterwards, for whom, and for how long; for a personal story, duration and consistency (e.g. "two years of evenings") carry the same weight.
6. Avoid a trivial pick, a team win where your role is vague, anything that takes credit from others, or a story too private for an interview. Keep it to about two minutes and let them ask for more.

Follow-up

• What would you do differently? Name one concrete decision you'd change and what it taught you, without undercutting the achievement.
• Do you have an example from the other side of your life? Keep a short backup story ready from work or personal life and say briefly why you led with the first.
• Who else made it possible? Credit specific people by role and state clearly which parts were yours.

What makes you the ideal candidate for this position?

Easy · Behavioral and Culture Alignment

Approach

1. This is a matching exercise: give a concise, evidence-backed case that your strengths meet this role's needs. Aim for about 90 seconds: a one-line thesis, three short proofs and at most one differentiator.
2. Prepare from the job description: pick the three requirements that matter most (usually a core technical skill, a kind of problem, and a way of working) and write a one-line proof from your own experience for each.
3. Open with the thesis in your own words, e.g. "I'm an engineer who takes features from design to production and keeps them reliable once users depend on them", then give each proof with a number: latency cut, users served, release cadence improved.
4. Add one differentiator other qualified candidates may lack: a cross-functional skill, a mentoring record, or real interest in the product's domain. Tie it to what the posting asks for, not to guesses about the team.
5. Raise a gap yourself only if it is obvious from your CV and likely to be the interviewer's first objection, and keep it to one sentence plus how you are closing it; otherwise wait until you are asked.
6. Avoid reciting your CV in order, generic adjectives ("hardworking team player"), or comparing yourself to candidates you know nothing about. Close by offering to go deeper on whichever proof matters most to them.

Follow-up

• What is your biggest gap for this role? Name a real but non-core one and the specific steps you're already taking to close it.
• Why you over someone with more experience? Point to ramp-up speed, ownership, and one example where you delivered beyond what your level expected.
• What would you achieve in your first 90 days? Outline learning the codebase and shipping small fixes early, then owning a scoped feature, with a check-in on expectations.