Software Engineer roles at Cisco cover two quite different kinds of work. Platform and infrastructure teams write C and C++ for enterprise routers, switches and custom silicon: platform software, driver wrappers, bit manipulation routines and memory-conscious data paths. Cloud and application teams, including Meraki, Duo and Webex, build back-end services and APIs in Java, Python or Go and web front ends in TypeScript and React. Security and analytics work, such as Umbrella and Talos, centres on threat intelligence tools, firewall management interfaces and packet analysis pipelines.
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.
Online Assessment
reportedCandidates 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 to demonstrate
- 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
reportedCandidates 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 to demonstrate
- 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
reportedCandidates 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 to demonstrate
- 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
reportedCandidates 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 to demonstrate
- 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
reportedThe 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 to demonstrate
- 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
8 candidate reports. Individual accounts describe a particular role and hiring cycle.
Cisco Software Engineer Interview Experience — HR Screen, Then a River-Crossing Brainteaser Instead of Coding
I applied for an SDE role on the Switch team. The first round was over Wedex, 30 minutes, with a female HR person. She asked things like where I live and where I'm eligible to work — that kind of question, nothing about my past experience. At the end I asked her how to prepare for the next round. She said this one would be switch-related, so I should probably brush up on some switching fundamenta…
Read full experienceCisco Software Engineer interview experience
The technical questions leaned toward systems thinking and networking fundamentals. I was asked about stack and heap basics, what causes segmentation faults, and how I would approach debugging a stack overflow. Networking came up too, including wireless concepts and the differences between OFDMA and OFDM. The conversation stayed informal. Even when the topics got detailed, I was encouraged to exp…
Read full experienceCisco Software Engineer interview: fair questions and disputed cheating concern
I entered the interviews confident because the questions matched my strengths: backend concepts, Java, system design, and coding. The interaction felt positive, and I believed I answered clearly. After the rejection, I spoke with HR to understand what happened. I learned that the interviewer thought I was looking at answers during the interview. That surprised me because I was not using anything…
Read full experienceCisco Software Engineer interview: assessment followed by weeks of silence
My process began with a Hackerrank-style exam. It included several easy-to-medium LeetCode-style problems and a simple SQL question, so it felt manageable compared with harder online assessments I had heard about. After I finished, I heard nothing for weeks. The silence eventually ended without further progress, so the outcome felt less like the result of an interview conversation and more like a…
Read full experienceCisco Software Engineer interview: networking OA cutoff
The process began with an online assessment, and the later interview path depended on that result. For me, the OA was the gate. I solved some questions, but my overall performance was not strong enough to continue. There was no detailed technical follow-up afterward, only the sense that the feedback did not support moving forward. The assessment covered networking and C fundamentals: subnetting,…
Read full experiencePracHub editorial advice for the preparation topics above.
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.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Solve the House Robber dynamic programming challenge to calculate maxi…
Solve the House Robber dynamic programming challenge to calculate maximum yields without selecting adjacent nodes.
Approach
- State the target complexity and say which constraint rules the naive version out.
- Choose the data structure from the access pattern, not from familiarity.
- Restate the input: its shape, its size, and what is guaranteed about it.
Follow-up
- What is the worst case, and how likely is it on real data?
- Which test case would catch an off-by-one here?
Implement a function to calculate the next term in a Look-and-say sequ…
Implement a function to calculate the next term in a Look-and-say sequence given a numerical string input.
Approach
- Walk one small example through your approach before writing the whole thing.
- Name the brute-force solution and its complexity before improving on it.
- Restate the input: its shape, its size, and what is guaranteed about it.
Follow-up
- Which test case would catch an off-by-one here?
- What is the worst case, and how likely is it on real data?
Given a sorted array of integers, compress consecutive numbers into ra…
Given a sorted array of integers, compress consecutive numbers into range strings (e.g., "a to b") while retaining distinct individual numbers.
Approach
- Choose the data structure from the access pattern, not from familiarity.
- State the target complexity and say which constraint rules the naive version out.
- Restate the input: its shape, its size, and what is guaranteed about it.
Follow-up
- How does this change if the input no longer fits in memory?
- What is the worst case, and how likely is it on real data?
Expand a compressed string with nested parentheses and repetitions (e.…
Expand a compressed string with nested parentheses and repetitions (e.g., converting (ab){3}(cd){2} to abababcdcd).
Approach
- State the target complexity and say which constraint rules the naive version out.
- Restate the input: its shape, its size, and what is guaranteed about it.
- Walk one small example through your approach before writing the whole thing.
Follow-up
- Which test case would catch an off-by-one here?
- What is the worst case, and how likely is it on real data?
Write a C function to perform bitwise operations, such as setting, cle…
Write a C function to perform bitwise operations, such as setting, clearing, and toggling specific bit masks in hardware registers.
Approach
- Say what the runtime actually does before reasoning about the code.
- Reach for the cheapest primitive that closes the race, not the broadest lock.
- Identify the window where an invariant is briefly untrue.
Follow-up
- What happens if two callers reach this at the same time?
- Where could this allocate more than you expect?
Reverse a singly linked list in C using both iterative approaches and …
Reverse a singly linked list in C using both iterative approaches and direct pointer manipulation without extra memory allocation.
Approach
- Say what the runtime actually does before reasoning about the code.
- Distinguish a value from a reference to it, and say which one you handed out.
- Identify the window where an invariant is briefly untrue.
Follow-up
- What happens if two callers reach this at the same time?
- How would you prove the race exists rather than suspect it?
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.
Approach
- 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, incrementattempt_countand setnext_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 withFOR UPDATE SKIP LOCKED, and the write-back must be fenced onlease_tokenso a worker that stalled and resumed cannot overwrite a newer attempt.
Worked solution 30 min
- Define the four structures explicitly:
queues: subscription_id -> deque[delivery],ready: min-heap of (next_attempt_at, subscription_id),inflight: set[subscription_id],breaker: min-heap of (half_open_at, subscription_id). - Write down the invariant you will assert after every operation: a subscription appears in at most one of
ready,inflightandbreaker, never in two. - Implement
due,completeandinsert, then simulate 200,000 subscriptions with Zipf-distributed queue depths totalling 20 million deliveries. - Add one endpoint that always times out after 10 seconds and one that always answers in 20 ms, then measure the fast endpoint's throughput with and without the per-endpoint breaker.
- Instrument heap size across the run.
Follow-up
- 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?
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.
Approach
- 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 ... typerewrites 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)andenvironmentwith its default on the parent. Both are catalogue-only but both take a brief ACCESS EXCLUSIVE that cascades to partitions, so run each withlock_timeoutset 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), thenvalidate constraint(SHARE UPDATE EXCLUSIVE, scans while reads and writes continue), thenset 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-up
- 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.
Approach
- 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')))andcheck ((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), notarray_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:
expiredis derivable fromexpires_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.
Worked solution 20 min
- Create the table with all three constraints on a scratch database and insert two revoked rows sharing (tenant_id, name); the partial index should accept both.
- Insert a second live row with that same name and confirm the violation names the partial index.
- Run
update tenant_api_key set revoked_at = now()leaving status = 'active' and confirm the CHECK rejects it; then tryinsert ... scopes = '{}'against both the cardinality and the array_length forms and note that only one rejects it. - Run
explain (analyze, buffers)on the lookup predicate for a live key and confirm an index scan on secret_hash with rows removed by filter equal to zero.
Follow-up
- 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?
Design an object-oriented chessboard framework, defining piece classes…
Design an object-oriented chessboard framework, defining piece classes, move validation rules, and initial state configurations.
Approach
- Name the read and write paths separately; they rarely have the same bottleneck.
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Choose a partition key and say what query it makes expensive.
Follow-up
- How does this behave when that dependency is down for an hour?
- What would you drop to keep the system up under load?
How would you design a high-throughput logging framework to calculate …
How would you design a high-throughput logging framework to calculate the exclusive execution time of nested functions across multiple threads?
Approach
- Name the read and write paths separately; they rarely have the same bottleneck.
- Choose a partition key and say what query it makes expensive.
- Fix the scope first: who calls this, how often, and what they do when it fails.
Follow-up
- How does this behave when that dependency is down for an hour?
- What breaks first when traffic grows ten times?
What are the primary differences between RADIUS and TACACS+ authentica…
What are the primary differences between RADIUS and TACACS+ authentication protocols?
Approach
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
- State your assumptions explicitly before working the problem.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
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.
Approach
- 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_expiredcode 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.
Worked solution 30 min
- Construct the failing case on paper: an event with occurred_at at 09:00 ingested at 14:00, and a consumer that read up to 10:00 at 11:00.
- Write the keyset query with the row comparison and the exact index it needs, then say which column of the index each predicate uses.
- Add the trailing-head predicate and pick delta from a named timeout setting rather than a round number.
- Define the cursor's encoded contents and the two error cases: filter mismatch and expired partition, with their status codes.
- Write the client's algorithm in four lines: request, persist cursor after processing the page, retry the same cursor on timeout, restart from a time on 410.
Follow-up
- 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.
Approach
- 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-up
- 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?
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.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Timed 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Data 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Computer 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Systems 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.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Object-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.
Practice prompt ↗Practice prompt ↗06Techno-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.
Practice prompt ↗Practice prompt ↗07Recruiter 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.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Reported behavioral questions for this role centre on your own projects and how you work with others: your hardest resume project, a technical disagreement, delivering under shifting requirements, and collaborating across time zones. Structure answers with STAR, but spend most of the time on the Action you personally took and a Result backed by a number or a concrete outcome. Prepare four to six stories, and check that each one holds up when you are asked why you made the decision it describes.
Walk through the most technically challenging project on your resume. …
Walk through the most technically challenging project on your resume. What architectural decisions did you make, and why?
Approach
- Pick a story where you made the decision, not one where you watched it.
- Give the blast radius: what could have broken, and what you measured.
- State the situation in two sentences and spend the rest on the reasoning.
Follow-up
- What did you decide not to do, and why?
- How did you know your change caused the improvement?
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.
Approach
- 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-up
- 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.
Approach
- 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-up
- 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?
- 01
Walk through the most technically challenging project on your resume. What architectural decisions did you make, and why?
- 02
Describe a situation where you had a technical disagreement with a teammate or lead. How did you resolve it?
- 03
Tell me about a time you had to deliver a critical module under shifting project requirements or tight deadlines.
- 04
How do you manage asynchronous workflows and clear communication when collaborating across different global time zones?
- 05
What draws you to this role, and how does your past experience connect to it?
- 06
How do you use AI tools in your engineering work, and how do you keep the output correct?
Is this an official Cisco interview guide?
No. It is PracHub's own research and practice material for the Software Engineer role at Cisco. Rounds and questions reflect what candidates have reported, not a process Cisco has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗What is on the Cisco Software Engineer online assessment?
Candidates describe algorithmic coding problems plus multiple-choice questions on computer networking, databases and operating systems. The assessment is hosted on a platform such as HackerRank or run through hiring events such as Code with Cisco. Prepare both halves: timed string, array and graph problems for the coding part, and a recall sheet of networking, SQL and OS fundamentals for the multiple-choice part.
PracHub Software Engineer practice ↗Do I need a CCNA certification to pass the interview for a Software Engineer role?
No. The material behind this guide states that a CCNA is not required for software engineering roles unless the job description says so. Networking fundamentals such as TCP/IP, subnetting, ARP, DNS, DHCP and VLANs are listed as topics to review, and reported questions cover ARP, DNS, DHCP and VLANs. CCNA-level understanding of those topics is worth having even without the certificate.
PracHub interview research ↗I work in Python or Java. Should I still review C?
Yes, for at least a day. Reported systems questions include reversing a linked list in C with pointer manipulation, bit manipulation on register masks, heap versus stack memory, and static versus dynamic linking. This material is reported to come up more on teams close to hardware. Ask your recruiter which team you are interviewing for and which languages you can use in the coding rounds.
PracHub Software Engineer practice ↗What mistakes should I avoid in Cisco technical interviews?
The material behind this guide names two: not explaining your reasoning out loud, and overstating your role in resume projects. Candidates report detailed follow-up on resume projects, so be ready to explain every technical choice and any code you claim as yours. While coding, state your plan and its complexity before you write, and test edge cases aloud.
PracHub interview research ↗Should I use the STAR method for Cisco behavioral questions?
Yes. It is the recommended structure for this role's behavioral and project questions. Keep Situation and Task short, spend most of the answer on the Action you personally took, and end with a Result stated as a number or a concrete outcome. Four to six prepared stories (technical conflict, tight deadline, a failure, an initiative) cover most of the reported prompts.
PracHub interview research ↗How long does the Cisco Software Engineer process take?
Candidates report five stages over roughly four to six weeks from application to offer. It varies by team, business unit and location, and university or large off-campus hiring drives can take longer. Ask your recruiter for the expected timeline, and raise any competing deadline early.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-24 - 02PracHub Software Engineer practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-24 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-24
Explore related engineering environments and compare the preparation focus.
L3Harris Technologies Software Engineer Interview Questions & Guide 2026
Systems practice for L3Harris Technologies software engineer candidates, weighted toward B2B software and infrastructure work: the load that actually arrives, the failure modes that matter there, and the invariants a partial outage must not
BairesDev Software Engineer Interview Questions & Guide 2026
Design practice for BairesDev software engineer prep that pushes past topology: turn a loose requirement into a schema and an API contract, then work out the read and write paths it implies.
IBM Software Engineer Interview Guide
Failure-handling practice for IBM software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
Adobe Software Engineer Interview Guide
Database practice for Adobe candidates: how an index changes a query plan, and which anomalies survive a given isolation level, since read committed still permits non-repeatable reads.