05The 60-second brief

Verkada builds hardware and enterprise cloud software together. Its six product lines are video security, access control, sensors, alarms, workplace and intercoms. Its cloud platform, Command, connects and manages devices such as video security cameras, access control systems, environmental sensors, alarms and workplace management tools. A Software Engineer works on the software side of that pairing: the cloud services devices connect to, the communication between the edge and the cloud, and the frontend interfaces that make video and sensor data actionable. Interview questions follow that shape. Alongside standard algorithm problems, expect design and networking questions about devices that stream video, raise alarms and lose connectivity.

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

06What a Software Engineer does at Verkada

Teams named for the role include Device Platform, Alarms, Access Control and Platform Infrastructure. The problems include networking, concurrency, real-time video streaming and cloud infrastructure. Languages named for the role include Go, Python, C++ and TypeScript with React. AWS services such as Kubernetes, Fargate, Lambda, DynamoDB and EC2 appear in role descriptions.

For preparation, this mix means one algorithms track is not enough. Reported questions include standard coding problems such as merging intervals and a constant-time insert, delete and random-access structure. They also include design problems tied to devices: a low-latency video backend for many concurrent cameras, an alerting system that has to guarantee delivery of critical alarms, and syncing door controller databases with the cloud through a network outage. Networking questions on TLS, DNS troubleshooting, TCP versus UDP and VLAN configuration come up too, so review them even if you are applying for a general backend or frontend role.

07The Verkada interview process

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

Recruiter Phone Screen

Candidates describe this as a call about your background, your interest in the company and your alignment with the role. Treat it as a chance to get information as well as give it. Ask whether the final loop's technical focus differs for frontend, backend or embedded candidates, and whether the technical screen is an online assessment or a live call. One reported behavioral question asks which physical security product line excites you most, so have a specific answer ready here as well.

What it evaluates

• Whether your background matches the role you applied for
• Whether your interest in Verkada is specific: a named product line and an engineering problem it implies, rather than a general interest in security
• Whether your experience and goals line up with the role as described

How to prepare

• Write one sentence that names a product line (video security, access control, sensors, alarms, workplace or intercoms) and one engineering problem behind it, such as a door controller that has to keep working offline
• Ask which track you are interviewing for and whether the technical screen is an online assessment or a live call, and if it is live, whether it focuses on algorithms, frontend or systems networking
• If you have a competing deadline, raise it on this call so there is still time to plan the rest of the process around it

Initial Technical Screen

Candidates report that this screen is either an online coding assessment or a live video call with an engineer, focused on algorithm design, frontend development or systems networking. Be ready to run and debug your code during the round, so practise until your solutions pass tests, not just until they look right. Prepare with the reported coding questions, which are not tied to a specific round: merging overlapping intervals, a class supporting insertion, deletion and random retrieval in constant time, ordering a stream of real-time alerts by priority and timestamp, and graph traversal for shortest paths or cycle detection over a network of devices.

What it evaluates

• Whether your code runs and handles edge cases, not only whether the idea is right
• Whether you choose data structures from the access pattern, such as a heap for priority ordering or an array plus a hash map for constant-time random removal
• In a networking-focused screen, whether you can explain protocols step by step and troubleshoot methodically

How to prepare

• Practise in your own local IDE, and write a small test file before each solution that feeds the examples, an empty input and a single-element input
• Drill the reported coding questions with their traps: touching intervals such as [1,3] and [3,5], deleting the last element in the random-access set, and equal priorities in the alert stream
• If the recruiter says the screen covers networking, rehearse the TLS handshake, DNS resolution and TCP versus UDP out loud until you can explain each in order without notes

Final Round Interview Loop

Candidates describe a half-day loop made up of several one-on-one technical interviews, a system design session, a behavioral round with an engineering manager and a technical presentation to a panel. For the presentation, you pick a technical topic, usually a project you worked on, present it for about 20 minutes, and then take questions from the panel. Confirm with your recruiter whether the one-on-ones lean frontend, backend or embedded for your track. For the design session, practise with the reported design questions, which are not tied to a specific round: a low-latency video streaming backend, a fault-tolerant alerting system with guaranteed delivery, an API rate limiter, and syncing door controller databases with the cloud during network outages.

What it evaluates

• In the one-on-one technical interviews, whether you can write code that runs and holds up against the edge cases you are asked about
• In the design session, whether your system survives the failures devices actually hit: lost connectivity, retries, duplicate events and traffic spikes
• In the presentation, whether you can explain the architecture, defend trade-offs under questioning and make your own contribution clear
• In the behavioral round, whether your stories show decisions you made and what you learned from them

How to prepare

• Build the presentation around a project you drove, rehearse it to time in front of someone who interrupts with questions, and have diagrams that can be read at a glance
• For each reported design question, write down the failure you are designing for and how the system recovers before you draw any boxes
• Prepare stories for the four reported behavioral prompts, each with a specific decision, what it cost and what you would change

08Questions Verkada candidates report

These are the prompts PracHub has collected for this role and company. They are a record of what candidates describe being asked, so treat them as the shape of the conversation rather than a script Verkada works from.

Data structures and algorithms

State the bound, then read your own code against it, because the cost you forgot is usually inside a call you did not write. A membership test against a list is linear while the same test against a set is expected constant, so one of those inside a loop turns a linear scan quadratic. Taking a slice copies the elements wherever slices are values rather than views. Repeated string concatenation is quadratic wherever strings are immutable, unless you accumulate into a builder or a list and join once. None of that is visible in the shape of the algorithm, and all of it is visible in the runtime.

• Given a list of intervals, merge all overlapping intervals and return the minimized list.
• Implement a custom sorting mechanism for a stream of incoming real-time alerts based on priority and timestamp.
• Implement a class that supports insertion, deletion, and retrieving a random element in constant time.

System design and architecture

At any point in a design you should be able to name the one resource that gives out first and what it costs to move it. Most follow-ups push on exactly that: traffic rises tenfold, a region is lost, a stricter consistency requirement appears. Answers hold up when the assumptions were said out loud early, because the design can then be re-derived from them rather than defended. The weak move under pressure is to add a component. The strong one is to say which part absorbs the change, which part has to be rebuilt, and roughly what the rebuild costs.

• Design an API rate limiter to protect Verkada's cloud platform from malicious traffic or device-side misconfigurations.
• Design a real-time video streaming backend that can support low-latency playback for thousands of concurrent security cameras.
• How would you design a distributed, fault-tolerant alerting system that processes millions of sensor events per second and guarantees delivery of critical alarms?

Behavioural and engineering judgement

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

• Why do you want to work at Verkada, and which of our physical security product lines excites you the most?
• Tell me about a time you had to deliver a highly technical project on a tight deadline. How did you manage trade-offs between speed and code quality?

Other topics

A large share of these are really questions about evidence: why something is slow, or how much of something you would need. Convert the prompt into a number or an observation. For diagnosis, name the measurement that would tell two candidate explanations apart and say what each predicts before you collect it. For sizing, carry the units through and stop at one significant figure. Listing everything that could plausibly be true is what the weak version looks like. What separates the strong one is a hypothesis, the observation that would falsify it, and what the arithmetic already rules out before any new data arrives.

• Build a custom React component in a timed session that renders a grid layout of video player cards with responsive controls.

09Practice exercises with worked solutions

The prompts above tell you what gets asked. These are PracHub exercises written to drill the same skills, with the reasoning spelled out so you can check your own answer instead of guessing whether it was good enough.

Paginate a tenant's delivery export without skipping rows

A customer exports webhook_delivery: delivery_id (bigint identity), subscription_id, tenant_id, event_id, status, attempt_count, next_attempt_at, created_at, delivered_at, updated_at. The endpoint runs select ... where tenant_id = $1 order by created_at desc limit 100 offset $2, and customers report rows missing from exports taken while new deliveries are being inserted. Write the replacement query and the index that supports it, paging a tenant's deliveries newest first at constant cost per page. State why updated_at cannot be the cursor column.

How a strong candidate works it

• Name the defect precisely. OFFSET is a position in a result set that is recomputed on every request, so a row inserted ahead of the window shifts everything back by one and the next page starts after a row the client never received. Nothing errors and no identifier gap appears, so the loss is silent.
• Replace the position with a value predicate over a stable, unique, indexed ordering: where tenant_id = $1 and (created_at, delivery_id) < ($2, $3) order by created_at desc, delivery_id desc limit 100. The row comparison is load-bearing: created_at alone is not unique, so ties straddling a page boundary are dropped or repeated, which is the same bug in a smaller window.
• Index (tenant_id, created_at, delivery_id). PostgreSQL scans a btree in either direction, so an all-DESC ORDER BY is served by an ASC index read backwards and no DESC modifiers are needed; they only matter when the ORDER BY mixes directions. Confirm the plan has no Sort node above the index scan, or the LIMIT stops being an early exit.
• Price both forms: keyset is one index descent plus 100 adjacent leaf entries per page, constant regardless of depth, while OFFSET still produces and discards every skipped row, so page N costs time proportional to N times the page size and a deep page on a large table goes from milliseconds to seconds.
• Rule out updated_at as the cursor from the precondition, not from taste: a cursor column must never change value for a row already paged past. updated_at moves on every delivery attempt, so a row the client already emitted re-enters a later page and is exported twice. created_at and delivery_id are immutable, which is the whole qualification.

Follow-ups

• The client wants a snapshot as of one instant rather than a live tail. Compare a repeatable-read transaction held open, an added created_at <= $snapshot bound, and a materialised export table.
• A retention job deletes deliveries older than 90 days. What does a client mid-walk see, and does keyset pagination help at all?
• The customer wants to resume an export from yesterday's last cursor. What must be true of the cursor for that to be safe?

Explain why the metering dashboard scans every daily partition

usage_event is range-partitioned daily on ingested_at and holds tenant_id, workspace_id, environment, sku, quantity numeric(20,6), occurred_at and ingested_at. The only relevant index is on (occurred_at). A dashboard runs select sku, sum(quantity) from usage_event where tenant_id = $1 and date_trunc('hour', occurred_at) >= $2 and environment = 'production' group by sku, and EXPLAIN shows a sequential scan of every partition. Give each distinct reason, rewrite the predicate so an index can serve it, propose the index, and state the write cost its column order adds.

How a strong candidate works it

• Separate the three causes rather than blaming one. First, date_trunc('hour', occurred_at) wraps the column, so the predicate is not sargable against a btree on the bare column. Second, pruning keys off ingested_at while the query constrains occurred_at, so no partition can be excluded. Third, even made sargable, (occurred_at) is not tenant-leading, so for one tenant among thousands the scan reads the whole time range and discards nearly all of it.
• Rewrite the bound carefully, because the obvious rewrite is only conditionally equivalent. date_trunc('hour', x) >= $2 equals x >= $2 only when $2 is already hour-aligned; for an arbitrary $2 it means x >= date_trunc('hour', $2) + interval '1 hour'. Normalise the parameter in the caller and leave the column bare.
• Restore pruning with a second, redundant predicate on the partition key: ingested_at >= $2 - interval '<late-data horizon>'. State both sides of it. It prunes to a handful of partitions, and it silently omits any event whose ingest lagged past that horizon, which is precisely what a producer replay produces. Either document the horizon as a stated bound, or partition on occurred_at and move the problem into the dedup window instead.
• Propose (tenant_id, occurred_at) include (sku, quantity) per partition. A partial index where environment = 'production' mostly saves size rather than selectivity, since production dominates the three environments; take it if non-production is a meaningful share and skip it otherwise.
• Price the write path honestly. At roughly 250M rows/day each extra index is another insert plus WAL per row, and a tenant-leading key scatters inserts across one hot leaf per active tenant instead of appending to a single rightmost leaf, so page dirtying and random I/O both rise. An INCLUDE payload widens every leaf entry and enlarges the index accordingly.
• Add the index-only-scan caveat before someone reports it as a regression: on a freshly appended table the visibility map is not yet set for recent pages, so the INCLUDE columns still cost heap fetches until autovacuum has been through, and the newest hour is exactly the data the dashboard reads.

Expected result (30 min): Three causes named separately: a non-sargable date_trunc, pruning on ingested_at against a predicate on occurred_at, and a non-tenant-leading index. A rewrite to occurred_at >= <hour-normalised $2> plus a redundant ingested_at >= $2 - horizon, an index on (tenant_id, occurred_at) including sku and quantity, a per-row write cost stated, and the late-data omission the pruning predicate introduces stated as a known bound.

Check yourself

• The plan lists only partitions inside the ingested_at bound.
• Rows removed by filter on the index scan is small relative to rows returned.
• The rewritten and original predicates agree for both hour-aligned and non-aligned bounds.
• A deliberately late-ingested event is visible or omitted exactly as the stated horizon predicts.

Follow-ups

• CREATE INDEX CONCURRENTLY is not supported on a partitioned parent. Give the sequence that gets this index onto 400 existing partitions without blocking ingest.
• One tenant holds 200 times the median row count and the dashboard still times out for them with the index in place. What changes?
• Should this read hit usage_rollup_hourly instead? State what that costs in freshness and what the watermark lets you promise.

Parse and verify a timestamped multi-signature webhook header

An inbound webhook carries a signature header of at most 1 KiB shaped t=<unix seconds>,v1=<64 hex chars>, with up to five v1 values during secret rotation and possibly unknown scheme keys. You hold the raw request body bytes and the currently active signing secrets. Write the parser and the verifier: accept when any active secret reproduces a signature and the timestamp is within a five-minute tolerance in either direction, reject otherwise. Single left-to-right pass over the header, no regular expression. State what is inside the MAC and why.

How a strong candidate works it

• Parse in one scan: split on ,, then on the first = only, since a value may itself contain = under a future scheme. Accept t exactly once and treat a second t as a reject rather than last-wins. Push every v1 onto a short list and ignore any other key, so a v2 can be introduced later without breaking this verifier.
• Say what is signed: HMAC-SHA256 over the exact byte string <t>.<raw body bytes>, yielding 32 bytes or 64 hex characters. The timestamp sits inside the MAC because otherwise an attacker replays yesterday's body with its still-valid signature and only has to edit the header timestamp.
• Hash the bytes as received. Verifying against a re-serialised JSON body is the usual defect: key order, whitespace and number formatting all change the bytes while the parsed objects compare equal, so signatures fail for honest senders and the popular 'fix' is to stop checking.
• Compare in constant time over fixed-length digests. Decode the hex to 32 bytes, accumulate acc |= a[i] ^ b[i] across the whole length, and test acc == 0 at the end. Evaluate every candidate without an early exit; at five candidates that is five HMACs over the body, linear in body size and negligible beside the network.
• Apply the tolerance as a two-sided bound, rejecting when |now - t| > 300 seconds. A sender whose clock runs ahead of yours is an ordinary case, and an unbounded future timestamp is a free replay window.
• Complexity: O(L) over the header producing k candidates, plus k HMACs at O(|body|) each. Space is O(k) beyond the body itself. Do the cheap rejections, including the tolerance check, before any cryptography runs.

Expected result (15 min): The valid case accepts. Both out-of-tolerance cases reject, including the future one. The unknown v2 field is ignored and the v1 still verifies. The re-serialised body fails, which is correct and is exactly why the raw bytes must be retained.

Check yourself

• Timing the comparison over 10,000 mismatching signatures that differ at the first character versus the last shows no separation you can measure.
• Removing t from the MAC input makes an old captured body with its original signature pass. Write that test, watch it pass, then put t back.
• Every rejection except the signature mismatch itself returns before an HMAC is computed.

Follow-ups

• The body is 40 MB. What changes about where you verify, and what can you do before the whole body has arrived?
• A customer reports that signatures fail for exactly the requests whose body contains a non-ASCII character. What is your first hypothesis?
• How do you rotate the signing secret with no failed deliveries, and how long do both secrets stay live?

Build a resumable usage export the customer can reconcile against

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

How a strong candidate works it

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

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

Check yourself

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

Follow-ups

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

Hourly rollups merge one hour and lose another

Reconciliation flags one tenant on one day. Summing usage_event.quantity by hour of occurred_at gives 24 non-empty hours, but usage_rollup_hourly holds 23 rows for that tenant, workspace and SKU, one of which carries roughly the sum of two adjacent hours. Other days reconcile exactly, and the affected date matches a civil-time transition. hour_start is documented as truncated to the hour in UTC. You have both tables, the rollup job source, and its runtime environment. Give an ordered checklist, the mechanism, and the correction path for a day that may already be sealed.

How a strong candidate works it

• Bisect by dimension until one cell explains the whole difference: tenant, then day, then SKU, then hour. A defect confined to a single transition date already rules out deduplication and late arrival, both of which are indifferent to which hour an event lands in.
• Read the truncation with its precondition stated: date_trunc on a timestamptz value is evaluated in the session TimeZone, not in UTC. If the job connects without pinning that setting, it inherits the server or container default.
• Follow that to the collision: in a zone that observes daylight saving, two distinct UTC hours map to the same local wall-clock label at the autumn transition, so both fold into one key under the unique constraint on (tenant_id, workspace_id, sku, hour_start) and their quantities sum into one row. At the spring transition a label never occurs and the row is simply absent.
• Confirm from data rather than from reading code: run the same aggregate twice, once with the session pinned to UTC and once with the job host zone, and check that the second reproduces the stored rollup exactly.
• Fix at the source by pinning the connection to UTC explicitly, or by truncating on occurred_at AT TIME ZONE 'UTC', rather than relying on a default that differs between a developer machine, CI and production.
• Correct according to status, not convenience: an open hour is recomputed with revision incremented, a sealed hour is frozen and the difference becomes an adjustment line on the next invoice with voided_by_line_id pointing at the line it reverses.

Follow-ups

• The same job also emits a daily figure for a dashboard. Why can a correct hourly rollup still produce a wrong day, and what does the tenant's billing timezone have to do with it?
• How would you detect this class automatically rather than waiting for reconciliation, given that it only manifests twice a year per zone?

Argue against failing open when the control plane is unreachable

The gateway caches credential-to-context decisions with a sixty-second TTL. A design proposal says that when control-plane reads fail, pods should keep serving from expired entries indefinitely so a control-plane outage never becomes a product outage. You believe that converts every revocation into an unbounded one. Describe a design you argued against while it was still a live proposal: what you measured or modelled to make the case, what you conceded, who decided, and what happened afterwards. Say what would have changed your mind before the decision, not after it.

How a strong candidate works it

• Reframe it from a values argument into a bounded-staleness argument. Both sides already accept the cache; the disagreement is only about the ceiling on how long a revoked credential keeps authorising. Put a number on the table — serve stale for up to fifteen minutes, then fail closed — and make the other side argue against a number rather than against a principle.
• Bring arithmetic rather than adjectives: the rate of revocations with revoked_reason in ('suspected_leak','auth_version_bump'), the observed distribution of control-plane unavailability, and the product of the two, which is expected requests served by revoked credentials per outage-hour. At 30k requests/second the unbounded version is not a subtle exposure and the number says so.
• Concede the strong half of the opposing case first, because that is what buys you the room: failing closed turns one service's outage into a total outage across three regions, and a control plane doing tens of writes per second is not engineered to the gateway's availability target. A proposal you have not steelmanned reads as reflex.
• Propose the asymmetry that usually resolves this: stale entitlements cost bounded money (a quota fifteen minutes out of date over-serves by a computable amount), while a stale revocation costs unbounded access. Split the cached decision by what it authorises, give the two halves different staleness ceilings, and let the entitlement half fail open while the revocation half fails closed.
• State the propagation dependency plainly, since it is the part that is missed: validity is also derived from the principal's auth_version, so password reset and sign-out-everywhere flow through this same cache. A design that bounds staleness for explicit revocation and not for auth_version bumps has only fixed half of it.
• Say who decided, and what you did afterwards in either outcome: write the decision down with its number and a review date, and instrument the exposure you were worried about so the next round of the argument is settled by data instead of by seniority.

Follow-ups

• Publish-subscribe invalidation is lossy under a partition, and a TTL is the only hard bound. What TTL do you pick, and what does it cost you at 30k requests/second?
• The key was revoked because it was found in a public repository. Does your answer change, and where does that urgency live in the design?
• You lost the argument and six weeks later the failure you predicted happens. What do you say in the review, and what do you not say?

10Where candidates lose points

Treating the technical presentation as a slide tour of a project you did not drive

Candidates describe the presentation as its own round, with panel questions about your architectural choices and your individual contribution. Choose a project where you were the main decision-maker. Structure it around the problem, the constraints, the decision and the alternatives you rejected, what went wrong, and the result. Rehearse it to time, then have someone interrupt you with questions such as 'why not the obvious alternative?' and 'which part was yours?'. If a panelist's question can only be answered with 'the team decided', you picked the wrong project.

Code that reads correctly but has never been run

Be ready to run and debug code in real time, possibly in your own local environment. Set up your IDE, compiler and test runner before the interview. Practise the reported problems until they pass tests, not just until they look right. Common failures: merge intervals on unsorted input or touching intervals, a random-access set that removes by swapping with the last element but forgets to update the moved element's index, and an alert ordering that has no tie-break for equal priority and timestamp.

Designing device systems as if the network never goes down

Several reported design questions depend on failure: door controllers syncing with the cloud through an outage, and alarms whose delivery has to be guaranteed. Start by saying what the device does while it is offline and which side is authoritative for each decision. Queue events locally with sequence numbers or idempotency keys so replays do not create duplicates. Give a conflict rule for changes made in the cloud during the outage, especially revoked access. For alarms, cover acknowledgement, retry and deduplication, and keep critical alarms apart from bulk telemetry so a flood of routine events cannot delay them.

Skipping networking because the role title says software, not network

Reported questions cover HTTP versus HTTPS and the TLS handshake, DNS resolution and troubleshooting a device that cannot resolve the cloud endpoint, TCP versus UDP for real-time video, and a VLAN or routing misconfiguration blocking an access control unit. The initial screen may also focus on systems networking. Practise a layer-by-layer troubleshooting story: physical link and addressing, then DHCP, DNS, routing and firewall, then TLS and the application. Say what command or observation rules out each layer before you move to the next one.

A generic answer to why Verkada and which product line

One reported behavioral prompt asks which physical security product line excites you most. 'I care about security' gives the interviewer nothing to follow up on. Name one line (video security, access control, sensors, alarms, workplace or intercoms) and one engineering problem it implies, for example rendering many live camera feeds in a browser without memory leaks, or keeping door access working offline. Then connect it to something you have built.

11Algorithms first, for a candidate whose problem-solving has gone rusty

For someone who has spent the last few years shipping features and reading other people's code, and who has not solved a timed problem from a blank file in a long time. Five days rebuild the primitives and the patterns that sit on them, working from invariants rather than remembered solutions, and the last two attach that back to the rest of the loop.

Day 1 — Reported coding problems, written to run

• Merge overlapping intervals: sort by start and extend the current end with a max. Test touching intervals, a fully nested interval, unsorted input and an empty list.
• Insert, delete and getRandom in O(1): use an array plus a value-to-index map, and delete by swapping with the last element. Test deleting the element that is already last.
• Order a stream of real-time alerts by priority, then timestamp: use a heap keyed on (priority, timestamp, arrival sequence) and explain what the sequence number breaks ties on.
• Solve the bank's interval variants on camera data: common active intervals across cameras, and motion intervals above a threshold.

Deliverable: Four solutions that run in your local IDE, each with a test file covering the edge cases above.

Day 2 — Caches, concurrency and graph traversal

• Implement an LRU cache with a hash map and a doubly linked list, then an LFU cache. Make the LRU cache thread-safe and test it under concurrent writes.
• Write a non-blocking wrapper around a blocking API using a worker pool and futures, and state what happens when the pool is saturated.
• Implement BFS for shortest paths and DFS cycle detection over a directed graph of devices, including the difference between in-progress and finished nodes.
• Work the webhook signature parser (drill-coding-3) in your local editor as a timed parsing drill, then compare your version against the worked exercise.

Deliverable: A thread-safe LRU with a concurrency test, a working non-blocking wrapper, and BFS and DFS implementations with test graphs.

Day 3 — Video: streaming backend and live-feed frontend

• Design a low-latency streaming backend for thousands of concurrent cameras. Separate the live path from recorded playback and say where fan-out to viewers happens.
• Choose between TCP and UDP for the live path and explain the head-of-line blocking trade-off on a lossy link.
• Design storage for footage with hot and cold tiers: what moves between them, when, and what playback latency each tier gives.
• Frontend track: build a React grid of video player cards with responsive controls, then list how you would render hundreds of live feeds without dropping frames or leaking memory (virtualise off-screen tiles, release media on unmount).

Deliverable: One diagram showing the live and playback paths, with the failure behaviour of each component written next to it.

Day 4 — Device-to-cloud reliability designs

• Design an alerting system that processes a high volume of sensor events and guarantees delivery of critical alarms. Cover acknowledgement, retry, deduplication by event id, and a separate lane for critical alarms.
• Design door controller sync with the cloud through a network outage: which side is authoritative offline, how queued events replay, and how a revocation made during the outage takes effect.
• Design an API rate limiter against misconfigured devices: the key (device or organisation), the algorithm, and what response tells a device to back off.
• Sketch the bank's camera health monitoring and per-status device counts from heartbeats, then read the worked design exercise (drill-design-4) for its cursor and late-data reasoning.

Deliverable: Three one-page designs, each opening with the failure it is built for and its recovery path.

Day 5 — Networking and systems fundamentals

• Explain HTTP versus HTTPS and walk through the TLS handshake step by step, including where certificates are checked.
• Trace DNS resolution from stub resolver to authoritative server, then write the ordered troubleshooting steps for a device that cannot resolve the cloud endpoint.
• Work the VLAN tagging or routing table scenario that blocks an access control unit from reaching its gateway, and explain what a DHCP reservation does and when you would use one.
• Review running executables from bash (paths, permissions, exit codes). Frontend track: explain call, apply and Promises well enough to predict what small snippets output.

Deliverable: A one-page layer-by-layer troubleshooting runbook you can talk through without notes.

Day 6 — The technical presentation

• Pick a project you drove and outline it: the problem, the constraints, the architecture, the decision and the alternatives you rejected, what went wrong, and the result.
• Draw the architecture diagrams so each one makes a single point and can be read at a glance.
• Rehearse to about 20 minutes, record it, and cut whatever pushes you over time.
• Write ten questions a panel would ask about your trade-offs and your individual contribution, and answer each out loud.

Deliverable: A finished deck, one timed recording, and written answers to the ten panel questions.

Day 7 — Behavioral round and a mixed mock

• Prepare stories for the four reported behavioral prompts: delivering on a tight deadline, diagnosing a complex bug, why Verkada and which product line, and disagreeing with a lead on a design choice.
• For the design disagreement, use drill-behavioral-6 as the model: put a number on the risk, concede the strongest part of the other side, and say who decided.
• For the bug story, use the structure of drill-debugging-5: narrow the scope, form a hypothesis, confirm it with data, and fix it at the source.
• Run a mock loop: one coding problem solved and tested locally, one reported design question, and presentation Q&A from a friend.

Deliverable: Four behavioral stories with a decision and a lesson each, plus notes from the mock on the weakest round.

12Frequently asked questions

Is this an official Verkada interview guide?

No. It is PracHub's own research and practice material for the Software Engineer role at Verkada. Rounds and questions reflect what candidates have reported, not a process Verkada has published, and they change over time. Confirm the current format and scope with your recruiter.

How difficult are the technical interviews at Verkada?

Candidates describe them as average to difficult. Reported coding questions are standard algorithm problems, such as merging intervals or a structure with constant-time insert, delete and random retrieval. Design and networking questions are tied to devices, video and cloud scale. Prepare those with concrete failure cases, such as a device that goes offline or a lossy link, rather than generic scaling diagrams.

What is the format of the technical presentation round?

Candidates report a presentation of about 20 minutes on a technical project of your choice, followed by questions from a panel of engineers about your architecture, trade-offs and individual contribution. Pick a project you drove, rehearse it to time, and practise with someone who interrupts with hard questions.

Is the final round in person?

The final round may be in person or virtual; ask your recruiter which applies to you. If it is in person, also ask whether you will code on your own laptop, so you can set up your environment and test runner in advance.

How fast does Verkada make hiring decisions?

Candidates report quick updates after the final round, in some cases within a few days. Timelines vary, so if you have a competing deadline, raise it at the recruiter screen rather than after the loop.

Do I need networking knowledge if I am applying for a backend or frontend role?

Prepare for it. Reported questions cover the TLS handshake, DNS resolution and troubleshooting, TCP versus UDP for real-time video, and a VLAN or routing misconfiguration. The initial technical screen may also focus on systems networking. Aim to walk through a failed connection layer by layer and say what rules out each layer.

Do frontend, backend and embedded candidates get different questions?

Reported questions span frontend, backend and embedded topics; ask your recruiter which track you are on and what that changes. Reported frontend questions include building a React grid of video player cards, explaining call, apply and Promises, and rendering hundreds of live feeds without memory leaks. The question bank also includes an embedded threading question.

Which programming language should I use?

Use the language you are fastest and most accurate in. Role descriptions name Go, Python, Java, C++ and JavaScript or TypeScript. Be ready to run and debug your code during the interview, so practise in the environment you will actually use and be fluent with its test runner and debugger.

13Keep practising

• Verkada questions on PracHub — 22 Software Engineer questions in the bank.
• Software Engineer question bank — cross-company practice.
• Interview preparation framework
• All interview guides