GCC and captive centres, senior. 31 questions across 7 blocks, about 16 hr of work.
A GCC interviews for the stack and the domain it actually runs, so the questions are concrete where Big Tech's are abstract: the parent's platform, its data model, and the regulatory shape of its industry. Puzzle-style algorithms show up in the screen but rarely decide the outcome; depth in the language and framework you claim, plus evidence that you can hold a design conversation with a product owner eight time zones away, usually does. Expect at least one round that is really about domain vocabulary, because a payments GCC has been burned by engineers who could build anything and understood nothing about settlement.
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.
Trace one real unit of work end to end, read the operational artefacts rather than the marketing ones, interview the people who handle exceptions, and publish a glossary inviting correction. Understanding shows as prediction and knowing why a rule exists; fluency only names things.
Evaluate architectural trade-offs in Authentication & Authorisation between consistency, throughput, operational complexity, and data durability at scale.
Evaluate architectural trade-offs in Data Modelling 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.
Model the state changes and invariants rather than the nouns the business names, and go looking for reversal, amendment, partial completion and manual override before committing to a shape. Domain-driven design earns its keep where rules are contested; on CRUD and reporting it is ceremony.
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.
Give every entity a surrogate primary key but keep a unique constraint on the business identifier, and model a negotiated price as a row with a validity period rather than a mutable column - then copy the agreed price onto the order line so history cannot be rewritten.
Pick a write policy that matches your consistency requirement rather than treating invalidation as an afterthought, then defend against the three failure modes that only appear under load: stampede on expiry, staleness from lost invalidation messages, and unbounded growth from missing eviction.
DORA now publishes five measures, three of throughput and two of instability, and they work because improving one dishonestly tends to show up in another. Report them as trends for a delivery system rather than as a per-team league table, and never let them into individual performance conversations.
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 Acquiring Domain Knowledge by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Diagnose performance degradation in Authentication & Authorisation 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.
Diagnose performance degradation in API & Contract Design 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.
Treat both as evidence, not verdicts: a document records an intention on a date, an expert reports today's practice inside their own scope. Most contradictions resolve as staleness, scope or the exception path, and practice departing from a control is a finding to escalate rather than a requirement to build.
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 DBA & Operations by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Diagnose performance degradation in Caching by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Diagnose performance degradation in Architecture Scenarios 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 Domain Modelling in Practice by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Default to server-side sessions in an opaque HttpOnly cookie, because revocation is a row delete and the browser cannot read the credential. Choose JWTs only when a resource server must validate without calling the issuer, keep them short-lived, and pin the algorithm, issuer, audience and expiry on every verification.
Decide by which attributes are filtered or constrained, not by how many exist. Anything a query filters, sorts or validates on becomes a real typed column; the open-ended remainder goes in a JSONB document with a GIN index, and entity-attribute-value is the fallback that costs you every guarantee.
Diagnose performance degradation in Full Case Studies by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
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.
Judgement is an unwritten rule plus a genuine discretion, so separate the two. Sample real decisions to find the factors deciding most cases, automate the unambiguous ends, and model the discretionary middle as a recorded decision carrying its inputs, recommendation and reason.
Diagnose performance degradation in Backend Scenarios 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.
Diagnose performance degradation in Consistency & Availability by isolating thread contention, I/O bottlenecks, and resource limits before attempting code fixes.
Find out why it happened before deciding what to do about it, because duplication is usually a symptom of a discovery or ownership failure that consolidation alone will not fix. Then choose deliberately between merging, keeping both, and letting one wither, on the basis of migration cost rather than tidiness.
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.
Usually yes for the label and no for the concept. A fossil name is still the word that lets you and the business point at the same thing, so keep it as the shared term, but model what the queue is for today rather than the channel it was named after.
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.
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.
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.