Cisco Software Engineer Interview Guide

Interviewing at Cisco

• Practice bank: 12+ questions
• Rounds: 3
• Typical prep: 2–4 weeks
• Interview reports: 9

Interview rounds

Round	Questions
Online Assessment	1
Technical Screen	4
Onsite	7

How hard is the Cisco Software Engineer interview?

Difficulty	Share	Questions
Easy	75%	9
Medium	8%	1
Hard	17%	2

What Cisco actually tests for

Topic	Share	Questions
Software Engineering Fundamentals	58%	7
Coding & Algorithms	25%	3
Behavioral & Leadership	8%	1
Statistics & Math	8%	1

The 60-second brief

Cisco's product range covers enterprise networking, security, data center and cloud management. The material behind this guide names Duo and Umbrella in security, ACI in the data center, Silicon One for hardware acceleration, Meraki for cloud management, and Webex and Talos elsewhere. Software Engineer work spans that whole range. At one end is C and C++ for packet processing, platform software and drivers on routers and switches. At the other are back-end services, APIs and web front ends in Java, Python, Go or TypeScript. Candidates on teams close to hardware report more low-level C and OS questions, so ask your recruiter which team the role sits in.

Cisco candidates report 5 rounds · ≈ 4-6 weeks. The stages below are what candidates describe, not a published process.

What a Software Engineer does at Cisco

Across those teams the reported interview topics are consistent. They are data structures and algorithms; computer networks (packet flow, ARP, DNS, DHCP, VLANs, firewalls, and authentication protocols such as RADIUS and TACACS+); operating systems and memory; and object-oriented and system design. Networking fundamentals are described as covered for candidates on almost every team. If you have only practised algorithm problems, you are exposed in the networking, database and OS multiple-choice questions of the online assessment and in the technical rounds.

The day-to-day work described for the role includes code review, automated unit and integration tests, and design documents. It also includes coordinating with hardware engineers, product managers, QA and site reliability engineers across time zones. The techno-managerial round is described as centred on your resume projects. Be ready to explain the decisions behind anything on your resume, and to write code for any technique you say you have used, such as BFS/DFS or dynamic memory management.

The Cisco interview process

Cisco candidates report 5 rounds · ≈ 4-6 weeks. The stages below are what candidates describe, not a published process.

Online Assessment

Candidates describe an online assessment with algorithmic coding problems plus multiple-choice questions on computer networking, databases and operating systems. It runs on a platform such as HackerRank or through a hiring event such as Code with Cisco. Coding-only preparation fails on the multiple-choice half. Those questions reward recall of mechanics, and algorithm practice does not give you that: what DHCP does before a host has an address, what a join or an index is for, how paging or a context switch works. For the coding half, practise timed problems in the reported string and array category (range compression, look-and-say, distinct pairs summing to K). Getting the edge cases right matters as much as choosing the algorithm.

What it evaluates

• Whether your code handles edge cases the examples do not show: empty input, a single element, a run that ends at the last index, duplicate values
• Whether you can answer networking, database and operating-system multiple-choice questions from understanding rather than by guessing between two plausible options
• Whether your approach's complexity fits the stated input bounds

How to prepare

• Take a timed set of string and array problems (range compression, look-and-say, distinct pairs summing to K) in a plain browser editor, and write your own tests for empty and single-element input before submitting
• Build a one-page recall sheet for the multiple-choice topics: OSI and TCP/IP layers, ARP, DNS, DHCP, the TCP handshake versus UDP, SQL joins and keys, processes versus threads, paging and deadlock conditions. Quiz yourself from it.
• Treat every worked example in a prompt as the specification, including the exact output format, before you write code

Recruiter Screen

Candidates describe the recruiter screen as a review of your background, communication skills and team preferences. Team preference matters here because the process varies by team, business unit and location. Meraki, Duo, CX and core hardware and software are the examples given. Use the call to find out which team the role sits in and whether the technical rounds lean toward C and OS, networking, or services and design, and state any hard constraints now, such as start date, location or work authorisation, rather than at offer stage.

What it evaluates

• Whether you can summarise your background and resume projects clearly and briefly
• Whether your team preference is specific enough to act on, naming the kind of work (platform C/C++, cloud services, security) rather than 'anything'
• Whether your hard constraints fit the role before a loop is scheduled

How to prepare

• Prepare a short spoken summary of your background that ends on the kind of team you want and why
• Ask which team or business unit the role belongs to, which languages that team writes, and whether the technical rounds lean toward C and OS, networking, or services and design
• Write each constraint (start date, location, authorisation, competing deadlines) in one line before the call and state them as facts

Technical Rounds

Candidates describe two to three technical sessions covering live coding, low-level system understanding, computer networks and object-oriented design. Remote rounds are reported to run over Webex. Practise narrating while you code on a video call with screen sharing. The reported questions in these categories show the range. Algorithms: House Robber, expanding a string with nested repetition, and BFS and DFS written both iteratively and recursively. C and pointers: reversing a singly linked list in place, and setting, clearing and toggling register bits. Networking: the packet flow when a browser requests google.com. Object-oriented design: a chessboard with piece classes and move validation. If a networking or systems question goes past what you know, say how you would troubleshoot it from first principles. Do not stop at 'I don't know'.

What it evaluates

• Whether you clarify input size, edge cases and constraints before coding, and state a brute-force approach and its complexity before optimising
• Whether you can write correct C with raw pointers and bit masks, not only high-level code
• Whether you can trace a request through the stack layer by layer: DHCP, DNS, ARP, the TCP handshake, TLS and routing
• Whether an object-oriented design gives each class a clear responsibility and enforces its rules, with move validation in one place rather than scattered

How to prepare

• Write list reversal and set/clear/toggle-bit functions in C from a blank file, then test an empty list, a single node and the highest bit of the register
• Say the google.com packet flow aloud end to end, then repeat it naming the layer and protocol at each step
• Implement BFS and DFS on the same graph, recursively and with an explicit queue or stack, and confirm both reach the same set of nodes
• Model the chessboard (piece hierarchy, board, move validator, initial setup), then add castling and note which classes had to change

Techno-Managerial Round

Candidates describe engineering leaders running this round. It focuses on your resume projects, decisions you made under real constraints, and team alignment. It mixes technical depth with judgement. Prepare to go from a project summary down to a specific design choice, including the alternative you rejected and why. Candidates report deep questions on the projects, languages and frameworks listed on their resume, so treat every line as open to questions. A claim you cannot back with detail costs more than leaving it off.

What it evaluates

• Whether you can explain the architectural decisions behind a listed project, including the alternative you rejected and the constraint that decided it
• Whether your claimed ownership matches the detail you can give, separating what you built from what the team built
• Whether you describe a technical disagreement or a change in requirements with a concrete account of what you did and what happened

How to prepare

• For each resume project, write the problem, your role, one key decision with its alternative, and what you measured. Cut anything you cannot defend under follow-up.
• Prepare four to six STAR stories covering technical conflict, a tight deadline, a failure and an initiative you drove. Keep each Action about your own contribution.
• Rehearse the reported prompt about working across global time zones with a specific example of how you kept asynchronous work moving

HR and Compensation Discussion

The final stage is described as a discussion of HR policies and compensation details. There is little to study, but you can lose value by arriving without numbers or questions. Know your expected range from current data points for your level and location. Ask how the offer is structured and which level it is pegged to, so you can compare it fairly with other offers.

What it evaluates

• Whether you can state a compensation expectation with a reason behind it
• Whether you ask the questions needed to compare the offer: its components, the level, location and start date

How to prepare

• Gather two or three current compensation data points for the level and location before the call
• List the questions you need answered: base, bonus and equity split, level, start date, relocation or remote policy, and the deadline for your decision

Questions Cisco candidates report

Data structures and algorithms

One structure rarely covers the whole operation set, and the interesting questions in this category are the ones where it does not. When you need constant-time lookup and constant-time reordering at once, or the minimum plus deletion of an arbitrary element, the answer is two structures that index each other: a map from key to the node holding it, beside the list or heap that maintains the order. What separates a strong answer is the invariant between them, stated explicitly. Every operation has to leave both halves consistent, and the bug people ship is a removal from one that leaves a stale entry in the other.

• Solve the House Robber dynamic programming challenge to calculate maximum yields without selecting adjacent nodes.
• Implement a function to calculate the next term in a Look-and-say sequence given a numerical string input.
• Given a sorted array of integers, compress consecutive numbers into range strings (e.g., "a to b") while retaining distinct individual numbers.
• Expand a compressed string with nested parentheses and repetitions (e.g., converting (ab){3}(cd){2} to abababcdcd).

System design and architecture

The design is the data model and the interface; the boxes follow from them. Write the entities, the key each row is stored under, and then, for every read the product needs, the path from a key to the rows returned. Do the same for each write, including whatever else must change in the same operation. Most designs fail here rather than at scale, when a read the feature depends on turns out to need a scan or a fan-out across every partition. The strongest answers state the queries first and let the storage choice fall out of them.

• Design an object-oriented chessboard framework, defining piece classes, move validation rules, and initial state configurations.
• How would you design a high-throughput logging framework to calculate the exclusive execution time of nested functions across multiple threads?

Languages, concurrency and fundamentals

Many questions in this area arrive as a symptom: code that passes every test and fails weekly in production, memory that climbs until a restart, a handle that runs out. Treat the symptom as a reachability or a scheduling question. For a leak in a collected runtime, ask what is still reachable, because collectors free unreachable objects and nothing else, so a cache or a listener list that is never pruned is a leak by design. For intermittent wrongness, ask which schedule produces it. The separator is producing that schedule or that retained path concretely rather than restating the symptom as a suspicion.

• Write a C function to perform bitwise operations, such as setting, clearing, and toggling specific bit masks in hardware registers.
• Reverse a singly linked list in C using both iterative approaches and direct pointer manipulation without extra memory allocation.

Behavioural and engineering judgement

Every question in this category has a number in it somewhere, and engineers routinely tell the story without one. What the outage cost, what the delay cost, what the rewrite consumed in engineer-weeks against what it saved, and who absorbed it when it was not users: the on-call rotation, another team's quarter, the support queue. You will rarely have an exact figure, and an estimate with its method stated beats both a precise-sounding invention and silence. Say how you got to it and what it leaves out. That is the sentence that makes the follow-up about whether it was worth doing answerable at all.

• Walk through the most technically challenging project on your resume. What architectural decisions did you make, and why?

Other topics

Most prompts in this group are underspecified, and the honest answer is conditional. Find the variable that flips the decision, such as read-heavy against write-heavy or data that fits in memory against data that does not, name it, then answer for the case you picked. A weak answer states a preference as though it held everywhere. A strong one gives the rule and the point where the rule changes. Say the assumption out loud and commit to it: an assumption can be corrected by the person asking, while an answer hedged in every direction at once gives them nothing to correct.

• What are the primary differences between RADIUS and TACACS+ authentication protocols?

Practice exercises with worked solutions

The prompts above tell you what gets asked.

Migrate a live partitioned event table without blocking ingest

usage_event is range-partitioned daily on ingested_at, holds roughly 250M rows per day across 400 live partitions, and is written at 10-40k rows/second. Two changes are required: quantity must move from double precision to numeric(20,6), and a new environment column must become NOT NULL with a default of 'production'. Ingest cannot stop. Give the ordered plan, naming for each step the lock it takes, what that lock blocks, and roughly how long it is held. Identify the one step that cannot be rolled back cleanly once traffic depends on it.

How a strong candidate works it

• Classify the two changes before planning anything. Adding a column with a non-volatile default has been metadata-only since PostgreSQL 11, so it is cheap. Changing double precision to numeric is not binary-coercible, so alter column ... type rewrites every partition under ACCESS EXCLUSIVE and rebuilds its indexes; on this volume that is hours of blocked ingest and is simply not an option, which is why the plan is expand-and-contract rather than one statement.
• Expand: add quantity_numeric numeric(20,6) and environment with its default on the parent. Both are catalogue-only but both take a brief ACCESS EXCLUSIVE that cascades to partitions, so run each with lock_timeout set to a second or two and retry on failure. A queued ACCESS EXCLUSIVE request blocks every reader behind it, which is how a metadata-only change turns into an outage.
• Dual-write: deploy producer code that populates both columns on every insert, and leave it running before anything reads the new column. This is the step that cannot be reverted cleanly. Once readers depend on quantity_numeric, reverting the writer leaves rows with a null there, and the gap is only discoverable by re-reading the old column, which the readers have stopped doing.
• Backfill older partitions in batches keyed on the primary key, oldest first, committing every few thousand rows with a pause between batches, and skipping the partition still receiving writes until it rotates. Each batch is an ordinary UPDATE taking row locks only. The cost is bloat and WAL rather than blocking, so watch dead tuples and let autovacuum keep pace instead of wrapping 400 partitions in one transaction.
• Make NOT NULL cheap with the three-step form: add constraint ... check (environment is not null) not valid (brief ACCESS EXCLUSIVE, no scan), then validate constraint (SHARE UPDATE EXCLUSIVE, scans while reads and writes continue), then set not null, which from PostgreSQL 12 uses the validated check and skips its own full scan. Do this per partition, then on the parent.
• Switch and contract: move reads to the new column behind a flag, verify over a full period that both columns agree on freshly written rows, drop the old column (metadata-only), and only then remove the dual-write. Any index on the new column goes on with CREATE INDEX CONCURRENTLY per partition, since CIC is not supported on a partitioned parent: create the parent index with ONLY, build each child concurrently, then ALTER INDEX ... ATTACH PARTITION until the parent index becomes valid.

Follow-ups

• A CREATE INDEX CONCURRENTLY fails halfway through the partition list. What state is the table in, how do you detect it, and what do you run?
• The producer computes quantity itself. What happens to a request already in flight when the dual-write deploy lands, and does it matter?
• Give two queries that prove the backfill is complete: one cheap enough to run every minute, one authoritative.

Model credential revocation so history survives the delete

tenant_api_key stores key_id, tenant_id, workspace_id, name, key_prefix, secret_hash, scopes text[], status (active, revoked, expired, compromised), auth_version, created_at, expires_at, last_used_at, revoked_at, revoked_reason. Rotation inserts a new row and revocation never deletes, because an incident review asks which credential served a request last quarter. Write the constraints that enforce: a label is unique only among a tenant's live keys, revoked_at and status can never disagree, and scopes is never empty. Then write the authentication lookup predicate, and name one column in this table that must stay out of it.

How a strong candidate works it

• Reach for a partial unique index rather than a plain UNIQUE: create unique index on tenant_api_key (tenant_id, name) where revoked_at is null. Any number of revoked rows may share a label, the live namespace stays unique per tenant, and the revoked majority is not in the index at all, so it stays small on a table that only grows.
• Tie the nullable timestamp to the enum so the two cannot drift: check ((revoked_at is not null) = (status in ('revoked','compromised'))) and check ((revoked_at is null) = (revoked_reason is null)). A revocation that records no reason is the one an incident review cannot use.
• Write the emptiness check as check (cardinality(scopes) > 0), not array_length(scopes, 1) > 0. array_length returns NULL for an empty array, a CHECK constraint passes when its expression is NULL, so the array_length version accepts exactly the value it was written to reject.
• Make the lookup a single index probe with every liveness condition inside it: where secret_hash = $1 and revoked_at is null and (expires_at is null or expires_at > now()) and auth_version = $2, backed by a unique index on secret_hash. Nothing is filtered in application code, so there is no path that forgets a clause.
• Keep last_used_at out of that predicate. It is written asynchronously and is allowed to lag by a minute, so it is a usage signal; feeding it into an authorisation decision makes the decision depend on a write that may be late, batched away or lost.
• Flag the modelling smell while you are here: expired is derivable from expires_at < now(), so storing it as a status obliges a job to keep it true and guarantees the column is wrong between the expiry instant and that job's next run. Derive it in the predicate; keep the stored status for states that are decisions rather than clock readings.

Expected result (20 min): A partial unique index on (tenant_id, name) where revoked_at is null; check ((revoked_at is not null) = (status in ('revoked','compromised'))); check ((revoked_at is null) = (revoked_reason is null)); check (cardinality(scopes) > 0); a single-probe lookup on secret_hash plus revoked_at, expires_at and auth_version; last_used_at excluded, with a note that 'expired' should be derived rather than stored.

Check yourself

• Two revoked keys with the same name insert cleanly; a second live one does not.
• The array_length form of the emptiness check accepts an empty array and the cardinality form rejects it.
• No statement anywhere in the design deletes or updates a revoked row.
• Revoking a key touches exactly one row and takes effect on the next lookup with no application-side filtering.

Follow-ups

• Rotation issues a replacement while the old key stays live for a 30-day overlap. What does the uniqueness rule become, and what does the UI show to tell two same-named keys apart?
• A password reset bumps the principal's auth_version. No row in this table changed. How does the next request fail, and what query counts how many keys that bump just killed?
• A key turns up in a public repository. Which columns let you find it, and what do you write to the row?

Schedule ordered webhook retries with a heap of subscription queues

Design the in-memory scheduler for webhook delivery. Up to 20 million rows sit in status pending or failed_retryable across 200,000 subscriptions, each row carrying next_attempt_at and attempt_count, and each endpoint having a circuit breaker. Deliveries for one subscription must be attempted in order, so at most one attempt per subscription may be in flight. Support due(now), complete(delivery, outcome) and insert(delivery) in O(log S), where S is the subscription count rather than the delivery count. Give the backoff formula you schedule retries with.

How a strong candidate works it

• Key the global heap by subscription, not by delivery. Each subscription owns a FIFO of its due deliveries in event order; the heap holds one entry per eligible subscription, keyed by its head's next_attempt_at. That is 200,000 heap entries instead of 20 million, and it makes the one-in-flight rule structural rather than a check somebody can forget.
• due(now): peek the minimum. If its key is in the future, sleep until then instead of spinning. Otherwise pop it, move the subscription into an in-flight set, and do not re-push it. A subscription absent from the heap cannot be dispatched twice, which is precisely how ordering is preserved.
• complete: on success, drop the head and re-push the subscription keyed by its new head, or leave it out when the queue empties. On a retryable failure, increment attempt_count and set next_attempt_at = now + uniform(0, min(cap, base * 2^attempt)), sampled uniformly across the whole interval. That is full jitter; deterministic backoff re-synchronises the herd you just created.
• Circuit breaker: park the subscription in a second heap keyed by its half-open time, so an endpoint dead for six hours costs one heap entry and zero attempts rather than consuming worker slots. Admit exactly one probe at half-open and close the breaker only on its success.
• Say the price of the ordering guarantee out loud. One in-flight attempt per subscription means an endpoint answering in 10 seconds drains at 0.1 deliveries/second however many workers you run, and its backlog grows until it recovers. If the customer does not need order, allow k in flight and document delivery as unordered; that is the trade, and it is a product decision.
• All three operations are O(log S) with O(S) resident heap memory and the queues themselves backed by the store. The database-backed equivalent is a partial index on (subscription_id, next_attempt_at) where status in ('pending','failed_retryable') claimed with FOR UPDATE SKIP LOCKED, and the write-back must be fenced on lease_token so a worker that stalled and resumed cannot overwrite a newer attempt.

Expected result (30 min): Heap size stays at or below 200,000 regardless of the 20 million deliveries. The fast endpoint's throughput is unaffected by the dead one once the breaker trips. The dead endpoint's deliveries accumulate in their own deque and cost exactly one heap entry.

Check yourself

• The asserted invariant never fires under concurrent workers.
• Replaying the same delivery set twice produces identical per-subscription ordering, even though the interleaving across subscriptions differs.
• Replacing full jitter with fixed backoff makes retry attempts cluster visibly in a histogram of attempt timestamps.

Follow-ups

• One subscription has 4 million queued deliveries. What stops it from starving the other 199,999, and what does your heap look like under that load?
• A customer requests redelivery of last Tuesday's events. Where do those rows enter your structure, and what keeps them from reordering live traffic?
• The process restarts. How much state do you rebuild, and what stops every subscription from being attempted in the same second?

Build a resumable usage export the customer can reconcile against

Customers reconcile invoices against usage_event (event_id uuid, tenant_id, workspace_id, environment, sku, quantity numeric(20,6), idempotency_key, occurred_at, ingested_at, source_service, request_id), partitioned daily on ingested_at. The current export is ?page=N&per_page=1000 ordered by occurred_at, and a customer syncing hourly reports rows that never appear in their export but do appear on their invoice. Design the replacement: the ordering, the cursor's contents, the index it requires, and the rule deciding where a page stops. State what the client does on a timeout and on a cursor older than retention.

How a strong candidate works it

• Separate the two defects in the current shape. Offset makes the database produce and discard N * per_page rows, so page cost grows linearly and a deep page degrades from milliseconds to seconds. Concurrent inserts also shift the window between requests, so a walker skips rows with no error raised anywhere, which for a customer sync is silent data loss.
• Order by ingestion, not by occurrence. During a replay events arrive hours out of occurred_at order, so a consumer holding an occurred_at high-water mark can never see a late event that falls below it; (ingested_at, event_id) is the only ordering under which 'everything after my cursor' is a complete statement.
• Page with a row comparison: where tenant_id = $1 and (ingested_at, event_id) > ($2, $3) order by ingested_at, event_id limit $4, backed by an index on (tenant_id, ingested_at, event_id). That seeks directly to the resume point, so every page costs the same regardless of depth.
• Trail the head of the table. With ingested_at defaulting to now(), which is transaction start time, a long insert transaction receives an earlier timestamp and becomes visible after a reader has already passed it. Cap each page at ingested_at <= now() - delta, with delta larger than the longest write transaction as bounded by statement_timeout and idle_in_transaction_session_timeout, or the export skips exactly the rows written under load.
• Make the cursor opaque and self-describing: base64 of the timestamp, the event id and a fingerprint of the filters, rejected when the filters differ from the current request. Return 410 with a cursor_expired code once the cursor's partition has been dropped, so the client restarts from a known time instead of resuming into a hole.
• Keep a page a pure GET with no server-side consumption, so a timeout is resolved by retrying the identical cursor.

Expected result (30 min): Keyset pagination over (ingested_at, event_id) with an index on (tenant_id, ingested_at, event_id), a trailing head predicate sized above the longest write transaction, an opaque filter-bound cursor, and 410 for a cursor past retention.

Check yourself

• A late event with an old occurred_at is still delivered by the export.
• Page cost is independent of how many pages have already been read.
• The cursor persists across a client restart and survives retrying the same page.
• The tie-break column is unique, so no row can be skipped or repeated at a page boundary.

Follow-ups

• The customer asks for a total count alongside the first page. What do you offer instead, and why is an exact count both expensive here and wrong by the time it is read?
• How would you let a customer re-read a window they have already consumed without giving up the forward-only cursor?

Invoice detail latency triples after an ORM relationship refactor

An invoice detail endpoint returned in 40 ms at p99 last week. After a refactor replaced a hand-written join with ORM relationship access it returns in 1.4 s, and the regression grows with the number of invoice_line_item rows on the invoice. Database CPU rose, but no statement in the slow-query log exceeds 3 ms. You have request traces with per-span SQL, the ORM statement log, and a staging copy of the data. Produce an ordered diagnostic checklist, the measurement that confirms the cause before any code change, and the fix.

How a strong candidate works it

• Count statements per request before reading any statement duration. A slow-query log hides this class by construction, because every individual query is fast and only their number is wrong; take one trace and count SQL spans.
• Establish proportionality rather than asserting it: sample invoices with 5, 20, 60 and 200 line items and plot statements per request against line count. A straight line of slope 1 through an intercept of one or two identifies a lazy relationship load, and no index or cache would move that line.
• Locate the emitting attribute access in the refactored code and check whether the same shape repeats one level deeper, for instance a tax or adjustment collection hanging off each line, which turns the cost quadratic.
• Fix with a bounded statement count: either one join that fetches invoice and lines together, or two statements where the second is WHERE invoice_id = $1 AND tenant_id = $2. Keep tenant_id in the predicate so the read stays tenant-scoped even though invoice_id already implies it.
• Choose between the two deliberately: the join duplicates the wide parent row across N children on the wire, the two-statement form avoids that for one extra round trip. Prefer the join for narrow parents and the split for wide ones.
• Pin it with a per-request statement-count assertion in a test that varies line count, because a latency assertion passes on a small fixture and would not have caught this.

Follow-ups

• The endpoint now also needs per-line tax rows. Show the shape that keeps statement count constant instead of reintroducing the same defect one level down.
• How does this change if a transaction-pooling proxy sits between the service and the database, so each statement may land on a different backend session?
• The same page paginates invoices with LIMIT and OFFSET. Why is that a second, independent defect, and what replaces it?

Estimate a tenant-leading index migration you have never run

Someone needs a date. usage_event carries an index on (occurred_at) and needs (tenant_id, occurred_at); the largest tenant holds roughly a hundred times the median tenant's rows, the table is partitioned daily with years of retention, and you have never run a migration on a table this large. Give an estimate you would defend: how you decompose the work, the two or three numbers you would go and measure first, the range and confidence you state, and what you commit to when the person asking needs a single date today.

How a strong candidate works it

• Refuse the bare number and then give one anyway, in the form that is actually useful: a range plus the measurement that collapses it. 'Four to eleven days; one afternoon building this index on a restored copy of the largest partition takes that to within a day' is an answer, while 'it depends' is not.
• Decompose by failure mode rather than into equal chunks, because that is where estimates go wrong. On a partitioned parent you create the index ON ONLY the parent, build each partition's index with CREATE INDEX CONCURRENTLY, then ALTER INDEX ... ATTACH PARTITION, at which point the parent index becomes valid. CONCURRENTLY does not block writes but scans each partition twice, waits out older transactions, cannot run inside a transaction block, and on failure leaves an invalid index you must drop concurrently and retry.
• Name the two unknowns that dominate and price them: build time on one restored partition of realistic size, and whether the planner actually chooses the new index for the skewed tenant, since selectivity for a tenant holding most of the rows is a different question from selectivity for the median tenant. Both are half-day measurements against a replica, and both are cheaper than being wrong by a week.
• State the assumptions the range is conditional on, because that is what makes a slip a re-estimate instead of a credibility event: no partition above a stated row count, one concurrent build at a time so it does not compete with ingest for I/O, and an ingest backlog that can absorb the added write amplification while both indexes exist.
• Budget the step nobody budgets: verification and the old index's removal. Dropping the old index is fast, but deciding it is safe to drop means confirming no plan still uses it, and that confirmation waits on real traffic across a full weekly cycle rather than on your patience.
• Answer the single-date request honestly. Commit to a date for the first checkpoint — the measured build number from the replica — and to re-estimating on that date, and say plainly what you are not committing to yet. A date with a scheduled re-estimate is worth more to the asker than a confident wrong one, and you should say why in those words.

Follow-ups

• The concurrent build fails half way through the largest partition. What is the state of the database and what do you do next?
• Your estimate slips by sixty percent. Which assumption broke, and at what point would you have known?
• The person asking needs the date for a customer commitment. Does your answer change?

Unblock an engineer on a job run that finished twice

An engineer two weeks into the team brings you a job_run row showing status succeeded with an exit_code written by a worker declared dead ten minutes earlier; the retry attempt also shows succeeded. They have spent a day adding logging and are no closer. You have twenty minutes and you do not want to take the keyboard. Describe how you unblock someone: the question you ask first, what you let them find themselves, the concept you name and when, and how you check the next day that they own the fix rather than having watched you produce it.

How a strong candidate works it

• Ask what they expect rather than what they see: which statement set status to succeeded, and what did it check before writing? That question points directly at the update's WHERE clause, which is where the answer lives, and it costs them nothing to answer, so it does not read as a test.
• Let them build the timeline themselves from the row: queued_at, started_at, leased_until, finished_at and worker_id, on both the original run and the retry. Two different worker_ids with a lease expiry between them tells the whole story, and they will see it before you say it.
• Name the concept once the evidence has earned it. A lease bounds time; it does not prevent a write. The store has to reject a stale writer, which means the update carries a fencing token the row compares — update job_run set status = 'succeeded' where run_id = $1 and lease_token = $2 and status = 'running' — and a long garbage-collection pause or a brief partition is enough to produce what they are looking at.
• Point at the second, less obvious half and let them decide it: 'lost' exists in the status enum precisely so a run whose worker vanished is not recorded as failed, because failed asserts an outcome nobody observed and the system then bills and retries on that assertion. Ask them what these two rows should have said.
• Leave them with the next step rather than the patch — a test that kills the first worker after the sandbox exits and before the row is written — and say when you are available again, so the offer is real rather than polite.
• Check ownership the next day by what they produced, not by asking if it went well: a test that reproduces the window proves they understood it; a test that only asserts the new WHERE clause proves they copied it. Ask them to explain it to a third person and listen for whether the explanation is theirs.

Follow-ups

• They propose a longer lease instead of a token. What do you say, and what breaks when legitimate runs last thirty minutes?
• How can you tell whether your explanation landed or they simply deferred to you?
• The same engineer hits a variant of this next month. What did you fail to teach the first time?

Where candidates lose points

Preparing only coding for the online assessment and dropping the networking, database and OS multiple-choice questions

The assessment is described as mixing algorithmic coding with multiple-choice questions on networking, databases and operating systems, and coding practice does not transfer to those. Build a recall sheet covering OSI and TCP/IP layers, ARP, DNS, DHCP, TCP versus UDP, SQL joins, keys and indexes, processes versus threads, paging and deadlock. Quiz yourself until you can explain each item in a sentence rather than just recognise the term.

Being unable to write C with pointers and bit masks because you only prepared in Python or Java

Reported systems questions ask you to reverse a singly linked list in C without extra allocation, and to set, clear and toggle bits in a register. Spend a day in C even if your target team uses a higher-level language. Practise pointer updates in the reversal loop and the masks x |= (1u << n), x &= ~(1u << n) and x ^= (1u << n). Know stack versus heap allocation and static versus dynamic linking. Test an empty list, one node and the top bit, because that is where most of the bugs are.

Stopping at 'I don't know' on a networking or OS question instead of reasoning from principles

Networking fundamentals are described as covered for almost all teams, and reported questions range from the packet flow behind a browser request to VLANs, stateful firewalls and RADIUS versus TACACS+. When a question goes past what you know, say how you would find out: which layer is involved, what a packet capture would show, and which protocol you expect at each hop. A structured troubleshooting answer gives the interviewer something to work with. Silence gives them nothing.

Listing a technique or project you cannot explain or code live when the techno-managerial or technical rounds dig into it

The techno-managerial round is described as centred on your projects, and candidates report deep questions on what their resume lists. If you list BFS/DFS, dynamic memory management or a framework, be ready to write or explain it on the spot. Go through your resume line by line. For each claim, either prepare the decision, the alternative and the measurement behind it, or reword it to the part you actually owned.

Answering the object-oriented design question with a list of class names and no rules or behaviour

For a prompt like the chessboard framework, naming the classes is the easy part. Show where move validation lives and how each piece's movement rules are expressed without a switch over piece types. Show how board state and turn order are held and how initial setup is configured. Then add one awkward rule, such as castling or pawn promotion, and show which classes change. For the router-monitoring or logging design prompts, state the load and the failure you are designing for before choosing components.

Breadth then depth, for a generalist facing a mixed loop

Four days sample coding, design, fundamentals and the practical rounds at deliberately shallow depth, which is enough to surface the topics you did not know were in scope. That map, rather than a guess made on day one, decides where the last three days go.

Day 1 — Timed string and array coding

• Solve three reported problems under a timer you set before starting: compress a sorted array into range strings, produce the next look-and-say term, and count distinct pairs summing to K.
• Before submitting each one, write tests for empty input, a single element, a run ending at the last index and duplicate values, and print expected against actual.
• Add the matrix row-max and column-min scan, and state its time and space complexity before coding it.

Deliverable: Four passing solutions, each with its edge-case tests and a one-line complexity statement.

Day 2 — Data structures and algorithms in depth

• Solve House Robber first as plain recursion, then with memoisation, then with two rolling variables, and explain why each version stays correct.
• Expand strings like (ab){3}(cd){2} using a stack, then test nested input such as ((a){2}b){2}, which should give aabaab.
• Implement BFS and DFS on the same graph, recursively and iteratively, and confirm both reach the same set of nodes.
• Implement an LFU cache with O(1) get and put using a key map, frequency buckets that keep recency order, and a minimum-frequency pointer. Explain how you break ties when two keys share the lowest frequency.

Deliverable: Working House Robber, string expansion, BFS/DFS and LFU implementations, each with its complexity stated.

Day 3 — Computer networks and security

• Explain aloud the full flow when a browser requests google.com: DHCP lease, DNS resolution, ARP for the gateway, TCP handshake, TLS, the HTTP request, routing and the return path.
• Write one paragraph each on ARP, DNS and DHCP, on VLANs and inter-VLAN routing, and on stateful versus stateless firewalls.
• Compare RADIUS and TACACS+ on transport protocol, how much of each packet is encrypted, and whether authentication, authorisation and accounting are separated.
• Review the bank topics on Spanning Tree Protocol, OSPF, and port-channel versus vPC, VSS and stacking. Write down the one mechanism you would explain for each.

Deliverable: A packet-flow walkthrough you can deliver without notes, and a one-page networking recall sheet for the multiple-choice section.

Day 4 — Systems programming, C and operating systems

• In C, starting from a blank file, reverse a singly linked list iteratively in place and recursively, then test empty, one-node and two-node lists.
• Write set, clear, toggle and test-bit functions for a 32-bit register using unsigned masks, and test bit 0 and bit 31.
• Explain heap versus stack layout, what happens on a context switch, how a signal handler runs, and static versus dynamic linking.
• Review memory fragmentation and C pointer and array declarations from the bank topics, for example int *a[10] (an array of ten pointers) versus int (*a)[10] (a pointer to an array of ten ints).

Deliverable: Tested C implementations of list reversal and bit operations, plus a one-page OS and memory summary.

Day 5 — Object-oriented and system design

• Design the chessboard framework: piece hierarchy, board, move validation, turn order and initial setup. Then add castling and note which classes change.
• Sketch the router status-monitoring service: how nodes report metrics, how an offline node is detected from missed heartbeats, where state is aggregated, and how alerts are raised.
• Outline the logging framework for the exclusive execution time of nested functions across threads: a call stack per thread, subtracting child time from the parent, and collecting logs without every thread contending on one lock.
• For each design, state the load and the failure mode before choosing components. Use the worked design exercise on this page to practise making ordering and index choices explicit.

Deliverable: Three designs, each with scope, components, data model and one named failure mode handled.

Day 6 — Techno-managerial round and behavioral stories

• For every project on your resume, write the problem, your role, one architectural decision with the alternative you rejected, and what you measured.
• Prepare four to six STAR stories: a technical disagreement, delivery under shifting requirements, a failure, an initiative, and collaboration across time zones.
• Have someone ask 'why' three times about your strongest project, and note where your answer runs out.
• Prepare answers to the bank prompts on your motivation for the role and on how you use AI tools at work.

Deliverable: One project sheet per resume entry and four to six STAR stories, each ending in a stated result.

Day 7 — Recruiter screen, HR prep and a full mock

• Run a back-to-back mock over a video call with screen sharing: one reported coding problem, one networking walkthrough and one project deep dive, narrating throughout.
• Write your recruiter-screen notes: a short background summary, the type of team you prefer, and constraints such as start date and location.
• Prepare for the HR and compensation discussion: two or three current compensation data points for your level and location, and your questions on offer components, level and start date.
• Re-attempt the weakest item from days 1-5 and compare the result with your first attempt.

Deliverable: Mock notes, a one-page recruiter and HR sheet, and one weak item re-attempted with a before-and-after comparison.