Interview guides · Aequor Healthcare Services

Aequor Healthcare Services Software Engineer Interview Guide

Aequor Healthcare Services Software Engineer interview guide: three reported rounds, networking and C questions, behavioral prep and a 7-day plan.

The 60-second brief

Aequor Healthcare Services is described by candidates as a healthcare staffing business, and the Software Engineer role is placed in the software behind it: tools for staffing, clinical workforce management and day-to-day healthcare operations, where facilities look for talent and professionals look for work. Candidates describe two kinds of work, improving existing internal platforms and building new features. The reported responsibilities are writing and maintaining the software, taking part in design, requirement gathering, deployment and post-release troubleshooting, reviewing code, resolving production issues, and explaining technical limits and progress to colleagues who are not engineers. Candidates also say the role works alongside product managers and other engineering teams to turn business requirements into technical specifications.

This guide is for candidates applying for the Software Engineer role at Aequor Healthcare Services. It covers the three reported stages (Screening Phase, Technical Rounds, Manager and HR Discussions) and the fifteen questions candidates report, grouped as networking and technical fundamentals, aptitude and judgement, and behavioral and managerial. It also covers the C and C++ topics that candidates list for the technical stage. It is not a guide to a particular team, and it does not assume healthcare experience: candidates describe that as a nice-to-have, while C or C++, networking, logic problems and clear communication are listed as the must-haves.

Candidates report three stages over roughly 3-5 weeks: a Screening Phase held by phone or as a written test, Technical Rounds on coding and networking, and Manager and HR Discussions on experience and long-term fit. A status update is reported to follow about two weeks after the last round.

Focus areas

Networking Fundamentals
Technical Round
Core Networking Knowledge

Overview

The work candidates describe is ordinary product engineering in a healthcare staffing setting: build and maintain platforms, review each other's code, and chase down problems that appear in production. The skills they say the role requires lean low-level. C, C++ or a similar language, plus a working grasp of networking protocols, are the first items on the must-have list, followed by logic and aptitude problems and strong written and spoken communication. Distributed systems, cloud architecture and automated testing frameworks are listed as extras, so they are worth a short pass but not the core of your preparation.

The fifteen reported questions fall into three groups of five. The technical group asks you to explain network architecture, handle connectivity problems in a distributed system, compare TCP and UDP, debug a complex C-based application and protect data integrity during transmission. The aptitude group is mixed: one question is a set of sequencing and pattern puzzles, while the others ask how you would work with limited information under a deadline, use quantitative data in coding decisions, explain a technical concept to a non-technical stakeholder and prioritize several simultaneous bugs. The last group is behavioral and managerial: a significant challenge, your ideal working environment, handling feedback, long-term goals and leading or influencing a project.

Preparation therefore splits in two. For the technical half, rebuild the fundamentals until you can explain the reasoning rather than recite definitions: where each protocol sits in the stack, why a transmission can be corrupted or lost and which layer repairs it, how pointers and manual memory go wrong in C, and how you would shrink the latency of a slow routine or fit a data structure inside a memory limit. Candidates list those last two as example scenarios. For the communication half, build a small set of true stories from your own resume, because candidates report being asked about past projects in detail.

Two habits come up repeatedly in what candidates report. First, clarify the requirements of a coding problem before you write anything. Second, talk through your thinking as you go, because the stages are described as live problem-solving rather than a recall test. Practise both aloud, with a timer, and treat every written answer in the screening as writing practice too, since clear, concise English is listed among the screening topics.

The Aequor Healthcare Services interview process

Candidates describe these three stages in this order. The questions are practised by type here, because candidates do not tie particular questions to particular stages.

Screening Phase

Candidates report that the opening stage is either a phone conversation or a written assessment. Its reported content is aptitude and reasoning (numerical reasoning, pattern recognition, logical sequencing), core technical concepts and English, meaning clear and concise writing and speaking. The reported question types that fit this format are the logic puzzles on sequencing and patterns, short explanations such as TCP versus UDP or the basic principles of network architecture, and judgement questions such as working with limited information against a deadline. Because the format varies, prepare for both: practise puzzles against a clock for the written version, and practise giving a structured spoken answer (claim, reason, example) for the phone version.

What to demonstrate

Aptitude and reasoning on numerical, pattern and sequencing problems
Core technical concepts, with networking fundamentals reported as a recurring topic
Clear, concise written and spoken English

How to prepare

Do timed sets of number series, pattern and sequencing puzzles and say your reasoning out loud as you solve them
Write one short, complete answer each for TCP versus UDP and the principles of network architecture, then cut each to its essential points
Practise stating assumptions first when information is missing, as in the limited-information, strict-deadline question

Technical Rounds

Candidates report in-depth evaluations of coding and networking knowledge. The topics they list are C and C++ (memory management, pointers, performance optimization), networking basics (the OSI model, TCP/IP and troubleshooting scenarios) and system design in the sense of how components interact in a larger architecture. Two example scenarios are reported: optimizing a routine that causes high latency, and implementing a particular data structure to work within a memory constraint. The technical and debugging questions, including debugging a complex C-based application and keeping data intact over a network, are the ones to practise for this stage. Ask clarifying questions before coding, state your assumptions, and explain why you chose a design as well as how it works.

What to demonstrate

Working code and the ability to adapt to a variation of a problem rather than recall a stored answer
C and C++ fundamentals: memory management, pointers and performance
Networking knowledge: OSI model, TCP/IP and troubleshooting
How components fit together in a larger system

How to prepare

Write a ring buffer or fixed-capacity hash table in C with explicit allocation, and be ready to say who owns each pointer and when it is freed
For a slow routine, list what you would measure first, then separate algorithmic, memory-access and I/O causes before proposing a fix
Draw the layers of the OSI model next to the TCP/IP stack and place the protocols you use on them, then walk a connectivity failure from DNS up to the application
Rehearse a debugging sequence for a crash in C: reproduce, narrow the input, inspect memory use, confirm the fix with a test

Manager and HR Discussions

The final stage is reported as conversations with managers and HR about past experiences, work responsibilities and long-term alignment. Candidates are told to expect detailed discussion of their resume and past projects, and the topics listed for professional fit are project ownership and conflict resolution. The behavioral and managerial questions apply here: a significant challenge, ideal working environment and team morale, handling feedback, long-term career goals and how the role fits them, and leading or influencing a project outcome. Prepare each as a short story or position backed by something you actually did, and bring two or three questions of your own about the team's challenges or technical direction.

What to demonstrate

Your account of past projects and what you personally contributed
Ownership of deliverables and handling of disagreement in a team
Fit between your long-term goals and the role

How to prepare

Build a table of every project on your resume with your role, one technical trade-off, one problem you hit and the result
Write STAR stories (Situation, Task, Action, Result) for the significant-challenge, feedback and lead-or-influence prompts, each with one concrete outcome you can stand behind
Write a two-part answer on career goals: the skills you want to deepen and how this role's C, networking and production work supports them
Prepare two or three questions about the team's current challenges to ask at the end

Where candidates lose points

Answering TCP versus UDP or network architecture with a list of definitions

Anchor each comparison in a scenario: reliable ordered delivery with handshake, retransmission and congestion control against low overhead and no delivery guarantee. Say what an application must add itself if it picks UDP, and where each protocol sits relative to the OSI layers.

Starting to code before the requirements are clear

Candidates are told to clarify first. Restate the problem, ask about input size, memory limits and failure behavior, state assumptions aloud, then write. The memory-constrained data structure scenario is a prompt to practise this.

Memorizing solutions and stalling when the problem changes

Practise with variations: take a solved problem and change one constraint, such as a smaller memory limit or a streaming input, then re-derive the approach. Be ready to explain why you chose a structure, not just how it works.

Listing C or C++ on the resume but being unable to explain memory ownership in your own code

Review each C or C++ project you list: who allocates and frees each buffer, where pointer bugs could occur, and how you found one. Rehearse a debugging sequence for a crash in a C program and name what you check first.

Telling behavioral stories in the team's voice, with no personal decision and no measured result

For each STAR story, write one sentence starting 'I decided...' and one result with a number or concrete change. Use the same discipline for career goals and the ideal-environment question, backing each claim with something you did.

Questions & practice

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
Where does the fingerprint get computed relative to request decompression and the body-size limit?

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Explain the basic principles of network architecture.

Medium · Technical & Networking Fundamentals

Approach

Start from the layered model: name the OSI layers (physical, data link, network, transport, session, presentation, application), then map them onto the four TCP/IP layers (link, internet, transport, application). Say why layering exists: each layer uses the one below through a fixed interface, so Ethernet can be swapped for Wi-Fi without touching TCP.
Explain encapsulation and addressing per layer: frames carry MAC addresses (local delivery, resolved through ARP), packets carry IP addresses (end-to-end routing), segments carry port numbers (which process). Switches forward on MAC within a LAN; routers forward on IP between networks using a routing table and the default gateway.
Trace one request end to end to show the pieces working together: DNS resolves the name, ARP finds the gateway's MAC, the TCP three-way handshake opens the connection, TLS sets up encryption, then the HTTP request goes out and each router hop decrements the TTL.
Cover the architectural choices around that: client-server versus peer-to-peer, private address space behind NAT, subnetting (a /24 holds 256 addresses, 254 usable hosts), and where load balancers and firewalls sit in the path.
Close with the trade-off that layering costs: header overhead and some duplicated work (checksums at several layers), accepted in exchange for independent evolution of each layer.

Follow-up

What exactly happens, layer by layer, when you type a URL into a browser and press Enter?
What is the difference between a switch and a router, and where does NAT fit?
How many usable hosts does a /26 subnet give you, and why are two addresses lost?

Can you explain the difference between TCP and UDP?

Medium · Technical & Networking Fundamentals

Approach

Lead with the core contrast: TCP is connection-oriented and gives a reliable, in-order byte stream; UDP is connectionless and sends independent datagrams with no delivery, ordering or duplicate guarantees.
Name the TCP mechanisms behind the guarantee: three-way handshake (SYN, SYN-ACK, ACK), sequence numbers and acknowledgments, retransmission on timeout or duplicate ACKs, flow control through the receive window, and congestion control (slow start, additive increase and multiplicative decrease). Its header is at least 20 bytes against UDP's fixed 8.
Point out the framing difference that bites C programmers: TCP has no message boundaries, so one send() can arrive across several recv() calls or be merged with the next; the application needs length-prefixing or a delimiter. UDP preserves datagram boundaries but a datagram may be lost, duplicated or reordered.
Match each to workloads: TCP for HTTP/1.1 and HTTP/2, SSH, database connections and file transfer; UDP for DNS lookups, voice and video, games, and QUIC, which builds its own reliability and encryption on top of UDP to avoid TCP head-of-line blocking.
State the trade-off plainly: TCP buys correctness at the cost of handshake latency and stalls behind a lost segment; UDP gives low latency and control to the application, which must then handle loss itself if it cares.

Follow-up

Why does DNS normally use UDP, and when does it switch to TCP?
If you had to send reliable messages over UDP, what would you add?
What is the TIME_WAIT state, and why can it exhaust ports on a busy client?

How do you ensure data integrity during a network transmission?

Medium · Technical & Networking Fundamentals

Approach

Separate the threats: accidental corruption in transit, loss or truncation, duplication and reordering, and deliberate tampering. Each needs a different control, so say which ones the scenario has.
Describe what the network stack already does and its limits: Ethernet frames carry a CRC-32, the IPv4 header has a checksum covering only the header, and TCP and UDP carry a 16-bit ones' complement checksum (optional for UDP over IPv4). That 16-bit checksum is weak, so end-to-end checks belong in the application.
Add application-level verification: send a length prefix plus a checksum (CRC32C for fast accidental-error detection) or a hash such as SHA-256 for whole files, recompute on receipt, and re-request on mismatch. Compare the byte count too, so a truncated transfer cannot pass.
For tampering, a plain checksum is not enough because an attacker can recompute it: use an HMAC with a shared key, or TLS, whose AEAD ciphers such as AES-GCM authenticate every record as well as encrypting it.
Handle ordering and repeats with sequence numbers, acknowledgments and retries, and make the receiver idempotent (an idempotency key or a unique message id) so a retried message is applied once even though delivery is at-least-once.

Follow-up

Why is a SHA-256 hash not enough to stop tampering, and what does an HMAC add?
How would you detect and resume a large file transfer that was cut off halfway?
Can you get exactly-once delivery over an unreliable network? What do you build instead?

Solve a series of logic puzzles involving sequencing and patterns.

Medium · Aptitude & Reasoning

Approach

For number series, test rules in a fixed order: first differences, then second differences (constant second differences mean a quadratic), then ratios (geometric), then interleaved series on odd and even positions, then known sequences such as squares, cubes, primes and Fibonacci-style sums. Example: 2, 6, 12, 20, 30 has differences 4, 6, 8, 10, so the next term is 42, which matches n(n+1).
For letter series, convert letters to positions (A=1 to Z=26), find the numeric rule, and wrap around with arithmetic modulo 26; check for skips that grow (+1, +2, +3) or alternate direction.
For sequencing and arrangement puzzles, write every constraint down, draw the slots or a grid, place the fixed constraints first ("X is at an end", "Y sits third"), then branch on the remaining cases and eliminate any branch that breaks a constraint.
Verify before committing: plug the answer back into every given term or constraint, since a rule that fits only the last three terms is a common trap.
Manage the set as a whole: answer the patterns you recognise quickly first, mark the slow ones, and return to them, rather than sinking the whole budget into one puzzle.

Follow-up

Two different rules both fit the terms you were given. Which one do you choose and why?
Walk through how you would solve a five-person seating puzzle with four constraints.
How do you check that a pattern you found holds for every term, not just the recent ones?

How would you approach a situation with limited information but a strict deadline?

Medium · Aptitude & Reasoning

Approach

Split what is known from what is assumed, and write the assumptions down. Rank them by how much the work would change if each one were wrong, and confirm the riskiest one with whoever owns the requirement before building on it.
Define the smallest deliverable that meets the hard part of the deadline, then list what can follow afterwards. Say explicitly what is being cut and what that cut risks.
Prefer reversible choices while information is missing: isolate an uncertain interface behind an adapter or a configuration flag so a wrong guess costs one module, not a rewrite.
Timebox investigation: give a short spike a fixed budget to answer the open question, and if it does not, proceed on the documented assumption rather than stalling.
Set checkpoints and report early: tell the stakeholder the assumptions and the trade-off at the start, not the day before the deadline. A concrete example from your own work, with the outcome, makes this answer credible.

Follow-up

The assumption you built on turns out to be wrong two days before the deadline. What do you do?
What would you cut first, and how do you decide?
How do you tell a stakeholder the deadline and the full scope cannot both be met?

Provide an example of how you use quantitative data to inform your coding decisions.

Medium · Aptitude & Reasoning

Approach

Tell one real story in a measurable shape: baseline number, hypothesis, change, measured result. Example framing: "I profiled the request path, found most of the time in one lookup, replaced a linear scan with a hash map, and re-measured." Use your own numbers, not invented round ones.
Show that you measured before optimising: a profiler (perf, gprof, Valgrind's callgrind) to find the hot path, rather than guessing which function is slow.
Use the right statistics: latency percentiles (p50, p95, p99) rather than averages, which hide tail latency; repeated runs with warm-up so caches and JIT effects do not skew the comparison; and a note on run-to-run variance so a small gain is not mistaken for noise.
Connect the data to the decision: combine big-O with the real input size (a linear scan can beat a hash map for very small n), and name the trade-off you accepted, such as extra memory or code complexity.
Mention other data that drives coding choices: error rates and crash counts from logs to decide which bug to fix first, or usage counts to decide which code path deserves optimisation.

Follow-up

How did you know the improvement was real and not noise between runs?
What did the change cost you in memory, complexity or maintainability?
Why did you pick that metric rather than, say, average latency or throughput?

Can you explain a complex technical concept to a non-technical stakeholder?

Medium · Aptitude & Reasoning

Approach

Start from what the listener needs to decide or understand, not from the mechanism: "This affects whether reports arrive late or arrive incomplete" before any protocol detail.
Pick one analogy and state its limit. For TCP versus UDP: "TCP is like a phone call where I confirm every sentence was heard; UDP is like mailing postcards, faster but some may never arrive." Then say where the analogy breaks so it does not mislead.
Strip jargon, or define a term once in plain words if it has to stay. Keep to the two or three points that change the listener's decision.
Check understanding by asking the listener to restate the choice or its consequence, not by asking "does that make sense?"
End with the decision or request: the options, the cost of each, and the recommendation, so the conversation produces an outcome.

Follow-up

Explain the cause of a recent outage to a manager with no technical background.
The stakeholder pushes back on your recommendation. How do you respond?
How do you know whether your explanation landed?

How do you prioritize tasks when multiple critical bugs arise simultaneously?

Medium · Aptitude & Reasoning

Approach

Triage on impact first: how many users are affected, whether data is being corrupted or lost, whether there is a security exposure, and whether a workaround exists. Data corruption and security usually come first because the damage grows the longer they run.
Check for a shared cause before splitting effort: if several bugs appeared after the same deploy or configuration change, one rollback may clear all of them.
Mitigate before root-causing: roll back, disable the feature behind a flag, or apply a workaround to stop the damage, then investigate with less pressure.
Make ownership and communication explicit: one owner per bug, a stated priority order with the reasoning, and regular status updates to affected stakeholders so nobody duplicates work or waits in silence.
Close the loop afterwards: a regression test for each fix and a short post-incident review of why several issues reached production at once.

Follow-up

Two bugs have equal severity and you are the only person available. How do you choose?
Your manager disagrees with your priority order. What do you do?
What would you change so that several critical bugs do not reach production together again?

Describe your process for debugging a complex C-based application.

Medium · Technical & Networking Fundamentals

Approach

Reproduce first: pin down the input, build and environment that trigger the failure, then shrink the case. If the bug is intermittent, note whether it follows load, threads or timing, since that points toward a race rather than bad logic.
Get evidence from the crash itself: enable core dumps (ulimit -c unlimited), build with -g, and open the core in gdb for bt, frame, info locals and print. A stack that looks corrupted is itself a clue that something overwrote the stack.
Run the memory and undefined-behaviour tools: AddressSanitizer (-fsanitize=address) for buffer overflows, use-after-free and double free; UndefinedBehaviorSanitizer for signed overflow and bad shifts; Valgrind memcheck for leaks and reads of uninitialised memory; ThreadSanitizer for data races. Compile with -Wall -Wextra so the compiler flags the easy ones.
Narrow the cause: git bisect between a known-good and known-bad build, strace or ltrace when the failure sits at the syscall or library boundary, and targeted logging around the corrupted value. Separate the trigger (the line that crashes) from the cause (the earlier write that broke the data).
Finish the fix properly: add a regression test that fails without it, and explain why a bug that vanishes at -O0 or after adding a printf usually means undefined behaviour or a timing race, not a fixed bug.

Follow-up

The crash disappears when you add a printf. What does that tell you, and what do you do next?
How would you debug a crash on a production machine where you cannot attach a debugger?
Memory grows slowly over days. How do you tell a leak from heap fragmentation?

Suggested practice checklist

The plan follows the three reported stages. Day 1 maps the loop and your resume, days 2 to 4 cover networking, C debugging and memory work, day 5 covers puzzles and judgement questions, day 6 covers behavioral stories, and day 7 is a spoken rehearsal.

Day 1 — Map the loop and inventory your resume

Write the three reported stages (Screening Phase, Technical Rounds, Manager and HR Discussions) with the question types each covers, then rank networking, C, puzzles and behavioral stories by how ready you are
List every project on your resume with your role, one technical trade-off, one problem you hit and the result, since candidates report detailed resume discussion

Deliverable: A one-page loop map with your weakest area marked, and a resume project table covering every project you list.

Day 2 — Networking fundamentals

Draw the OSI model beside the TCP/IP stack and place the protocols you have used on it, then explain the basic principles of network architecture from the diagram
Write a TCP versus UDP table covering handshake, ordering, retransmission, congestion control, overhead and typical uses, and say when you would choose each
Answer the data-integrity question aloud: checksums and CRCs, sequence numbers and retransmission, and end-to-end hashes or authenticated encryption

Deliverable: A layered diagram, a TCP versus UDP table, and one spoken answer each for network architecture, TCP versus UDP and data integrity.

Day 3 — Connectivity failures and debugging C

Write a checklist that localizes a connectivity failure from DNS to application response, and note what each tool (ping, traceroute, curl, tcpdump) rules out
Write a small C TCP client with a connect timeout and retries using exponential backoff with jitter, and note which calls are safe to retry
Plant a use-after-free or off-by-one bug in a short C program and write the debugging sequence you would follow, then solve the idempotency-fingerprint practice problem to see why retries need keys

Deliverable: A failure checklist, a working C client, a written debugging log for your planted bug and a solved idempotency practice problem.

Day 4 — Memory limits and slow routines in C

Implement a ring buffer or fixed-capacity hash table in C with manual allocation, and write down who owns each pointer and when it is freed
Take a slow routine you wrote and list what you would measure first, then separate algorithmic, memory-access and I/O causes with one fix for each
Solve the practice problem on finding the heaviest tenants in a window under memory pressure, and compare its approach with your data structure

Deliverable: A working C data structure with ownership notes, a written latency analysis of one routine, and a solved memory-pressure practice problem.

Day 5 — Puzzles, judgement and plain-language explanations

Do timed sets of number series, pattern and sequencing puzzles, speaking your reasoning, and log which kinds slow you down
Write answers to the limited-information deadline question, the quantitative-data coding decision question and the prioritizing-simultaneous-bugs question, using impact, urgency and workaround to rank bugs
Write a plain-language explanation of a technical concept (a memory leak or TCP retransmission) for a non-technical stakeholder
Work the practice window-function problem on version gaps to rehearse reconciling records that conflict

Deliverable: A puzzle log, three written judgement answers, one stakeholder explanation and a solved reconciliation practice problem.

Day 6 — Behavioral stories and career goals

Write STAR stories for the significant-challenge, feedback and lead-or-influence prompts, each with an 'I decided' sentence and a concrete result
Write your answers on ideal working environment and team morale, naming one practice and one thing you did for the team
Write the three-part career-goals answer and two or three questions to ask the team about its current challenges

Deliverable: Three written STAR stories, two written position answers, and a list of questions for the team.

Day 7 — Full spoken rehearsal in loop order

Give short spoken or written screening-style answers to a puzzle and to TCP versus UDP, as you would for a phone or written assessment
Solve one C data-structure problem and one networking scenario aloud, clarifying requirements first and explaining why you chose your design
Walk through your resume and career goals as you would with a manager, then record yourself and list the three biggest fixes

Deliverable: A recorded rehearsal covering all three stages and a list of three fixes to apply before the interview.

Stories for the manager and HR stage

Candidates report that the final stage, Manager and HR Discussions, covers past experiences, work responsibilities and long-term alignment, with detailed discussion of resume projects. Project ownership and conflict resolution are named as topics. The reported behavioral questions below ask for a challenge, your preferred working environment, how you take feedback, your career goals and a time you led or influenced an outcome. Prepare each with a real example and a concrete result, in the first person singular.

Describe a disagreement with a teammate over a technical decision and how it was resolved.

How do you handle connectivity issues in a distributed system?

Medium · Technical & Networking Fundamentals

Approach

Answer this one as a technical diagnosis, not a story. Localize first: is the failure one client, one service, one network path or everything? Then walk the stack bottom-up: name resolution, TCP connect, TLS, then the application response, using ping, traceroute, curl -v, ss or netstat, and tcpdump if needed.
Read the symptom. A refused connection means nothing is listening or a firewall is rejecting; a timeout suggests dropped packets, a silent firewall or an overloaded peer; a reset means the peer crashed or a middlebox closed an idle connection.
Build tolerance into the code: explicit connect and read timeouts, retries only for idempotent calls using exponential backoff with jitter and a retry budget, and idempotency keys so a retried write cannot apply twice.
Contain the damage: a circuit breaker so a failing dependency is not hammered, health checks that pull bad nodes out of rotation, keepalives or heartbeats to detect half-open connections, and queue-and-replay or cached fallbacks where stale data is acceptable.
Close with monitoring: alert on connection-error and timeout rates per dependency, not only on up/down status.

Follow-up

A request timed out: how do you know whether the server processed it, and how do you make the retry safe?
How do you stop retries from turning a small outage into a retry storm?
How would you tell a network fault from an overloaded server using only what you can observe from the client?