Loading...
GCC and captive centres, senior. 55 questions across 7 blocks, about 28 hr of work.
Have a job description? Paste it or upload the PDF and get a plan for that exact role.Build from a JD →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.
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.
Return a strong ETag on GET, require If-Match on writes, and reject a stale token with 412 Precondition Failed so a lost update becomes a visible error rather than silent data loss. What makes it correct is that the comparison and the write must be one atomic operation - an UPDATE guarded by the version in its WHERE clause - because a SELECT then UPDATE reintroduces the race.
Use NOT EXISTS for customers with no recent order because it expresses an anti-join and avoids NULL traps. NOT IN can return no rows if the subquery contains NULL, and LEFT JOIN becomes wrong if filters are placed in WHERE. Use this SQL answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects null semantics to the point an interviewer is testing.
Nines only mean something as a downtime budget over a stated window, and dependencies in series multiply: five hard dependencies at three nines each put your own ceiling near 99.4 percent, so the target is met by removing dependencies from the critical path rather than by asking each owner for more nines.
Name the competing demands, say what you dropped or deferred and who agreed to it, and describe how you told the people whose work was affected. Interviewers listen for a decision made in the open, not for evidence that you absorbed the overload quietly.
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.
A saga has no rollback. Each step already committed in its own database and was visible to everyone, so you can only run new forward transactions that semantically offset it. Compensations are not atomic, some actions cannot be compensated at all, and compensations themselves fail - so a saga needs idempotent handlers and an ordering rule for irreversible steps.
A partial index only contains rows matching its predicate, so indexing WHERE deleted_at IS NULL stores five million entries instead of forty million - smaller, shallower, and far likelier to stay cached. The catch is the planner only uses it when it can prove the query predicate implies the index predicate, and it does nothing about dead rows still in the heap.
Every distinct combination of label values is a separate time series with its own index entry, so an unbounded label multiplies series count by the number of users rather than adding one dimension. Metrics are the wrong tool for per-entity questions: keep labels bounded, move per-user debugging to exemplar-linked traces, and guard against the next unbounded label.
Reconstruct the original context first and test whether it has genuinely changed or whether you simply inherited a cost you dislike, then write a new record that supersedes rather than edits the old one, price the half-reversed state explicitly, and get agreement from the teams who now carry the consequences.
CPU is compressible, so the kubelet throttles it rather than evicting for it. Eviction comes from memory, ephemeral storage or inodes - and which pods die is decided by QoS class, not by who caused the pressure. Check node conditions and eviction thresholds first, then fix the requests and limits so critical workloads are Guaranteed rather than BestEffort.
A training row must contain only feature values that were knowable at its own event timestamp. A naive equality join on entity id attaches whatever the feature table holds now, including values derived from after the event, which leaks the future and produces offline metrics that collapse in production.
Scrum's Sprint assumes work that can be planned a fortnight ahead, held stable for that fortnight, and shaped into a goal worth committing to. Where one of those fails - interrupt-driven support, single-item research, hard external gates - a flow-based approach fits better.
Make the write idempotent before you make it correct: partition-level replace rather than append, so rerunning a day produces the same result whether it runs once or five times. Then work out how far the contamination spread, because a downstream table that accumulated rather than recomputed will not fix itself when the source is repaired.
Whiteboard each one for real, on paper, before you look. A design answer you have only read is one you cannot produce under questioning.
Treat it as a confirmed breach until proven otherwise: preserve logs, scope who saw what, and start the disclosure clock alongside the investigation. The cause is almost always tenant scoping living in application code, where one forgotten filter leaks everything - so move enforcement below the code, to row-level security.
A single threshold on a single window cannot separate a real outage from a brief spike, so it either pages on noise or misses slow burns. Replace it with multi-window multi-burn-rate alerting: a fast rule that pages and a slow rule that files a ticket, each gated by a short window so a spike that already stopped does not keep paging.
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.
Two transactions can each run the SELECT before either commits, so neither sees the other and both inserts succeed. The fix is a serialisation point the database owns - a unique index on a natural or client-supplied key - plus a defined answer for whoever loses the race. It also connects idempotency to the point an interviewer is testing.
Permission data is as privileged as the code that reads it, so a bulk write to it needs the same review, staged rollout and reversibility as a deploy. Derive grants from a source of truth rather than stamping them, assert tenant invariants continuously, and know how long a cached decision keeps the mistake alive.
Express both attributes as measurable scenarios, then lay out the intermediate designs so the choice is between numbers rather than adjectives. Where the conflict is genuinely irreducible, escalate to whoever owns both consequences and record what was sacrificed, with a trigger for revisiting.
Re-pointing traffic at the previous version is only safe if nothing else moved with it. The feature transformations, the input schema and any consumer calibrated to the current score distribution may have changed, so the unit of rollback is the model plus its features and its contract.
The rounds where there is no correct answer, only a defensible one. State your assumptions out loud; that is what is being scored.
An acknowledged write is only guaranteed on the replicas that acknowledged it, so a read served elsewhere can legitimately return the previous version. Locate the staleness - replica, secondary index or cache - then buy read-your-writes for that operation only, and price what it costs during a partition.
A global limit protects the service from overload but says nothing about how capacity is divided, so one tenant can consume most of it while staying under the ceiling. Fairness needs per-tenant accounting: a token bucket for the steady-state contract, a concurrency limit so expensive requests cannot hog workers, and round-robin queueing so a burst queues behind itself.
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.
gRPC multiplexes many calls over one long-lived HTTP/2 connection, so a balancer that distributes connections pins each client to one backend for its lifetime. Balance per request with an HTTP/2-aware proxy or client-side subchannels, and bound connection age so scaling out actually moves traffic.
Establish what the product is load-bearing for and what the deadline really is once procurement, security review and change freezes are subtracted, then price four options against that calendar: pay for an extension, move to the vendor's successor, replace it, or absorb the capability.
The prediction record must name the model version, the exact feature vector as served with its values, the identifier of the code that computed those features, the decision and any thresholds or overrides applied. Reconstruction after the fact is not possible, because feature pipelines and reference data have moved on.
When a Terraform plan wants to destroy production, stop and identify whether the diff comes from state drift, a provider change, a renamed resource or real configuration intent. Do not approve until the blast radius is understood. It also connects IAC to the point an interviewer is testing.
Very little has to be common, and one thing genuinely does: teams releasing one product must share a Definition of Done. Standardise what a joint release depends on, leave cadence, boards and estimation units local, and refuse uniformity whose only benefit is a comparable dashboard.
Adding a processor in another country is a transfer and a sub-processor change at once, so the work is a lawful transfer mechanism, the notice your own customer contracts require, and an engineering boundary that sends the provider the minimum and keeps nothing at their end.
Return to whatever went worst this week. One session on a genuine weakness is worth three on material you already have.
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.
Decide which groups you are testing across and how you will obtain that attribute, choose one fairness definition and justify it - because the common definitions are mathematically incompatible and cannot all be satisfied - then report performance and error rates per group with sample sizes and intervals attached. It also connects bias testing to the point an interviewer is testing.
A backup job that exits zero is a belief, not a control. Establishing recoverability means agreeing an RPO and RTO, then rehearsing a restore onto clean infrastructure, measuring how long it took and verifying the result — including everything the dump does not contain.
The system is being held down by effects it now generates itself: accumulated client retries, an empty cache multiplying database load, and a queue of requests whose callers have already given up. Recovery needs shed load and a controlled ramp, not more capacity.
Every producer must have a declared answer — block, buffer to a bounded local store, or drop — chosen per event class rather than once for the whole fleet, because the default of blocking on a full in-memory buffer turns a broker outage into an outage of every service that publishes to it.
Name the single writer first, then choose which coupling you would rather own: a shared schema couples the two teams' release calendars, while a replicated copy couples them to a staleness window and obliges someone to detect and repair divergence. Both are permanent, so pick the one your organisation can pay for.
Separate the layers that can fail together: routing reachability, name resolution, identity and physical access. Then build an access path that shares none of them, keep controls failing static rather than closed, and rehearse the emergency path often enough that it is known to work.
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.
PostgreSQL compares 32-bit transaction IDs, so old rows must be frozen before the counter laps them. A rising age means vacuum is not freezing fast enough, and if it keeps rising the server eventually refuses to assign new transaction IDs and stops accepting writes.
You cannot distinguish a crashed process from a slow one, so every failure detector is a timeout and every timeout is a guess. Choose which error you can afford: declaring a live node dead risks two writers, waiting risks a stall, and only fencing makes the first survivable.
The key must contain every request input that changes the response — identity, scope, locale, device class, active flags — because anything left out silently merges two different responses into one entry. An unkeyed input is both a correctness bug and an injection surface.
Forecast from the whole spread of observed weekly throughput rather than its average, subtract the rate at which the backlog is growing, and give a date with a confidence attached. Then say plainly whether you are offering a forecast or accepting a commitment, because they are not the same promise.
The queue records that work was sent but cannot know whether the server received it, so any crash between sending and recording the acknowledgement replays the action. At-least-once delivery is the only thing a mobile client can guarantee, so the fix is to make the operation idempotent with a client-generated key persisted alongside the queued action, not to try harder to deliver exactly once.
The dialog was built as a styled div, so nothing marks the rest of the page inert. Focus was never moved in, never constrained, never restored on close, and Escape was never wired. A correct dialog moves focus in, keeps it in, restores it, marks background inert and is labelled - which native dialog with showModal gives you almost for free.
Stop treating debt as a backlog of tasks and express it as a rate — the interest you are paying in change lead time, incident load and onboarding cost — then fund only the remediation that measurably moves one of those numbers. A fixed percentage tax is easy to agree and the first thing cut under pressure.
Scale on queue depth or in-flight concurrency rather than request rate, because a GPU replica that takes minutes to load weights cannot be added after the queue has already formed. Then decide deliberately how much warm capacity to keep, since that is what you are paying to avoid cold starts.
A tag is a mutable pointer in the registry, so re-pushing it makes the same reference resolve to different content over time. Nodes that already cached the old digest keep serving it, so the fix is to deploy by digest and let the tag be a human label rather than the deployed identity.
Evidence of operation is a by-product of the control running, not a screenshot taken during the audit. Design each control so it emits a dated, attributable artefact you cannot backfill, and be able to argue completeness rather than just show samples.
Work out who owns the customer after the deal, because that decides whether this is distribution or the slow loss of your product. Price the engineering the partner's requirements will consume, and set the conditions under which you would walk away before you see the revenue figure.
Write your stories in full, prepare the questions you will ask them, and stop early.
Judge whether the term blocks the decision in front of you: if it does, ask immediately, and ask for a concrete instance rather than a definition; if it does not, note it and follow up afterwards. Then play back your understanding in your own words so the correction happens in the meeting rather than in the code.
Check whether the increment is genuinely usable before blaming the diary, because stakeholders skip reviews that give them nothing to react to. Then invite fewer and better people, ask questions that require a decision rather than applause, and be willing to say the review is the wrong forum for this product.
Stakeholder sign-off should not stall a project indefinitely. Confirm the decision owner, shrink the ask, proceed on a dated assumption, and escalate the delivery risk rather than complaining about the person. Use this stakeholder management answer to show the decision, trade-off, and evidence rather than a memorised definition.
Say it does not, then find out what the requirement behind the question is, because what decides the deal is whether the gap blocks them and what the honest path around it costs. A soft yes turns into a contractual obligation that somebody else has to deliver.
Price the whole package before you argue about base, then make one counter that names a specific number, says which components you would take it in, and justifies it against the market for the role rather than your own needs. A sequence of separate asks is what makes a recruiter stop moving.
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.
Name the one or two things that would genuinely change your answer if you had an offer, ask them of the person best placed to answer, and say why they matter to you. Vagueness here reads as indifference to the job rather than as politeness.
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.