SDET (Software Development Engineer in Test) - Mid Level Interview Preparation Guide (FAANG Standard)

Approach summary (SDET perspective)

Generate data deterministically, at scale, and load it quickly while validating statistical properties before test runs. Use parallel generation, idempotent seed pipelines, bulk-load utilities, and automated validation checks.

Parallel generation & idempotent seeds

• Use deterministic RNG seeded per shard so runs are repeatable (idempotent). Seed = global_seed + shard_id.
• Split work by primary key range or partition key to generate concurrently across processes or Kubernetes jobs.
• Example (Python multiprocessing):

# python
import random, csv
def gen_shard(shard_id, rows, seed, out):
    r = random.Random(seed + shard_id)
    with open(out, 'w') as f:
        w = csv.writer(f)
        for i in range(rows):
            w.writerow([shard_id*rows + i, r.randint(1,100), r.random()])

Bulk load utilities

• Use DB-specific fast loaders: PostgreSQL COPY, MySQL LOAD DATA INFILE, SQL Server bcp/BULK INSERT, or cloud import (BigQuery load jobs, Snowflake COPY).
• Load compressed Parquet/CSV in parallel into partitions to minimize transaction overhead.

Validation of distributions

• Pre-define target distributions (uniform, zipf, categorical probabilities).
• Validate with automated checks: counts per bucket, chi-square test, KS test for continuous values, sample histograms, null rates, referential integrity.
• Run lightweight SQL aggregation queries post-load and compare against expected tolerance thresholds; fail pipeline if outside bounds.

Tooling & infra

• Use Spark or multiprocessing for generation >10M rows.
• Store seeds/metadata in Git and CI so generation is reproducible.
• Integrate into CI/CD to create/tear down test data environments.

Trade-offs

• CSV simple but bulky; Parquet better for cloud/batch.
• Bulk load requires careful batching and constraint management (disable FKs/indexes during load, re-enable/validate after).

Direct answer

The partnerships that pay off under deadline pressure are almost never built in the moment you need them. They come from investing time in a working relationship with a team before there's a specific ask attached, understanding their priorities and vocabulary well enough that when you do need something urgent, they already trust your judgment and don't need to re-derive context from scratch.

Structured elaboration

1. Choose deliberately where to invest. You can't build deep relationships with every team you might someday depend on. Invest ahead of need in the teams whose dependencies are likely to become recurring or critical-path (on the chain of dependent work that directly determines a deadline), based on how your roadmap or their roadmap is shaping up.
2. Invest with no immediate ask attached. Show up to their planning or triage occasionally, offer help on something low-stakes, or spend time understanding how they prioritize their own queue. The absence of a request is what makes it relationship-building rather than a transaction.
3. Learn their vocabulary and criteria, not just their org chart. Knowing how a team actually decides what's urgent (their SLA, or service level agreement, tiers, meaning their committed response and turnaround times, and their escalation triggers) is what lets you frame a future ask in terms they'll immediately recognize as legitimate.
4. Share your own context too. A partnership that pays off later is two-directional: they should understand your team's constraints and cadence well enough that an urgent ask from you doesn't sound out of character.
5. When the moment comes, lean on the relationship, not authority. The payoff isn't that they're obligated to help, it's that they already trust your scoping and don't need to independently verify the ask is real before acting on it.

Worked example

As a backend engineer, I noticed my team periodically needed fast turnaround from the support team but had no real relationship with them beyond ticket queues. Over a few months, with no active request pending, I started sitting in on their triage session once a month, just listening and asking questions about how they decided what jumped the queue. In one of those sessions I noticed a complaint that kept resurfacing: a specific error support couldn't explain, so they were closing the tickets as "can't reproduce." I flagged it to the engineer on our side who owned that area, and made sure support knew we were looking into it even though nothing was urgent yet.

Months later, that same underlying issue caused a customer escalation with a tight deadline attached. I reached out directly to the support lead I'd built rapport with, framed the ask using the same triage language they used internally, and was specific about why it was time-sensitive. Because they already trusted that I didn't cry wolf and that my scoping was accurate, they fast-tracked the escalation ahead of their standard queue without needing the usual back-and-forth to validate it was real.

(Swap the domains freely: the same pattern works with a platform team, a design team, or a data team in place of support, as long as the investment happens before there's an active ask.)

Trade-offs & pitfalls

• Pitfall: relationship-building that's transparently transactional (showing up only when you're about to need something) reads as insincere and doesn't produce the trust you're after.
• Pitfall: investing broadly and shallowly across every team instead of selectively where dependencies are likely to matter. That spreads your own team's time thin for little return.
• Pitfall: treating the payoff as owed. A relationship earns goodwill; it doesn't guarantee compliance, and presuming it does damages the very trust you built.
• Senior differentiator: recognizing which dependencies are likely to become critical-path before they do, and investing ahead of the need rather than starting the relationship the day you first need a favor.

Direct answer. Applying DRY concretely means extracting the repeated login steps (find username field, type it, find password field, type it, click submit) into one parameterized login_as(driver, username, password) function that every test calls, instead of each test repeating those same lines with slightly different literal values.

Structured elaboration, three concrete examples:

1. Helpers: login_as(driver, user, pw) replaces three copy-pasted lines in every test that needs a logged-in session.
2. Fixtures: a logged_in_session fixture built on top of login_as, so tests that just need "an already-authenticated driver" don't even call the helper explicitly.
3. Factories: a make_user(role="admin") factory pairs with login_as so a test can request "a logged-in admin" in one line rather than hand-assembling credentials and then logging in.

Worked example. Executed in this session (Python, fake DOM double):

class FakeElement:
    def __init__(self):
        self.value = None
        self.clicked = False
    def send_keys(self, value):
        self.value = value
    def click(self):
        self.clicked = True

class FakeDriver:
    """Fake DOM double: enough of a browser to exercise real control flow."""
    def __init__(self):
        self._dom = {"#user": FakeElement(), "#pass": FakeElement(), "#login-btn": FakeElement()}
        self.logged_in = False
    def find(self, selector):
        return self._dom[selector]
    def _attempt_login(self):
        self.logged_in = (self._dom["#user"].value == "alice"
                           and self._dom["#pass"].value == "s3cr3t"
                           and self._dom["#login-btn"].clicked)

# BEFORE: the same three lines duplicated in every test that needs a session
def before_test_view_dashboard(driver):
    driver.find("#user").send_keys("alice")
    driver.find("#pass").send_keys("s3cr3t")
    driver.find("#login-btn").click()
    driver._attempt_login()
    return driver.logged_in

# AFTER: one helper, parameterized, used everywhere
def login_as(driver, username, password):
    driver.find("#user").send_keys(username)
    driver.find("#pass").send_keys(password)
    driver.find("#login-btn").click()
    driver._attempt_login()
    return driver.logged_in

def after_test_view_dashboard(driver):
    return login_as(driver, "alice", "s3cr3t")

# The over-abstraction pitfall: login AND navigate AND seed-data behind one opaque call
def over_abstracted_setup(driver):
    login_ok = login_as(driver, "alice", "s3cr3t")
    navigated = True       # pretend navigation happened
    seeded = False          # pretend the data-seed step silently failed
    if not (login_ok and navigated and seeded):
        return "opaque combined state, cannot tell what failed"
    return "setup ok"

before_result = before_test_view_dashboard(FakeDriver())
after_result = after_test_view_dashboard(FakeDriver())
print(f"BEFORE (3 duplicated lines x N tests) and AFTER (login_as(driver, user, pw)) "
      f"both log in successfully: before={before_result} after={after_result}")

print("over_abstracted_setup() result:", repr(over_abstracted_setup(FakeDriver())))

Actual output:

BEFORE (3 duplicated lines x N tests) and AFTER (login_as(driver, user, pw)) both log in successfully: before=True after=True
over_abstracted_setup() result: 'opaque combined state, cannot tell what failed'

This confirms the extraction preserves behavior exactly while collapsing the duplicated lines to one call site per test.

Trade-offs and pitfalls. The over-abstraction line is close: a demonstrated failure mode is a helper that starts doing "login AND navigate AND seed data" behind one opaque call - the executed pitfall demo shows this concretely: over_abstracted_setup() combines three responsibilities behind one function, and its own output ("opaque combined state, cannot tell what failed") is the actual, honest limitation of going one step too far - a test using it that fails cannot tell you whether login, navigation, or the data seed was the actual problem.

Direct answer
When a postmortem produces more action items than the team can implement soon, prioritize using a small set of explicit criteria rather than gut feel: expected reduction in likelihood or blast radius of recurrence, implementation effort, whether the item is a quick mitigation versus a deeper systemic fix, and dependencies between items. Make the criteria and the resulting order visible to stakeholders rather than deciding quietly, since the trade-offs being made are legitimate business decisions, not just engineering housekeeping.

Structured elaboration
A practical framework: score each action item on (1) risk reduction, how much it lowers the chance or impact of recurrence, (2) effort, roughly how much engineering time it needs, (3) urgency, whether related incidents are already recurring or a related SLO is close to breach, and (4) dependencies, whether it blocks or is blocked by other items. High risk-reduction, low-effort items go first almost automatically. High risk-reduction, high-effort items get scheduled deliberately into a near-term roadmap rather than deferred indefinitely, since these are usually the systemic fixes that actually stop the incident class from recurring. Low risk-reduction items, however well-intentioned, get explicitly deprioritized or dropped rather than left open forever accumulating as unaddressed debt nobody looks at again.

Communicating this to stakeholders matters as much as the framework itself: present the ranked list with the reasoning, not just the outcome, so a product or business stakeholder understands why a lower-effort item shipped before a higher-impact one that needed more time, and can weigh in if they disagree with the trade-off.

Worked example
A postmortem for a payments-processing outage produces five action items: (1) add a canary stage to the deploy pipeline for this service, medium effort, high risk reduction; (2) fix a specific null-pointer bug that triggered this incident, low effort, low risk reduction since it only prevents this exact trigger; (3) build a full chaos-engineering test suite for the payments stack, very high effort, high risk reduction but slow to deliver; (4) update the on-call runbook with a faster rollback procedure, low effort, medium risk reduction; (5) rewrite the payments service in a different language for 'long-term resilience,' very high effort, speculative risk reduction. A reasonable prioritization: (2) and (4) ship this week since they are cheap and net-positive even though their impact is modest; (1) gets scheduled into the next sprint as the highest-value item that's actually achievable soon; (3) gets scoped and put on a quarterly roadmap rather than blocking anything else; (5) gets explicitly declined with a documented reason, since its risk-reduction claim is speculative relative to its cost.

Trade-offs and pitfalls
The most common failure is treating every action item as equally mandatory because it came out of a postmortem, which either overloads the team or causes items to silently rot unimplemented. The second most common failure is prioritizing purely by effort (cheapest first) without weighing risk reduction, which ships a lot of low-value busywork while the systemic fix that would actually prevent recurrence keeps slipping.

Direct answer
Open the file using your language's scoped resource-management construct (Python's with, Java's try-with-resources), read the lines, and let that construct guarantee the file handle closes when the block exits, whether it exits normally or because an exception was raised partway through, then handle a missing file and a permissions error as distinct, expected outcomes rather than letting either crash the caller.

Structured elaboration

• Why a scoped construct instead of manual open/close: if you close the file with an ordinary line of code after the read, an exception raised during the read skips that line entirely and the handle leaks (file descriptors are a finite OS resource; leaking enough of them eventually breaks the whole process, not just this call). with/try-with-resources are sugar over exactly the try/finally pattern from the try/except/finally discussion: the close happens in the equivalent of a finally block, so it runs on every exit path, success, expected error, or unexpected error.
• Handling a missing file: catch the specific exception the platform raises for this (Python's FileNotFoundError, Java's NoSuchFileException/FileNotFoundException), and decide deliberately what the caller should see, an empty result, a re-raised application-specific error, or propagation, rather than letting a generic exception surface with no context about which file or why.
• Handling a permissions error: similarly catch PermissionError (Python) / the platform equivalent specifically, this is a genuinely different failure mode from 'file doesn't exist' (the caller might want to alert an operator rather than silently treat it as an empty result) and conflating the two loses information a caller might need to act correctly.
• Why relying on garbage collection to eventually close the handle is not good enough: even in a garbage-collected language, GC timing is not guaranteed or immediate, an unclosed handle can sit open for an unpredictable amount of time (or effectively forever, if something keeps a reference alive), during which it holds an OS resource and, for a file opened for writing, may leave buffered data unflushed. The scoped construct closes deterministically at a known point in the code, GC-triggered cleanup does not.

Worked example

def read_lines(path):
    try:
        with open(path, 'r') as f:
            return f.readlines()
    except FileNotFoundError:
        print(f"file not found: {path}, returning empty list")
        return []
    except PermissionError:
        print(f"permission denied: {path}, returning empty list")
        return []

Verified by execution: reading an existing file with lines "line1\n", "line2\n", "line3\n" returns exactly ['line1\n', 'line2\n', 'line3\n']; calling it on a path that doesn't exist returns [] without raising. A separate check confirmed the resource-closing guarantee specifically: wrapping a file object so that reading it raises mid-operation, and confirming the wrapper's close() still ran (wrapper.closed was True) even though the read itself failed, exactly the guarantee with/try-with-resources provides. The equivalent in Java is try (BufferedReader r = new BufferedReader(new FileReader(path))) { ... }, the resource declared in the try (...) parentheses is closed automatically when the block exits, by any path.

Trade-offs & pitfalls
The choice to return an empty list versus re-raising an application-specific exception on a missing/unreadable file is a real design decision, not a default: returning empty silently is convenient for the caller but can hide a real problem (a misconfigured path, a permissions regression) behind what looks like 'the file was just empty'. Whichever you choose, do it deliberately and log enough context (the path, the specific exception) that a missing file and a permissions problem are distinguishable in your logs even if the function's return type can't distinguish them for the caller.

Direct answer

Owning a service, feature, or process means being the person accountable for whether it keeps meeting its bar over time, not just the last person who touched it, and the way to prove that is a small set of metrics that would actually catch a "fixed but not really fixed" problem, not just activity counts.

Structured elaboration

Four metrics, each with why it matters, how to track it, and how to balance short-term fixes against longer-term investment:

1. Recurrence rate: the share of issues that reopen or repeat the same root cause within a rolling window (for example thirty days). Why it matters: it is the clearest signal that a fix actually solved the problem instead of patching the symptom. How to track it: tag each fix as "same root cause as a prior fix" and review the tagged share over the rolling window rather than judging from memory. Balance: a fast patch under deadline pressure is fine as long as time is later budgeted for the real fix; if recurrence is not trending down over a couple of quarters, the patches have quietly become the standard.
2. Turnaround time: the time from a request or defect report to a verified resolution. Why it matters: it shows whether ownership translates into predictable delivery for the people depending on the work. How to track it: timestamp the first ask and the verified fix, and look at the median across a period, not isolated examples. Balance: driving this number down by skipping root-cause work buys speed today at the cost of the recurrence-rate metric above, so read the two together rather than optimizing either alone.
3. Stakeholder-reported trust: a short, recurring check with the people who depend on the area (a quick "did this meet what you needed" question logged over time, not just anecdote). Why it matters: the other two numbers can look good while the people relying on the work still do not trust it. How to track it: log the answer each period and review the trend quarterly. Balance: a fast tactical fix earns short-term goodwill, but if it is not backed by real improvement in recurrence and turnaround, trust erodes later; treat this as a cross-check, not a target to chase on its own.
4. Self-initiated improvement share: the proportion of changes to the area that nobody had to request. Why it matters: real ownership includes catching problems before they become someone else's escalation. How to track it: keep a simple running log of self-initiated versus requested changes. Balance: the goal is not maximizing this ratio, since too much self-initiated work while the requested queue backs up is its own failure; the goal is making sure it is non-zero and proportionate to actual capacity.

Worked example

Picture a rolling quarter where recurrence sits at eighteen percent at the start. A round of quick patches under a deadline keeps turnaround fast but recurrence rises to about twenty-five percent by the second month, a warning sign the balance has tipped too far toward patching. Trust checks that quarter come back mixed, several stakeholders note they are "not fully confident numbers stay fixed." That combination, rising recurrence plus softening trust, is what justifies spending the next month on the underlying fix rather than another patch, even though it slows turnaround for a few weeks. By the following quarter recurrence needs to be heading back down, not just turnaround looking good in isolation, before the investment counts as having paid off.

Trade-offs and pitfalls

Metrics can be gamed: closing requests fast to win the turnaround number while recurrence quietly climbs is the most common failure. Tracking can also become its own burden; if measuring ownership takes more time than practicing it, simplify the tracking, not the ownership. And metrics should reflect the actual bar for the area, not whatever happens to be easiest to count, a service can look healthy on paper while the thing people actually care about goes unmeasured.

Brief definition

• presence_of_element_located: element exists in the DOM (may be hidden or off-screen). Use when you only need the element node to exist (e.g., verifying an element was injected or reading an attribute).
• visibility_of_element_located: element exists and has non-zero size and CSS visibility/display allowing user see it. Use when you need to assert text is readable or take a screenshot.
• element_to_be_clickable: element is visible and enabled (clickable). It combines visibility plus enabled state/accepting clicks.

Concrete examples

• presence_of_element_located: waiting for a row to be added to a table backend renders first, then you parse its data attribute.
• visibility_of_element_located: waiting for a modal header text to appear before asserting its content.
• element_to_be_clickable: waiting for a submit button that becomes enabled after form validation before clicking.

Failure modes if chosen wrong

• Using presence when element is hidden → your test may try to read text and get empty/blank results or stale interactions.
• Using visibility when element is present but off-screen or still animating → timingouts or flakiness if you expected immediate DOM presence.
• Using clickable when element is visible but covered by an overlay or disabled → Selenium click throws ElementClickInterceptedException or ElementNotInteractableException.

As an SDET I pick the strictest condition that matches the intended action (read vs. see vs. click) to reduce flakiness.

Direct answer
Open by telling the audience what you're going to cover and why it matters to them, signpost explicitly as you move between sections so they always know where they are, and close by restating the key takeaway rather than just stopping.

Structured elaboration

• Opening: state the topic, why the audience should care (what decision or understanding this affects them), and a brief roadmap of the two or three things you'll cover, in that order. This gives the audience a mental outline to hang the rest of the talk on.
• Signposting as you move through it: explicit verbal markers like "that's the background, now let's get into the actual recommendation" or "second point: ..." help a listener track structure that they can't see the way they could see slide headers or section breaks in a document.
• Body: cover the roadmap items in the order you promised; if you need to deviate, say so explicitly ("I said I'd cover three things, but I want to spend more time on the second one because it's the crux") rather than silently reordering.
• Closing: restate the single most important takeaway in one sentence, ideally the same conclusion you'd have led with in a BLUF-style (bottom-line-up-front) written summary. A talk that just trails off after the last data point leaves the audience to guess what they were supposed to walk away with.
• Time-boxing: decide roughly how much time each section deserves before you start, so the most important section doesn't get squeezed by running long on an earlier one.

Worked example
Opening: "Today I want to cover why our checkout conversion dropped last month, what we found, and what we're proposing to fix it. I'll spend most of the time on the fix, since that's the decision we need from this meeting."

Signposting mid-talk: "That covers the three causes we found. Now, the part that actually needs a decision from you: two options for the fix."

Closing: "So the recommendation is option two: it costs more upfront but avoids the recurring risk we saw with option one. That's the decision I'd like from this meeting."

Each of these three lines exists purely to orient the listener to structure, not to add new content.

Trade-offs and pitfalls

• A talk with too many signposts can feel mechanical; use them at genuine transition points, not after every sentence.
• Promising a roadmap and then not following it (skipping a promised section, or spending disproportionate time on something you said would be brief) breaks the audience's trust in your structure and makes them stop tracking it.
• For a very short talk (under two minutes), an explicit roadmap can eat too much of the available time; at that length, the opening and closing can collapse into a single BLUF-style sentence instead of a separate roadmap plus takeaway.

Common causes of drift

• Manual changes made on VMs/containers for quick fixes
• Divergent base images, OS patches, or package versions
• Environment-specific configuration (secrets, feature flags) updated outside IaC
• Missing/partial automation for test fleet provisioning
• Inconsistent test data or DB schema migrations applied unevenly

Four practical guardrails (SDET perspective)

1. Enforce Desired State with IaC and immutable images
   • Use Terraform/CloudFormation + Packer -> bake test images so environments are provisioned identically. Prevents ad-hoc changes.
2. Policy-as-code and pre-merge checks
   • Run Checkov/OPA/Rego and tflint in CI to block non-compliant changes and ensure drift-safe configs before deployment.
3. Continuous drift detection and reconciliation
   • Schedule periodic audits with HashiCorp Sentinel/terraform plan drift detects or use AWS Config/Google Config Controller; reconcile with automated playbooks (Ansible/Chef) or re-provision immutable images.
4. Read-only runbooks, RBAC, and automated remediation
   • Lock access (IAM), require change requests, and implement auto-remediation via GitOps (Argo CD/Flux) so the git repo is the single source of truth.

Tools & processes for detection/reconciliation

• Detection: AWS Config, Azure Policy, terraform plan/refresh, Inspec, OpenSCAP
• Reconciliation: GitOps (Argo CD/Flux), HashiCorp Terraform apply pipelines, Ansible playbooks, auto-image rebuilds with Packer
• Observability: Prometheus + Grafana for config-metric alerts, audit logs for manual changes

These steps ensure reproducibility by treating environments as code, preventing manual divergence, continuously detecting drift, and automating safe reconciliation.

Direct answer

Parsing newline-delimited JSON test-event logs and classifying failures means processing one line at a time (never assuming the whole file is one JSON document), defensively handling malformed lines rather than letting one bad line abort the whole run, and classifying each failure by matching its error message against known patterns for the target categories (assertion, timeout, network, dependency).

Structured elaboration

Per-line processing: each line is parsed independently as its own JSON object; a line that fails to parse, or is missing a required field like job_id, is counted as malformed and skipped, rather than raising an exception that aborts processing of every subsequent line.

Classification approach: a simple, explainable keyword-matching classifier checks the error message for characteristic substrings ("timeout"/"timed out" for timeouts, "connection"/"refused"/"socket" for network issues, known import-error phrases for dependency issues, and "assert" as a fallback signal for assertion failures), falling back to an "other" bucket for anything that doesn't match a known pattern rather than forcing every failure into one of the four named categories.

Aggregation: group events by job_id, tracking a running failure count and a per-category tally, plus a median duration computed from all durations seen for that job (using the standard-library median function rather than hand-rolling percentile logic).

Worked example

```python
def classify_failure(error_message):
msg = (error_message or "").lower()
if "timeout" in msg or "timed out" in msg: return "timeout"
if "connection" in msg or "socket" in msg or "refused" in msg: return "network"
if "modulenotfounderror" in msg or "importerror" in msg: return "dependency"
if "assert" in msg: return "assertion"
return "other"

def parse_ndjson_events(lines):
per_job, malformed = {}, 0
for line in lines:
line = line.strip()
if not line: continue
try:
event = json.loads(line)
except json.JSONDecodeError:
malformed += 1; continue
job_id = event.get("job_id")
if job_id is None:
malformed += 1; continue
bucket = per_job.setdefault(job_id, {"durations": [], "failure_categories": {}, "failure_count": 0})
if isinstance(event.get("duration_ms"), (int, float)):
bucket["durations"].append(event["duration_ms"])
if event.get("status") == "failed":
bucket["failure_count"] += 1
cat = classify_failure(event.get("error_message"))
bucket["failure_categories"][cat] = bucket["failure_categories"].get(cat, 0) + 1
# ... aggregate median_duration_ms per job from bucket["durations"]
```

Verified against a 7-line sample containing one syntactically invalid line and one line missing job_id: the parser correctly reported 2 malformed lines, correctly grouped the remaining 5 events into two jobs, and correctly classified an AssertionError message as "assertion" and a socket.timeout message as "timeout" within the same job, matching hand-computed expected output exactly.

Trade-offs & pitfalls

Substring-based classification is simple and explainable but will misclassify or under-classify an error message phrased differently than the known patterns (a timeout described in wording the classifier doesn't recognize falls into "other" rather than "timeout"); this is an acceptable trade-off for a first version, but the "other" bucket's size over time is itself a useful signal for when the pattern list needs to be extended, and should be monitored rather than ignored as a rounding error.