Loading...
IT services and consulting, 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 →Breadth beats depth here, because a consultant is staffed against whatever the account needs next quarter and the panel is measuring how quickly you become useful on an unfamiliar codebase. The rounds that decide the outcome are usually the case study and the client-facing conversation: estimation, scoping, what you do when the requirement is ambiguous, and how you say no to a client without losing the account. Presales and solutioning questions appear even for delivery roles at senior levels, since anyone leading a workstream eventually writes part of a proposal.
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.
Set an agenda, ask about the business outcome and current process before any technology, and use the call to qualify rather than to collect requirements: establish who decides, what changed to make this the quarter they act, and what would have to be proven, then confirm it in a written recap.
As-is to-be process mapping starts with the process as performed, uses swimlanes to expose handoffs, baselines cycle time and rework, then designs a to-be process that eliminates work before automating it. Use this process modelling answer to show the decision, trade-off, and evidence rather than a memorised definition.
Yes, once and briefly, with an assumption attached. In a hypothetical product exercise the scored move is what follows. Separate gaps that change the design from gaps that do not, choose assumptions that keep the problem hard, write them where both of you can see them, and say which parts of the design depend on each.
Build what your users pay you for and buy the rest, correcting that heuristic for switching cost and data gravity. The comparison people get wrong is licence fee versus zero, when it is really licence fee versus salaries, on-call and opportunity cost for as long as the system lives.
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.
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.
Separate what cannot be released from what cannot be built, because the two are almost never the same thing. Then slice along business dimensions such as workflow step, rule variation or customer segment, and hide the incomplete parts behind a toggle so the release stays whole while the build arrives in pieces.
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.
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.
Indirect prompt injection is when instructions hidden in content the model reads are followed as if they came from you. Instructions and data share one token sequence, so there is no complete fix and the defence is architectural: least-privilege tools, filtered output, and human approval for side effects. It also connects llm security to the point an interviewer is testing.
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.
Treat it as a broken experiment, not a rounding issue. At two million users a 53/47 split is astronomically unlikely by chance, so something removed users non-randomly - and that something almost certainly correlated with the outcome. The result cannot be trusted in either direction, so find the mechanism, fix it and rerun rather than adjusting the numbers.
It earns its cost when several models share features and when you need offline and online parity plus feature history for correct backfills. It does not when one team runs one model, because you have added a stateful service to the request path for benefits nobody is drawing on yet.
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.
Read the data rather than the DDL: profile every column for cardinality, null rate and value distribution, use foreign-key-shaped joins to test relationships you suspect, and confirm each conclusion against a report the business already trusts before you build on it.
Whiteboard each one for real, on paper, before you look. A design answer you have only read is one you cannot produce under questioning.
Show the arithmetic once, then convert the gap into a decision the customer can take: what the stated budget genuinely buys as a coherent first phase, what the full scope costs, and which specific outcome is deferred. Never deliver the full scope at the reduced number.
Reduce dependencies before coordinating them, by moving team boundaries towards whole slices of value and replacing synchronous handoffs with contracts. Coordinate what remains with a visible dependency board and one ordered backlog. SAFe buys alignment and a planning cadence at real cost in batch size and process.
Inventory everywhere the model is coupled to behaviour, then use the eval set as your migration harness, shadow the candidate on live traffic to compare without user exposure, and re-measure cost and latency because both shift. Use the migration to delete instructions that only compensated for the old model.
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.
Rewrite it as a quality-attribute scenario: a named stimulus arriving at a stated rate, hitting a stated system state, with a response measured at a percentile over a defined window. A number with a load figure, a duration and a named sacrifice is designable and testable; a list of maxima is not.
Revoke once in the authorisation store, then propagate to the index ACLs, every cache holding text or results, any derived summaries and embeddings, and the conversation transcripts still carrying passages. Answers already delivered cannot be recalled, so the guarantee you offer is a bounded window rather than erasure.
Preventing double booking seats means claiming the seat before payment, not racing two payments and reconciling later. A short atomic hold serialises buyers, payment only starts for the winner, and uncertain payment outcomes are settled by reconciliation rather than silent expiry.
The rounds where there is no correct answer, only a defensible one. State your assumptions out loud; that is what is being scored.
Choose a work sample with real decisions in it that you still understand line by line and are allowed to share. Be ready to admit which parts were other people's or a tool's, what is wrong with it, and what you would change, because the interviewer can open any file and ask why it is there.
Separate what is technically true from what you would prefer, write it as a one-page recommendation with named conditions that would change your view, and escalate to the level that can accept the risk. If overruled, get the risks recorded and stop objecting.
Usually both are correct and they are answering different questions, so stop comparing totals and reconcile down to the first point of divergence. Publish a bridge that explains the gap in named components, then have one definition made authoritative with a named owner instead of declaring a winner.
Do not open with the Scrum Guide. Show what pre-assignment costs in flow terms, since assigning everyone an item on day one puts the whole Sprint in progress at once and stretches cycle time. Then find out what the manager needs from it and offer a mechanism that meets that need without the assignment.
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.
Write the entry criteria before the parallel run begins so the decision is a checklist rather than a mood, ramp through a stepped population with an abort condition at each step, and recognise that rollback stops meaning redeploy once the new system takes its first authoritative write.
Split LLM cost by feature and by line: uncached input, cached input, output, retries and hidden callers. Find which line moved before cutting anything. A collapsed prompt-cache hit rate or longer replies can double a bill with no change in traffic; fix those before you downgrade a model.
Vectors from two models live in unrelated spaces, so there is no incremental path — you re-embed and reindex the whole corpus. The real cost is running both indexes side by side long enough to compare them on a gold set, keeping query and document models in step, and retuning thresholds calibrated on the old scores.
You delete from the operational store, propagate to every derived copy you can enumerate, and for the copies you cannot rewrite you rely on crypto-shredding, keyed compaction, snapshot expiry and exclusion at the next retrain.
Return to whatever went worst this week. One session on a genuine weakness is worth three on material you already have.
A bare yes is a contractual representation you cannot support and a bare no scores zero, so the answer is a qualified compliance marking with the explanation carried where the evaluators will read it. Use the clarification window before you are forced to choose.
Triage by what is expensive to reconstruct after they leave rather than trying to capture everything, watch the work rather than only interviewing about it, and verify what you are told against system evidence. Capture the decisions and the exceptions, because the happy path can be rebuilt and the judgement cannot.
Separate the technical disagreement from the interpersonal one, since only the first belongs in the open. Speak to each privately about specific observed behaviour and its effect, look for a structural cause such as unclear ownership, and escalate when it becomes conduct or performance.
Spend the first week building an evidence map from money, traffic, incidents and deploys rather than from code, and interviewing the people who touch it with one fixed set of questions. Spend the second producing a risk-ordered plan of stabilisation before structure, with unknowns listed explicitly.
Subtract the answer reservation and the fixed prompt first, give retrieval a token allowance rather than a passage count, and let conversation history have what remains under an explicit eviction policy - because history is the only term that grows every turn while everything else stays flat.
Read the failing queries first and sort them into causes, then apply the matching lever — rewriting for vague queries, filters for scope errors, smaller retrieval units for buried answers, lexical retrieval for literal terms, a reranker where recall sits below the cut — each with the metric that proves it worked.
Photo storage should separate originals from thumbnails. Originals are large, rarely read and irreplaceable, so keep a canonical erasure-coded object; thumbnails are small, hot and rebuildable, so replicate them, cache them at the edge and address them by content or transform version.
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.
Decide which documents deserve to be current before updating anything, because each one is read for a different decision and drift matters in only some of them. Retire what nobody reads, point people at the real record of truth, and cost the maintenance honestly rather than promising to keep everything in step.
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.
Find out whether the blocker is a real control gap, a wording problem, or a policy that cannot bend, because only one of those is an engineering conversation. Then work with the reviewer rather than round them, and never let sales rewrite an answer to unblock it.
Earn the right to the claim by attributing infrastructure cost per tenant, then separate cost caused by their usage shape from cost caused by your own design. Architecture can change the shape; the decision about who pays is commercial, and it needs the engineering evidence to happen at all.
Report two rates separately: ungroundedness, meaning claims the provided sources do not support, and factual error, meaning claims wrong about the world. Measure per claim, publish the abstention rate beside them, and name the query set that produced the numbers. Use this hallucination answer to show the decision, trade-off, and evidence rather than a memorised definition.
Ask the index directly whether the old text is still there, because that single check splits the problem into change detection, queue or write failure, a retire step that left duplicate chunks, or a downstream cache. Then fix the reason you learned about it from a user rather than an alert.
Reconstruct the defect's exact path, then ask at which layer a test could have seen it and why none did, distinguishing a missing case from a whole condition your environments cannot reproduce, and fix the class rather than adding one test for this instance.
Separate the leverage from the merit: the renewal makes the request urgent, it does not make it valuable. Work out the real problem underneath the requested solution, test whether it generalises to other accounts, and price the full cost including permanent maintenance rather than the build estimate. Then choose deliberately between roadmap, configuration, services and no.
Treat thin evidence as a missing decision rather than a weak yes, because a hire made on impressions is a coin flip dressed as a process. Separate what was observed from what was inferred, find which required signals nobody actually tested, and close that gap with a targeted follow-up rather than overruling the room or rubber-stamping it.
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.
An inverted index maps terms to posting lists, built by an analysis chain that must run identically over documents and queries, ranked by BM25 plus business signals, and fed by a change stream of denormalised documents with reindexing behind an alias treated as routine.
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.
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.
Stop arguing about the label and test the request against the accepted criteria: if the behaviour or the effort changes, it is a change whatever it is called. Hand the product owner a delta and options rather than a refusal, and keep a log so a fortnight of small clarifications stays visible.
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.
Re-plan the remaining time against risk rather than against the test-case order, then report coverage as an explicit list of what was tested, what failed and what was never opened. The recommendation is yours; the decision to ship belongs to whoever carries the business consequence.
Translate each finding from security language into the same terms the roadmap is already prioritised by — a concrete failure scenario, its business cost, and the cheapest point in the system's lifecycle to fix it — rather than asking for time on the strength of the threat model alone.
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.