Startups and scale-ups, senior. 31 questions across 7 blocks, about 16 hr of work.
There is no calibration to hide behind, so the loop is whatever the founder or lead believes predicts performance - most often a practical build, then a conversation about the trade-offs you chose. Breadth is the bar: the same person is expected to ship the feature, its migration, its metrics, and its on-call. Behavioural rounds are less about principles than about tolerance for ambiguity and whether you make decisions when nobody hands you the requirement.
Front-load breadth, put the two hardest rounds mid-week when you still have time to react to a bad session, and keep the last evening for a timed loop and your stories. Two hours a night done every night beats one eight-hour Saturday, because retrieval improves with spacing and a single long session mostly produces the feeling of having worked.
Read the sheets for the core sections of this track at speed. Mark the items you could not answer; they become your revision list all week.
A CPU limit is a quota per scheduling period, so exceeding it means the process is throttled until the next period and gets slower. A memory limit has no throttle: the kernel reclaims what it can and then the cgroup OOM killer terminates a process, which surfaces as exit code 137.
Colour is not a signal on its own, so each error needs text, and that text must be programmatically tied to the field with aria-describedby and marked with aria-invalid. On submit, move focus to a summary or the first invalid field rather than hoping a live region is announced.
Evaluate architectural trade-offs in Authentication & Authorisation between consistency, throughput, operational complexity, and data durability at scale.
The stack and concept questions this loop opens with. Answer before reading, and note which probes you missed rather than whether you got it right.
Build it from the nearest native element so role, focusability and key handling come free, decide the keyboard model before the visuals, move and restore focus deliberately, and add ARIA only for state the markup cannot express - it changes what assistive technology announces but adds no behaviour.
Model permission as a relationship between a subject, a role and a specific resource, not as a role stamped on the user, and push the check down into the data access predicate so a list query and a single-record fetch are authorised by the same rule.
Work outward from the plan: confirm the index is actually usable for the predicate as written, then check whether the optimiser is choosing to ignore it because of selectivity, stale statistics, or a type or collation mismatch that makes the predicate non-sargable.
State is the mapping from a config address to a real resource ID, so it is the only thing that tells Terraform whether to create or update. Drift, imports, refactors and concurrent applies are all consequences of that mapping being separate from both the code and the infrastructure.
Establish whether the test could ever have detected the effect you cared about, because an underpowered null tells you nothing; then read the confidence interval rather than the verdict and decide whether to extend, test a larger change, or accept that the assumption was wrong.
Whiteboard each one for real, on paper, before you look. A design answer you have only read is one you cannot produce under questioning.
Diagnose performance degradation in Authentication & Authorisation by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Build one immutable artefact, promote that same artefact through environments behind ordered quality gates, and deploy so traffic can be shifted back instantly. Rollback only stays possible if schema changes are backward-compatible expand-contract steps decoupled from the code deploy.
Diagnose performance degradation in Accessibility by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Diagnose performance degradation in Data Modelling by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
The rounds where there is no correct answer, only a defensible one. State your assumptions out loud; that is what is being scored.
Lag is the integral of arrival rate minus service rate, so establish which of the two moved and whether the consumer is slow or stalled. Check lag per partition before per group, rule out a rebalance loop, and remember that adding consumers beyond the partition count does nothing.
Diagnose performance degradation in CI/CD by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Diagnose performance degradation in Angular & Vue by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Diagnose performance degradation in DBA & Operations by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Diagnose performance degradation in Discovery & Research by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Return to whatever went worst this week. One session on a genuine weakness is worth three on material you already have.
Diagnose performance degradation in Backend Scenarios by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Replace the stored key with OIDC federation so each job exchanges a short-lived signed token for temporary credentials, then make the trust policy specific to a repository, branch or environment. Also narrow the pipeline's own token, pin third-party steps to commit SHAs, and attest what you built.
Diagnose performance degradation in Browser & Rendering by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Every step is chosen to hold weak locks briefly - add the constraint invalid and validate separately, index concurrently, backfill in committed batches - behind a restore you have rehearsed and timed, and a pool small enough that one blocked DDL statement does not exhaust it.
Run the rounds back to back with a timer and no notes. The point is stamina and switching cost, which no amount of single-question practice reveals.
A flat p50 rules out a uniform slowdown, so the tail belongs either to a subset of requests or to a queueing effect. Partition the latency histogram by instance, endpoint and tenant before naming a cause, then confirm with traces, GC logs and pool-wait metrics.
Decide by what the managed service removes from your on-call load versus which controls it removes from you, and price the option honestly rather than by sticker rate. The bills that surprise teams are internet egress, cross-zone traffic, and capacity that is provisioned but idle.
Diagnose performance degradation in CSS & Layout by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Diagnose performance degradation in Indexing by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Diagnose performance degradation in Execution & Trade-offs by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Diagnose performance degradation in Introduction & Career Narrative by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Write your stories in full, prepare the questions you will ask them, and stop early.
Declare it, take the incident commander role explicitly, and mitigate before you diagnose - roll back or shed load first, understand later. Keep one channel as the record, publish updates on a fixed cadence, hand over rather than push through, and let the review produce owned actions instead of narrative.
Find out what the date is being used for, then commit to something you can actually control — a timeboxed discovery end, a date for the date, or a narrow first slice — and never issue a single-point estimate for scope that is still undefined.
Name the clock and what it was costing, say which facts you had and which you chose not to wait for, classify the call as reversible or not, act at the level you were authorised to and say so, and record the reasoning at the time so it can be judged on what you knew.
Change what the meeting is about rather than how it is run: inspect the board against the Sprint Goal instead of polling individuals, stop being the person addressed, and push detail into a follow-on conversation. If the Sprint has no real goal, no format will save the event.
Scope is the union of the track's sections, the rounds this employer type asks regardless of role, and the industry if you named one. Weights above 1.0 pull a section up the order; below 1.0 push it down. Nothing is excluded - a deprioritised section still appears when its best question is the most relevant thing left.