American Engineering Testing Software Engineer Interview Guide

The 60-second brief

Candidates describe American Engineering Testing as a firm that offers testing, inspection and engineering consulting services, with work that touches physical materials such as concrete and soil. The Software Engineer role sits on the internal software side. Reports mention tools for collecting data from the field, automating reporting workflows and tracking project progress, with field engineers and project managers as the people who use them. Candidates also mention improving the reporting interface that clients see and bringing digital tools into older engineering workflows.

This guide is for Software Engineer candidates at American Engineering Testing. Candidates describe the role as open to a range of experience levels. It covers the two reported rounds, the background and domain questions candidates report, how to answer each one, and a seven-day plan. Deep coding tests are not the reported focus, so the guide spends its time on explaining your projects, showing real interest in field engineering, and handling the logistics of a short process.

Candidates report two rounds over roughly 2-4 weeks: an initial contact through a career fair, email or recruiter outreach, then a one-on-one interview by phone or at a regional office.

Focus areas

• Technical interview skills
• Communication skills (verbal)
• Software engineering role understanding

Overview

The reported work is practical software for an engineering services firm: getting measurements and field observations out of the field and into a system, automating data entry and report generation, and keeping project-tracking tools dependable. Candidates describe the engineers and project managers as the main users, and the Software Engineer as the person who turns what they need on a job site into working software. That is a different picture from a product company with a large engineering org, and the interview reflects it.

Candidates describe the interviews as conversational and low-pressure, and the reported questions are about you: "Tell me about yourself.", "What was your specialty?", "What are your expectations for this role?" and "How do you envision your daily operations?". Candidates report that deep coding tests are not the main focus. Your preparation is therefore about story quality. Choose two or three projects you can explain from end to end, covering what data went in, what your code did to it, who used the output and what you would change now.

The other reported theme is interest in the physical side of the work. Candidates are asked whether they have background knowledge on concrete, and the requirements they describe list civil engineering, materials science or data visualization as nice-to-have rather than required. Most software candidates will have little or no direct background, so the aim is an honest answer plus visible curiosity: learn the basic vocabulary of materials testing, think about how field data becomes a client report, and prepare questions about the team's projects and clients.

Candidates also report that responsiveness matters in a process that moves quickly and is often arranged by email or phone. Keep your resume current and ready to send, since recruiters may request it early, and reply to scheduling messages promptly. If the role is tied to a regional office, be ready to say why that location works for you.

The American Engineering Testing interview process

Candidates report two stages, and the reported questions cover background and domain interest rather than algorithm puzzles. The format and order below are what candidates describe.

Initial Contact

Candidates report that the process opens with a connection through a career fair, an email, or a recruiter reaching out to talk about your background. They also report that a recruiter may ask for your resume at this point. Treat it as a first conversation where you give a clear, short account of who you are and what you have built, and where your reliability shows in how quickly and cleanly you handle the logistics.

What to demonstrate

• How clearly you describe your background and your specialty
• Whether your resume is current and available when it is requested
• How promptly and professionally you handle email and scheduling

How to prepare

• Update your resume and keep a PDF ready to send the moment it is asked for.
• Write and rehearse out loud your answers to "Tell me about yourself." and "What was your specialty?", each tied to software that handles data or reports.
• Prepare a two-sentence reason for wanting an engineering testing firm over a pure software company.
• Set up a calendar and a phone routine so you can answer scheduling messages the same day.

One-on-One Interview

Candidates report a personal, one-on-one interview held by phone or in person at a regional office, in a conversational and low-pressure tone. Reported questions cover your background, whether you know anything about concrete, what you expect from the role and how you picture your daily work. Candidates report that deep coding tests are not the primary focus, so prepare to talk through your past projects clearly and to connect them to field data and engineering reports.

What to demonstrate

• How well you connect your software experience to a field engineering and materials testing context
• Your interest in the work and your picture of the role and its daily tasks
• How you explain past projects and how you have learned new domains before

How to prepare

• Choose two projects and outline each as data in, processing, output, user and what you would change.
• Learn basic materials vocabulary such as compressive strength, curing, slump and soil moisture, so you can answer the concrete question honestly and ask informed follow-ups.
• Write a daily-work answer for a developer who supports field engineers and project managers: intake of requests, building, testing with users, fixing bottlenecks.
• Prepare questions about the software team's current projects and the clients the firm serves, and look up the regional office if the role is tied to one.

Where candidates lose points

Answering "Tell me about yourself." by reading your resume in date order

Build the answer as present, past and future, choose only the experiences that relate to data, automation or reporting, and finish on the role you want. Your resume is a separate document you can send when asked.

Saying "no" to the concrete question and stopping, or bluffing a technical answer

Say plainly what you do know, then show you have done the homework: mention basics such as compressive strength and curing, or soil moisture and density, and ask how software helps the team handle that data. Honest curiosity beats a guess.

Giving "learn and grow" as your expectations for the role, with nothing about this job

Tie your expectations to the reported work: automating data entry, improving client reports, supporting field engineers. Say what you want to build, what you want to learn about the field, and how you would judge that you were useful.

Describing a daily routine that could belong to any developer anywhere

Picture the people who use your tools, field engineers and project managers, and walk through a day: a request from a job site, a fix to a form or report, testing it with the user, then follow-up. Ask the interviewer how close that is to reality.

Treating the process as casual and slipping on logistics, such as a slow reply or a resume that is out of date

Candidates report that recruiters may ask for a resume early and that responsiveness is noticed. Keep a current PDF ready, answer scheduling messages the same day, and confirm whether the interview is by phone or at a regional office.

Questions & practice

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

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?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

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

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

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

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

What was your specialty?

Medium · Background and Introduction

Approach

1. Name one specialty in a single sentence (for example backend services and databases, data processing, or front-end reporting tools), then back it with one project: the problem, the stack, what you built yourself and a number that shows the result (rows processed, hours saved, error rate cut).
2. Tie the specialty to the work candidates describe for this role: field data collection and reporting. Say which part carries over, such as schema design for inspection records, input validation, or turning raw measurements into a client-ready report.
3. If your specialty is a degree track rather than a job, give the coursework or capstone that shows it and the language you wrote it in, so the claim can be checked against your resume.
4. Name the adjacent skill you would have to learn for the job and how you would learn it (reading the test standards the engineers work to, shadowing a field technician), so the answer shows range without overclaiming.

Follow-up

• Which project best shows that specialty, and what part of it did you write yourself?
• How would that skill apply to software that tracks field tests or produces client reports?
• What is outside your specialty that this job would make you pick up first?

Can you send me your resume?

Medium · Background and Introduction

Approach

1. Treat it as a logistics request and answer it quickly: candidates report the resume can be requested early, so keep a current PDF ready, named with your name and the role, and confirm in one line that you have sent it.
2. Keep it to one page for early-career candidates, with a projects section that leads with work closest to this role: data entry automation, form or database tools, report generation, dashboards or data visualization.
3. Write each bullet as action, tool, result: 'I built a Python script that parsed lab spreadsheets into PostgreSQL and cut manual entry for 300 rows a week.' Use only numbers you can defend.
4. List any civil engineering, materials or lab coursework explicitly, since candidates describe that background as a plus for this role, and put a working link to code you can walk through.

Follow-up

• Walk me through the top project on your resume: what did you build and why that design?
• Which of the languages listed here have you used most recently, and on what?
• Is there anything on your resume you would explain differently in person?

Do you have any background knowledge on concrete?

Medium · Domain Knowledge and Interest

Approach

1. Be honest about your level, then show you have done basic homework: concrete is cement, water, aggregate and admixtures, and a lower water-cement ratio generally gives higher strength but lower workability.
2. Name the common field tests: slump (ASTM C143) for workability, air content (ASTM C231 pressure method) for freeze-thaw durability, concrete temperature (ASTM C1064), and casting cylinders in the field (ASTM C31) that are later broken in compression in the lab (ASTM C39), commonly at 7 and 28 days.
3. Connect it to software: each sample becomes a record with project, mix design, placement location, field results and scheduled break dates; the system then checks results against the specified strength and flags anything that falls short.
4. Mention an edge case that shows care with data: unit mismatches (psi vs MPa), cylinders broken late or missing, a break schedule that must follow the cast date, and the difference between one cylinder and a strength test (usually the average of the cylinders from one sample).
5. If you know soil testing too, add one line on compaction (Proctor tests, ASTM D698 or D1557, and field density checks); if not, say you would learn it the same way.

Follow-up

• How would you model a concrete cylinder test in a database, and what fields are required before a report can go out?
• How would your system flag a low strength result, and who should be notified?
• How would you get up to speed on the testing standards the engineers use?

What are your expectations for this role?

Medium · Domain Knowledge and Interest

Approach

1. Answer with three concrete expectations: the kind of work you want (building and maintaining internal tools that field and project staff use), how you want to grow (a skill or stack you name), and how you like to work (frequent contact with the people using the software).
2. Ground it in what candidates describe for this role, such as improving data collection and reporting tools, rather than in generic ambitions, and show you understand the users are engineers and technicians, not other developers.
3. Address location directly: candidates report roles tied to regional offices, so say whether you can work from that office and why it suits you.
4. Close with one question that checks your expectations against reality, such as which tools the software team is focused on now or how requests from field staff reach the developers.

Follow-up

• Where do you want to be technically in two years, and how does this role get you there?
• What would make this job a poor fit for you?
• Are you comfortable working from that office, and on-site with field staff if needed?

How do you envision your daily operations?

Medium · Domain Knowledge and Interest

Approach

1. Outline a realistic day built on the responsibilities candidates describe: fixing and improving internal tools, automating manual data entry, working on client-facing reports, and talking with field engineers and project managers about what slows them down.
2. Describe your working loop: take a request, restate it back to the requester, reproduce the problem with real records, ship a small change through version control and review, then confirm with the person who asked that it fixed their problem.
3. Show how you would prioritize: a bug that blocks a report a client is waiting on comes before a convenience feature; batch small requests and keep a visible list so field staff know where their request stands.
4. Add one technical point that fits field work: if data is captured on site with poor connectivity, store entries locally and sync later with a unique id per record so a retried upload does not create duplicates, and decide how conflicting edits are resolved.

Follow-up

• A field engineer needs a fix today while you are mid-way through a planned feature. What do you do?
• How would you gather requirements from a user who describes the problem but not the solution?
• How would you make sure a change to a reporting tool does not alter numbers in reports already sent to clients?

Listing latency scales with page size, not with filters

Easy · n+1 · latency · query batching

The tenant listing endpoint reads resource filtered by tenant_id and status, ordered by updated_at DESC, and returns each row plus the owner's display name from app_user and the actor of that resource's latest resource_revision. p99 is 55 ms at 10 rows per page and 1.4 s at 200. Database telemetry shows 401 statements per request, each under 1 ms, and nothing in the slow-query log. Diagnose the cause and give the fix, stating the statement count per request and the p99 you expect afterwards.

Approach

1. Read the counters before forming a theory. 401 statements for 200 rows is one driver query plus two per row, and sub-millisecond execution with an empty slow-query log rules out a bad plan. The time is round trips, which is why it is invisible in every per-query metric and scales with rows returned rather than with filter selectivity.
2. Name the two per-row statements from their normalised text: a single-row app_user lookup by user_id, and a resource_revision lookup by resource_id ordered by version DESC LIMIT 1. Confirm by dropping those two response fields and watching the statement count fall to one. That locates the calls in the serialisation layer, not the repository.
3. Check that the arithmetic accounts for the whole gap. Measure one round trip to the replica in isolation; 400 trips at roughly 3 ms of network plus 0.2 ms of execution is about 1.3 s on top of a 55 ms baseline, which matches. If the multiplication had fallen short, the N+1 would only be part of the story and you would keep looking.
4. Batch both lookups. Collect owner_user_ids and resource_ids from the driver query, then issue WHERE tenant_id = $1 AND user_id = ANY($2) for the users, and PostgreSQL's SELECT DISTINCT ON (resource_id) ... WHERE resource_id = ANY($2) ORDER BY resource_id, version DESC for the latest revision, which the UNIQUE (resource_id, version) index serves directly. On an engine without DISTINCT ON, use a lateral join or a row_number window. Three statements per request at any page size.

Follow-up

• The page size is capped at 200 today. What breaks first if it is raised to 2,000, and is it still this bug?
• How do you stop the next N+1 from reaching production, given that no individual query is slow and the endpoint's tests pass?

Suggested practice checklist

The plan follows the two reported rounds and the six reported questions: logistics and your introduction first, then the domain and role questions, then your own stories and a full dry run.

Day 1 — Resume and project inventory

• Update your resume and save a PDF you can send within minutes, which covers the question about sending your resume.
• List two or three projects and, for each, write one line each for data in, processing, output, user and what you would change.
• Set up reminders for email and calls so scheduling messages get same-day replies.

Deliverable: An updated resume PDF and a one-page inventory of your projects in the data-in, processing, output, user format.

Day 2 — Introduction and specialty

• Write a present, past, future outline for "Tell me about yourself." and speak it aloud twice.
• Write a one-sentence specialty statement with two pieces of proof, then say it aloud for "What was your specialty?".
• Record yourself and cut anything that is not about data, automation, reporting or your next step.

Deliverable: A written outline of your introduction, a specialty statement with two proof points, and one recording of both answers.

Day 3 — Concrete and soil basics

• Read a short introduction to concrete and soil testing and list ten terms with a one-line meaning, such as compressive strength, curing, slump and moisture content.
• Write an honest answer to "Do you have any background knowledge on concrete?" that states what you know and what you would learn first.
• Write three questions about how the team's software handles lab or field results.

Deliverable: A ten-term glossary, a written answer to the concrete question and three questions for the team.

Day 4 — Field data to client report

• Sketch how a measurement taken on a job site becomes a client report: entry form, validation, storage, review, report output.
• Mark where errors and delays could appear, such as bad entries, missing connectivity or manual re-keying, and note how software could reduce each.
• Turn the sketch into a three-sentence answer for "How do you envision your daily operations?".

Deliverable: A one-page flow sketch with bottlenecks marked and a three-sentence daily-operations answer.

Day 5 — Expectations for the role

• Write your answer to "What are your expectations for this role?" covering what you want to build, learn and be judged on.
• Check each sentence against the reported work: automating data entry, client reporting, supporting field engineers and project managers.
• Say the answer aloud for a phone-style conversation and shorten it until it sounds natural.

Deliverable: A written and spoken answer to the expectations question that names tasks from the reported work.

Day 6 — Learning and translating stories

• Outline three stories: learning an unfamiliar domain, automating a manual process, and explaining a technical constraint to a non-programmer.
• Write each as situation, action and result, with one number or visible outcome apiece.

Deliverable: Three outlined stories with results, and one rehearsed spoken narration of a past project.

Day 7 — Full dry run

• Run a phone-style mock with a friend, covering all six reported questions in a random order.
• Check the logistics: resume PDF ready, calendar clear, the regional office located if the role is tied to one.
• Finalize two or three questions about the team's projects and the clients the firm serves.

Deliverable: One completed mock, a revised weak answer and a final list of questions to ask.

Behavioural preparation

Candidates report conversational stages that centre on your background, your interest in an engineering domain and how you would fit a collaborative team. Prepare short stories that show how you learn new fields, how you turn a manual process into working software, and how you work with people who are not programmers. The reported questions come first below.

1. What was your specialty?
2. What are your expectations for this role?
3. How do you envision your daily operations?
4. Describe a time you had to learn an unfamiliar domain well enough to build something useful for it.
5. Tell me about a time you replaced a manual process with software and how you knew it saved effort or reduced errors.

Tell me about yourself.

Medium · Background and Introduction

Approach

1. Use a present, past, future shape. Start with what you do now and the kind of software you build or study, add one or two earlier steps that explain how you got here, and end with why a software role at an engineering testing firm is your next step.
2. Pick details that relate to data and reporting: scripts that replaced manual spreadsheets, forms or dashboards, pipelines, or any work with measured or physical data. If you have none, name the closest experience and say why field-facing software interests you.
3. Include one concrete result with a visible outcome, for example a weekly report that went from a manual process to a script, stated with a number if you have one, so the answer shows what you delivered and not only what you were responsible for.
4. Keep it a conversation opener, not a recitation of your resume. Close on a hook such as the project you would most like to explain, so the next question comes from your story. Rehearse the structure until it is natural, but do not memorize word for word.

Follow-up

• Which of those projects would you most like to walk through in detail?
• What drew you to an engineering testing firm rather than a pure software company?
• What would you want to learn first about the field side of the work?

Tell callers you do not own that their integration breaks

Medium · deprecation · compatibility · stakeholders

A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

Approach

1. Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
2. Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
3. Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
4. Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.

Follow-up

• How would you detect a consumer that reads the field only during a monthly export?
• One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?

Narrate an outage you owned from page to postmortem

Hard · incident response · blast radius · postmortems

Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.

Approach

1. Open on the signal rather than the cause: which metric at which percentile moved, on which service, at what time, so the listener follows the same evidence you had rather than a conclusion you already reached.
2. Separate mitigation from diagnosis out loud. State what you did to stop the bleeding (flag off, shed traffic, drain a lease, roll back a deploy) and say plainly that you did it before the mechanism was known, because those are two jobs with different deadlines.
3. Establish blast radius in countable terms: how many tenants, how many writes, and crucially whether the effect was loss or only delay. An append-only revision table or a pending outbox row means the change survived and the projection was merely behind, which is a repair rather than a data-loss incident.
4. Prove the mechanism instead of asserting it. Name the trace span that grew, the plan that flipped to a sequential scan, the lease that expired, plus one alternative you ruled out and the signal that stayed flat while you ruled it out.

Follow-up

• What would you do differently in the first five minutes, given the same dashboard and no more information?
• Which follow-up action did you deliberately not take, and why was dropping it the right call?