Bevera Solutions Software Engineer Interview Guide

The 60-second brief

Candidate reports list Software Engineer openings at Bevera Solutions on two tracks: a Senior Infrastructure Subject Matter Expert track and a UX/UI and Web Design Specialist track. The infrastructure side is described as backend infrastructure management in Atlanta, and the web side as user-facing web communications in Riverdale. The reports name no product line or customers, so nothing here assumes a particular system. What they do tell you is the shape of the work: keeping a digital footprint stable on one track, and producing accessible, fast web content on the other, with cloud-based infrastructure listed as a nice-to-have.

This guide is for candidates interviewing for a Software Engineer role at Bevera Solutions, whichever track the posting describes. It covers the five questions candidates report (an infrastructure failure story, design versus page-load trade-offs, content management and data integrity, web accessibility methods, and integrating new tools into a legacy environment), the reported evaluation areas, and how to turn your own projects into answers. It does not cover coding puzzles, because none are reported.

No round sequence is reported for this loop. Candidates describe a scenario-driven process with detailed discussion of past projects, and say it runs a few weeks from first screen to decision.

Focus areas

• Software Engineering
• Infrastructure Engineering
• Web Development

Overview

The reported questions split into two families. One family is infrastructure: troubleshooting a failure, keeping a system stable through a traffic spike, and rolling out automated updates to production. The other is web delivery: trading visual polish against page weight, meeting accessibility standards, and keeping content correct inside a content management system. The fifth reported question, integrating new tools into a legacy environment, applies to both. Because the two tracks overlap only partly, the first preparation step is learning which track your posting belongs to.

Candidates also report that the loop leans on your own experience. Past projects are described as the starting point for technical deep-dives, and the advice given to candidates is to answer in the STAR structure and to explain the reasoning behind each decision, not only the tools used. That means most of your preparation is selecting the right three or four projects and being able to defend every choice in them: what you measured, what you rejected, what broke, and what you wrote down afterwards.

Three evaluation themes come up in candidate reports for the infrastructure track: reliability (monitoring and incident response), scalability (growing without slowing down) and documentation (records that let a team carry on after you). For the web track the matching themes are interface quality, accessibility against WCAG and content integration. Requirements candidates describe also include strong debugging and clear written communication, so practise writing a short incident summary or design rationale as well as speaking one.

Reports mention cross-departmental meetings as part of the job. Have one example where you explained a technical constraint to someone outside engineering, such as a communications or operations colleague, and what changed because of it.

Where to focus your preparation

No separate rounds are reported, so the loop is treated as a single preparation focus built around the five reported questions and the infrastructure and web evaluation areas.

Preparation focus

Candidates do not report a round-by-round sequence for Bevera Solutions. They describe a loop that mixes technical discussion with scenario-based questions, covering Software Engineering, Infrastructure Engineering, Web Development, UX Design and UI Design, and they are told to expect detailed conversation about their own past projects. Treat this step as the whole process. Before anything else, ask your recruiter which track you are interviewing for (infrastructure or web design), how many stages there are, and whether any of them involves writing code. Then prepare the five reported questions plus two reliability scenarios candidates mention: a sudden traffic spike that threatens stability, and automated updates in a production environment.

What to demonstrate

• Breadth across the reported topics: software engineering, infrastructure, web development, UX and UI
• Whether you can explain a past project in depth, including why you made each decision
• Clear written and spoken communication of a debugging or design process

How to prepare

• Write the recruiter questions (track, number of stages, any coding) and send them before you invest in one track
• Prepare two STAR stories from your own work: one production failure you diagnosed and one content or data change you verified
• Outline answers to the traffic-spike and automated-update scenarios, covering monitoring, scaling, rollout and rollback
• Prepare a short, specific answer for each web question: a page-weight budget, an accessibility checklist tied to WCAG, and a phased legacy integration plan

Where candidates lose points

Telling the infrastructure failure story as a list of tools with no decisions in it

Structure it as detect, contain, diagnose, fix, prevent. State the single decision you owned at each point and what evidence drove it, and keep the tool names to the ones that mattered.

Treating the mitigation and the root cause as the same step when describing an outage

Say explicitly what restored service (rollback, failover, load shedding) and, separately, what explained the failure. The same separation applies to the traffic-spike and automated-update scenarios.

Reducing accessibility to "I run an automated checker"

Combine automated scans with keyboard-only navigation, a screen reader pass, colour-contrast and focus-order checks, and map findings to WCAG success criteria. Automated tools find only part of the issues, so name the manual checks.

Answering the design versus page-load question by picking a winner

Set a page-weight and load budget, then spend it deliberately: compress and size images, limit fonts and scripts, lazy-load below the fold, and keep the visual elements that carry the design. Say how you measured before and after.

Proposing a big-bang replacement when asked about integrating tools into a legacy environment

Describe an inventory of what the legacy system does, a thin adapter or phased cutover, a period of running both, a tested rollback, and written documentation for the people who maintain it afterwards.

Questions & practice

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

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

1. 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.
2. 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.
3. 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.
4. 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?

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

1. 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.
2. 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.
3. 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.
4. 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?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

• The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
• How do you verify the backfill actually finished, given rows are still being inserted while it runs?

How do you balance the trade-offs between aesthetic design and page load performance?

Medium · Technical and Domain Proficiency

Approach

1. Turn the trade-off into a budget before arguing taste: target the Core Web Vitals 'good' thresholds at the 75th percentile (LCP under 2.5 s, INP under 200 ms, CLS under 0.1), and check both lab data (Lighthouse) and field data (CrUX or your own RUM), because a design that passes on a fast laptop can fail on a mid-range phone.
2. Keep the visual and cut its weight: serve hero imagery as AVIF/WebP through srcset and sizes, give every image width and height (or aspect-ratio) so it cannot shift layout, lazy-load below-the-fold images, and never lazy-load the LCP image; mark it fetchpriority="high" instead.
3. Handle brand fonts as a cost line: limit families and weights, subset to the glyphs used, ship WOFF2, preload only the critical face, and pick font-display swap or optional, with a size-adjusted fallback so the swap does not move text.
4. Keep motion cheap: animate transform and opacity, which the compositor handles, instead of width, height or top, which force layout; honour prefers-reduced-motion; load carousel, animation or video libraries only on the pages that use them, with code splitting and defer.
5. Close with the decision rule: price each design element in kilobytes and milliseconds against what it adds, offer the designer a cheaper equivalent (CSS gradient instead of a background photo, poster image instead of autoplay video), and guard the agreed budget with Lighthouse CI or bundle-size checks so it holds after launch.

Follow-up

• Marketing wants an autoplaying background video on the home page. What do you build so the page still meets its LCP budget on mobile?
• Field LCP regressed after a redesign while lab scores look fine. How do you find the cause?
• How do you stop a carefully tuned page from getting heavier again over the next six months?

What specific methodologies do you use to ensure web accessibility compliance?

Medium · Technical and Domain Proficiency

Approach

1. Name the standard and level: WCAG 2.2 Level AA, organised by the POUR principles (perceivable, operable, understandable, robust). Know the concrete checks: text contrast at least 4.5:1 (3:1 for large text and for UI components and focus indicators), reflow at a 320 CSS px wide viewport without horizontal scrolling, and pointer targets of at least 24 by 24 CSS px under 2.2.
2. Build it in rather than audit it on: native semantic HTML first (button, a, label tied to its input, landmarks, one logical heading order), and ARIA only where no native element exists, because a wrong role or state is worse than none. Every form field gets a visible label, and errors are described in text, not signalled by colour alone.
3. Automate the cheap layer: axe-core or Lighthouse in CI and eslint-plugin-jsx-a11y in the editor. Be clear that automated tools find only a subset of failures (missing alt text, contrast, missing labels) and cannot judge alt text quality, focus order or whether a flow makes sense.
4. Run manual passes every release: a keyboard-only walk-through (logical tab order, visible focus, no keyboard traps, a skip link), a screen reader pass on at least two pairings such as NVDA with Firefox or Chrome and VoiceOver with Safari, and 200% zoom. For content sites, require alt text in the CMS (empty alt for decorative images) and captions for video.
5. Make it a process: accessibility in the definition of done, contrast and focus states checked at design review, findings logged by severity with owners, and third-party widgets and PDFs checked before adoption, since they fail just as often as your own code.

Follow-up

• How would you build an accessible custom dropdown or combobox, and which keyboard keys and ARIA states does it need?
• In a single-page app, what happens to focus and screen reader announcements on a route change, and how do you fix it?
• An automated scan reports zero issues. Why is that not proof of compliance?

How do you approach the integration of new software tools into an existing legacy environment?

Medium · Technical and Domain Proficiency

Approach

1. Start with discovery: map how the legacy system is called and what it calls (APIs, batch jobs, shared database tables, file drops), who owns each piece and which flows are revenue-critical, then write characterization tests that pin current behaviour, quirks included, before changing anything.
2. Integrate behind a seam, not a big-bang swap: put a facade or routing layer in front of the old system (the strangler fig pattern) and an anti-corruption layer that translates between the legacy data model and the new tool's model, so neither leaks into the other.
3. Treat the data as the hard part: avoid naive dual writes, since one write can succeed while the other fails; prefer one source of truth with change data capture or a one-way sync into the new tool, plus a reconciliation job that compares row counts and checksums and reports drift.
4. Roll out reversibly: run the new tool in shadow mode on real traffic and diff its outputs against the legacy result, then move traffic behind a feature flag in slices (one team, one region, a small percentage), with a written rollback path and dashboards for error rate and latency on both paths.
5. Finish the job: update runbooks and documentation, train the people who operate it, set an explicit date to decommission the old path once parity metrics hold, and remove the facade branches, so the estate does not end up running two systems indefinitely.

Follow-up

• The legacy system has no tests and no documentation. How do you learn what it actually does before integrating?
• During the parallel run the new tool and the legacy system disagree on some records. How do you decide which one is right?
• How would you make the cutover reversible if a problem appears a week after full migration?

One log partition stops advancing while the others drain

Easy · poison message · head-of-line blocking · consumer lag

Search results for a subset of tenants are hours stale; the rest are current. The projection consumer reports lag of zero on 15 of 16 partitions and 400,000 on one. Its error rate is flat and its CPU is idle. outbox_event has no pending rows older than a second, so the relay has published everything it holds. Identify the mechanism, give the ordered checks, and state what you do in the first ten minutes versus what you change permanently.

Approach

1. Read the lag distribution first. A slow consumer lags everywhere; zero on fifteen partitions and 400,000 on one is not throughput. Idle CPU on the stuck partition means the consumer is not advancing its offset at all, which points at one message it cannot get past rather than at a rate problem.
2. Exonerate the producer before touching the consumer. No pending outbox rows older than a second means the relay published, so the event exists in the log. This separates never sent from sent and never applied, which are different code paths and usually different owners.
3. Read the message at the stuck offset and the handler's log lines for its event_id. A flat error rate with no progress has two explanations and you must distinguish them: the handler is throwing and the retry loop is swallowing it, or the handler is blocking on something and never returning. Idle CPU with no error lines favours the second.
4. Mitigate before diagnosing further. Move the offending event to a dead-letter store and commit the offset past it. Adding consumers does nothing here, because a partition is consumed by exactly one member of the group, and the blast radius is every aggregate hashed to that partition, not only the aggregate that produced the bad event.

Follow-up

• The dead-lettered event carried aggregate_version 7 and the projection had applied 6. What must the replay do differently if 8 and 9 landed in the meantime?
• How do you show staleness to the user while the partition is behind, given the API already returns the projection's watermark?

Suggested practice checklist

The plan starts by pinning down the track and format, then works through the five reported questions grouped as infrastructure, content integrity, web delivery and legacy integration, ending with a full spoken run.

Day 1 — Confirm the track and map your projects

• Send your recruiter questions: which track (infrastructure or UX/UI web), how many stages, and whether any stage involves writing code.
• List four projects from your own work and note, for each, one failure, one measurable result and one decision you owned.
• Match each of the five reported questions to the project that answers it best.

Deliverable: A sent list of recruiter questions, a four-project inventory, and a table matching each reported question to a project.

Day 2 — Infrastructure failure story

• Write a STAR outline for the troubleshooting question: detection, containment, diagnosis, fix, prevention, with the evidence for each step.
• Say the story aloud once and cut anything that is a tool name without a decision.

Deliverable: A one-page STAR outline for the infrastructure failure story and a written check order for the stalled-partition practice question.

Day 3 — Reliability scenarios

• Outline an answer for a sudden traffic spike that threatens stability: what you watch, what you shed or cache, how you scale, and how you confirm recovery.
• Outline an answer for rolling out automated updates in production: staged rollout, health checks, automatic halt, rollback and who is told.
• Write the runbook entry you would leave behind for each scenario, since documentation is a reported evaluation area.

Deliverable: Two scenario outlines and two short runbook entries.

Day 4 — Content systems and data integrity

• Write your answer to the content management question: the systems you used, your role, and your definition of data integrity.
• Pick one migration or publishing incident and list the checks you ran or would run (counts, link checks, restore test, staging review).

Deliverable: A written content-integrity answer, a verification checklist for one migration, and a stepwise backfill plan with a check after each step.

Day 5 — Page performance and accessibility

• Take a page you built or know well, record its load measurements with a browser performance audit, and set a page-weight budget with a plan to spend it.
• Run a keyboard-only pass and a screen reader pass on the same page and write each issue against the WCAG success criterion it breaks.
• Write a two-minute spoken answer for each of the aesthetic-versus-performance and accessibility-methods questions.

Deliverable: A before-and-after performance note with a budget, an accessibility issue list mapped to WCAG, and two spoken-answer outlines.

Day 6 — Legacy integration and estimating

• Outline an integration plan for adding a new tool to an existing system: inventory, adapter or phased cutover, parallel running, rollback, documentation.
• Practise explaining the plan to a non-engineer in four sentences.

Deliverable: A one-page legacy integration plan, an estimate with named assumptions, and a four-sentence version for a non-engineer.

Day 7 — Spoken dry run

• Answer all five reported questions aloud in one sitting, using the projects from day 1, and record yourself.
• Rehearse a deep-dive on one past project: be ready to defend each decision and say what you would change.
• Write three questions to ask your interviewers about current technical challenges and how engineering works with other departments.

Deliverable: A recording of all five answers, a one-project deep-dive outline, and three questions for interviewers.

Incident and content-integrity stories

Candidates report that the loop uses your own experience as the basis for technical conversation, and that clear explanation of the reasoning behind your choices counts. The two behavioral-style questions reported are a troubleshooting story and a content management story, and both are answered best with a real project, the decision you owned, and the check that proved the outcome. Reports also mention working with people outside engineering, so prepare one example of that.

1. Tell me about a time you introduced a new tool into an existing system and how you limited the risk to people already using it.
2. Describe a time you explained a technical constraint to a colleague outside engineering and what changed as a result.
3. Tell me about a time you found a process that wasted effort and what you did about it.

Describe a time you had to troubleshoot a critical infrastructure failure; what was your process?

Medium · Technical and Domain Proficiency

Approach

1. Pick one real failure where you owned part of the response, and say your role in the first sentence. Keep your own actions separate from what the wider team did, and use "I" for the parts you drove.
2. Walk the sequence in order: how it was detected (alert, user report, dashboard), how you limited damage first (rollback, failover, shedding load, disabling a feature), and only then how you found the cause. Interviewers want to hear that you separated stopping the bleeding from finding the root cause.
3. Show the diagnosis as hypotheses you ruled out with evidence: recent deploys or config changes, saturation of CPU, memory, disk or connection pools, a failing dependency, certificate or DNS expiry. Name the signal that narrowed it down, such as a log line, a metric that diverged or a failing health check.
4. Close with the fix, the proof it worked, and what you changed afterwards: an alert, a runbook entry, a test, or a change to the release process. Documentation is a reported evaluation area, so mention the written record you left behind.
5. Avoid a tool inventory. A sentence like "I rolled back the release first, then reproduced the failure in staging and found the pool was exhausted" shows reasoning; a list of monitoring products does not.

Follow-up

• How did you decide between rolling back and fixing forward?
• How did you keep non-engineering stakeholders informed while the system was degraded?
• What monitoring or process change did you make so the same failure is caught earlier next time?

Explain your experience with content management systems and how you ensure data integrity.

Medium · Technical and Domain Proficiency

Approach

1. Name the content management systems you have actually used and your role with each: author, administrator, plugin or template developer, or the person who migrated content. Be specific about versions or hosting only if you know them.
2. Define data integrity in concrete terms before you answer: required fields and validated content models, working internal links and media references with no orphans, revision history so a bad change can be reverted, and permission and review steps that stop unreviewed content reaching the live site.
3. Back each claim with a check you ran: a link checker after a restructure, row or page counts compared before and after a migration, a restore test from backup, or a staging environment where content and templates were reviewed before promotion.
4. Tell one story with a decision in it, for example a migration or a bad publish. State what could have been lost or broken, the verification you chose, and the result. A story where nothing went wrong and nothing was checked is not evidence of integrity.
5. Mention concurrency and access: what happens when two editors change the same page, who can publish, and how you recorded changes. Keep it to what you really did.

Follow-up

• How would you verify that a migration between two content systems lost nothing?
• How did you recover from a change that should not have been published?
• What happens when two editors save conflicting changes to the same page?

Estimate work you have never done and defend the range

Hard · estimation · backfills · expand-contract

You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

Approach

1. Decompose into independently deployable steps before estimating anything: add the column nullable, write both shapes, backfill in batches, verify, move reads, stop writing the old shape, drop it. That is four deploys spread over days, and the calendar estimate is dominated by them rather than by the loop's runtime.
2. Do the arithmetic aloud for the part that has arithmetic in it: batch size times number of batches times per-batch duration, at a write rate the primary can absorb alongside roughly 1.2k writes per second of production traffic. The loop is throttled by replication lag and lock waits, not by how fast it can issue statements.
3. Price the schema step by its lock rather than its statement duration. In PostgreSQL an ALTER TABLE taking ACCESS EXCLUSIVE waits for every open transaction on that table while later queries queue behind it, so a millisecond change issued during a thirty-second analytics query stalls that table for thirty seconds. Adding a nullable column with a non-volatile default avoids a rewrite from version 11; a new index wants CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block and leaves an invalid index behind if it fails.
4. Express the answer as a range whose endpoints each trace to a stated assumption, then name the cheapest experiment that collapses it, which is almost always running one real batch against the real table and multiplying.

Follow-up

• How do you verify the backfill genuinely finished, given rows written by production traffic while it ran?
• Where does the backfill resume from after a worker is killed mid-batch, and what makes that resume point trustworthy?