Comprehensive Interview Preparation Guide: Entry Level SDET at Spotify

Direct answer

I decide who to pull in based on where the evidence points, not on organizational courtesy, and I'd rather pull in one extra team too early and be wrong than wait for certainty and be right too late. Looking back at a specific case, I judged one escalation right and one slightly late, and the late one is the more instructive story.

Structured elaboration

• Deciding who, across teams: escalation isn't "who owns this officially," it's "who has the context or access I don't." I look at the symptom (which system, which layer) and pull in whoever's expertise the current evidence points toward, even if the retrospective later shows it wasn't actually their code.
• Deciding when, under time pressure: I use a rough personal threshold: if I can't form a credible hypothesis within a defined short window, or if the blast radius (how many users or systems are affected) is growing while I investigate, that's the signal to escalate rather than keep digging alone. Waiting for certainty before escalating is itself a decision, just a slower and riskier one.
• The cost asymmetry that should drive the call: escalating and being wrong costs someone else a few minutes of attention. Not escalating and being wrong costs extended user impact. That asymmetry means the bar for escalating should be lower than it instinctively feels under pressure, since the instinct is usually not wanting to page (send an automated on-call alert to) someone for something you might solve yourself.
• Judging it afterward: right, too early, or too late should be assessed against what was knowable at the time, not against what turned out to be true. Pulling in a team that turned out to be unaffected isn't automatically "too early" if the evidence available at that moment reasonably pointed there.

Worked example

During an incident where a service was returning errors for a subset of requests, I initially suspected our own service's recent deploy and pulled in that team's on-call within the first few minutes, which in hindsight was the right call: they were able to quickly confirm or rule out the deploy as cause, and ruling it out fast redirected the investigation instead of costing time. Error rates kept climbing while the deploy theory was being ruled out, and the pattern started looking like it correlated with a specific upstream dependency, a shared caching layer another team owned that stored temporary results so services didn't have to repeat expensive work. I hesitated on pulling that team in for a while, partly because the correlation wasn't yet conclusive and partly, honestly, because I didn't want to page a second team on a hunch that might turn out wrong. When I finally did escalate, they found a change on their side within a few minutes that matched the timeline closely.

Looking back, that second escalation was too late by my own standard: the evidence pointing toward the caching layer had been strong enough to justify pulling that team in noticeably earlier than I did, and the time I spent second-guessing the correlation extended the outage without producing better evidence than what I already had. The lesson wasn't "always escalate instantly," since the first escalation showed that fast, targeted escalation on reasonable evidence works well. It was that my hesitation on the second one came from worrying about being wrong in front of another team, not from the evidence actually being weaker.

Trade-offs and pitfalls

The senior-discriminating mistake here isn't failing to escalate at all, it's the quieter version: escalating on the confident hunch immediately but hesitating on the second, less certain one, because social discomfort about being wrong outweighs the actual cost math in the moment. The trade-off worth naming explicitly is that over-escalating has a real cost too. Constant low-confidence pages erode a team's willingness to respond quickly the next time, so the goal isn't to escalate on everything, but to calibrate the bar honestly to the evidence rather than to your own comfort with looking uncertain.

Direct answer

A test harness running against a staging environment with production-like data needs to be treated as a system with real access to sensitive data, not just a testing convenience, which means enforcing least privilege on what the harness itself can do, masking or synthesizing sensitive fields wherever possible, auditing every destructive operation the harness performs, and having an explicit, tested rollback path for anything the harness might irreversibly change.

Structured elaboration

Data masking. Wherever the staging dataset genuinely needs to resemble production data in shape and volume for a test to be meaningful, sensitive fields (names, emails, payment details) should be masked or synthetically generated rather than being real production values copied verbatim; this bounds the damage of any test-harness bug or credential leak, since there is no real user data to expose in the first place.

Role-based access control, specific to the harness's own service account. The credentials the test harness itself runs as should have the minimum permissions actually required for the tests it runs, not a broad or administrative staging-environment credential reused for convenience; a harness that can only read and write to its own designated test-data namespace cannot accidentally corrupt an unrelated dataset even if a test has a bug.

Ephemeral test accounts. Rather than reusing a small set of long-lived test accounts across many test runs (which accumulate state over time and make one run's leftover data interfere with another's), provision fresh, short-lived accounts per test run (or per test suite invocation) and tear them down afterward, so tests are isolated from each other's side effects and a compromised or leaked test-account credential has a short useful lifetime.

Audit logging. Every destructive or data-modifying action the harness performs (not just failures) should be logged with enough detail to reconstruct what happened, distinctly from the application's own normal audit trail, so that if something goes wrong (an unexpected dataset corruption is discovered later), there is a clear record of exactly which test run did what and when, rather than an ambiguous "something touched this data at some point".

Rollback strategies for destructive operations. Any test that intentionally deletes or mutates data as part of exercising a destructive code path (testing an actual delete-account flow, for example) needs a tested rollback or restoration mechanism, verified BEFORE it's relied on in a real run, not assumed to work the first time it's actually needed; a snapshot-and-restore of the affected data specifically, taken immediately before the destructive test runs, is a common, reliable approach.

Worked example

A test suite exercises an account-deletion flow against a staging environment seeded with a seeded, production-scale, but fully SYNTHETIC dataset (no real user data at all, generated to match production's shape and volume for the specific purpose of realistic-scale testing). Each test run provisions a fresh, ephemeral service account scoped only to the specific test-data namespace it needs, runs the deletion test, logs the specific account ID deleted and the test run ID that performed it to a dedicated test-audit log, and tears down the ephemeral account regardless of whether the test passed or failed. Because the underlying dataset is synthetic rather than real, a bug in the harness that accidentally deletes more than intended is a data-hygiene problem to fix, not a real user's data being lost, and the namespace-scoped credentials mean the bug's blast radius cannot extend beyond that one test-data namespace even if the harness itself is compromised.

Trade-offs and pitfalls

Fully synthetic data is safer but is not always realistic enough to catch every bug that using real (masked) production data would surface, particularly for classes of bugs that depend on genuine data messiness (unusual real-world character encodings, actually-occurring edge-case combinations of fields) that synthetic generation may not reproduce faithfully; the right calibration depends on what class of bug the specific test suite is trying to catch, and some organizations use masked-but-real data specifically for this reason, accepting the additional masking discipline that requires. The most common and costly mistake is a test harness reusing broad, long-lived, highly-privileged staging credentials "because it's just staging", which is precisely the assumption that turns a harness bug into an incident affecting far more of the staging environment (and, if staging and production share any infrastructure or credentials by accident, potentially production itself) than the specific test ever needed to touch.

Overview (SDET perspective)
I’d deliver an automated, repeatable pipeline that produces privacy-compliant test datasets using configurable masking and pseudonymization modules, integrated into CI/CD so QA can generate safe snapshots on demand.

Techniques

• Irreversible masking: deterministic salted hashing or format-preserving encryption (FPE) stripped of key; for emails use hash + “@example.test”. Use one-way bcrypt/sha256(salt + value) when uniqueness not needed.
• Reversible pseudonymization: encrypt with KMS-backed keys (AES-GCM) and store key metadata separately. Provide a secure service to re-identify under approval.
• Referential integrity: maintain mapping tables (original_id → masked_id) generated atomically; apply same mapping across tables during ETL so FK relationships preserve. Use deterministic transforms where appropriate.

Complex types

• Free-text: NLP redaction pipeline — detect PII via regex + ML NER (names, phones) and replace with placeholders (e.g., [NAME_1]). Keep contextual tokens for realistic tests.
• Embedded JSON: recursively traverse and mask fields based on schema; for unknown fields apply conservative redaction.

Validation & Risk Detection

• Automated checks: uniqueness ratios, entropy, k-anonymity sampling, detect leaked quasi-identifiers combining fields. Run synthetic attack simulations (linkage to public datasets). Produce risk score and fail pipeline if above threshold.

Governance

• Simple approval model: dataset requester -> automated risk report -> data steward review -> short-lived credentials for reversible keys. Log all actions, require quarterly audits.

Automation notes

• Implement as test fixtures and CLI tools; integrate into CI to automatically create/validate datasets before test runs.

Overview (goal)
I would deliver a six‑month rehabilitation that combines immediate stabilizers with platform work to make quality sustainable: restore fast feedback, reduce flakiness, raise confidence, then invest in architecture, tooling, and culture so quality is owned across teams.

Month-by-month / Sprint milestones (2-week sprints)

• Sprint 0 (week 0–2): Triage & baseline — run entire suite, categorize failures (flaky, slow, genuine), measure baseline metrics, quick triage board.
• Month 1 (sprints 1–2): Quick wins — quarantine flaky tests, add tags, fix top 20% of tests causing 80% of failures, introduce parallel CI jobs for smoke tests.
• Month 2 (sprints 3–4): Reliability foundation — introduce retry limits, test isolation rules, stabilize environment (test data, mocks), add deterministic seeds.
• Month 3 (sprints 5–6): Performance work — split slow suites, add focused unit/integration/smoke gates, implement test impact analysis to run only affected tests.
• Month 4 (sprints 7–8): Framework & infra — standardize fixtures, centralize helpers, add observability (test timing, failure reasons), improve CI resource scaling.
• Month 5 (sprints 9–10): Preventative tooling — flake detector, quarantine automation, pre-commit hooks, gating in PRs, dashboarding.
• Month 6 (sprints 11–12): Handoff & governance — define SLAs, owner rotations, runbook, training, embed quality KPIs in sprint rituals.

Metrics to track (weekly & dashboarded)

• Flakiness rate (tests with nondeterministic outcomes)
• Mean time to repair (MTTR) per flaky test
• Suite runtime and median CI feedback time
• Test pass rate on PRs and master
• Test coverage of critical flows (end-to-end acceptance)
• Number of quarantined tests vs fixed

Guardrails to prevent regressions

• Fail build on new flaky tests > threshold; auto-quarantine after N intermittent failures
• PR gating: critical smoke must pass within X minutes before merge
• Enforce test ownership label and SLA to address quarantined tests within 2 sprints
• CI quotas to prevent silent bypasses (no blanket “force merge” without QA sign-off)

Incentives & cultural changes

• Make quality part of sprint goals; tie small bonuses/recognition to reducing flake and MTTR
• Create “test champions” rotation across squads; run biweekly lightning demos of fixes/tools
• Pairing sessions: dev + SDET to write stable tests; treat test code reviews like production code reviews
• Training & office hours for best practices (fixtures, mocks, determinism)

Communication plan

• Weekly status email and dashboard link to engineering leadership with top 5 regressions and progress vs KPIs
• Biweekly stakeholder demo (working CI, flake reductions, time-to-feedback improvements)
• Runbook + FAQ in central wiki; announce major changes in sprint planning and Slack #quality with automatic posts from CI

Why this works
Quick wins restore trust (visible reductions in flakes and faster feedback). Parallel longer investments reduce maintenance cost and embed ownership so quality stays stable. Metrics, guardrails, and communication ensure transparency and continuous improvement.

Situation & goal
As an SDET I'd reduce developer distrust by making flaky detection automatic, visible, and actionable so flaky failures are triaged, fixed, or quarantined quickly.

Detection

• Add a flaky-detector in CI that records test outcomes across N runs and flags tests with non-deterministic pass/fail patterns (e.g., >3 failures across 10 runs or >X% variance).
• Capture environment, node, timestamps, and stack traces for every failure.

Automatic reruns & quarantine

• Implement conservative auto-retry: on first failure, re-run test up to 2 times on a fresh worker. If any retry passes, mark the run “flaky” (not blocking) and record metrics.
• If a test hits flaky criteria, automatically move it to a quarantined “flaky” pipeline so it doesn’t fail nightly gating builds.

Ownership & workflow

• Require test metadata with an owner (git blame + test annotation). When a test is quarantined, notify owner and open a lightweight ticket in the issue tracker with failure artifacts.
• If owner absent, assign to platform/SDET rotation.

Instrumentation

• Enrich tests with deterministic IDs, enhanced logging, timing, env snapshot, screenshots/recordings for UI tests, and network traces where relevant.
• Store artifacts centrally with links in CI failure.

Long-term root cause

• Triage cadence: daily review of quarantined tests; weekly deep-dive of top flaky tests with developers to identify root cause (race, order dependence, resource limits).
• Classify flakes and add preventive measures: flaky-proofing helpers, better fixtures, timeouts, retries with backoff, or replacing flaky integration tests with contract/unit tests.

Metrics & communication

• Expose dashboard (Grafana) showing flaky-rate, top flaky tests, MTTR, % failing builds blocked by flakes.
• Post daily Slack summary of new quarantines and weekly digest to engineering with action items.
• Track SLA: reduce nightly runs with flake-caused failures from 15% → <5% in 90 days.

This balances short-term reliability (retries, quarantine) with long-term fixes (ownership, instrumentation, triage) and transparent communication so teams regain trust.

Direct answer

A pipeline run can be started by a push to a branch, a pull request being opened or updated, a scheduled (cron) run, a manually-triggered run, a tag or release being created, or a webhook from an external system. Choosing the right trigger for each job is mostly about matching the trigger's latency and cost to what the job is actually protecting.

Structured elaboration

Push/PR triggers give the fastest feedback and are the right choice for anything that should block a merge: build, lint, unit tests, a fast integration-test subset. The main pitfall is redundant runs: if a PR gets three commits pushed in quick succession, naively triggering a full run for each wastes compute and can even produce out-of-order results if an earlier, slower run finishes after a later one. The fix is to cancel superseded in-progress runs for the same PR/branch and, where the platform supports it, filter by which files actually changed so an unrelated service's pipeline doesn't rebuild for a docs-only change.

Scheduled (cron) triggers are right for work that's too slow or too expensive to run on every PR but still needs to run regularly: a full regression suite overnight, a dependency-vulnerability scan, a long-running performance benchmark. The pitfall is scheduling collisions and thundering-herd load if many scheduled jobs fire at the same wall-clock time; stagger them.

Manual triggers are right for anything that should never happen accidentally: promoting a build to production, running a destructive migration, kicking off an expensive one-off job. The pitfall is under-using them; requiring a manual trigger for something that should really be automatic (like re-running a known-flaky test) just adds friction without adding safety.

Tag/release triggers are the natural fit for a release pipeline: build and publish only happens when a tag matching a release pattern is pushed, keeping arbitrary main-branch commits from silently becoming release artifacts.

External webhook triggers (an upstream artifact landing in a registry, another repository's pipeline completing) are right for coordinating multi-repository or multi-stage workflows, but they introduce a race-condition risk: if the webhook fires before the upstream artifact is fully committed or replicated, the downstream job can start against incomplete data. Deduplication and idempotency matter here as much as for scheduled jobs.

Worked example

For a typical service: PR-open and PR-synchronize trigger the fast build+lint+unit-test job, with in-progress runs for the same PR cancelled when a new commit arrives. Push to main triggers the same checks plus the full integration suite and, if that passes, an artifact publish. A nightly cron triggers the full end-to-end and performance suite against the latest main. A tag matching v* triggers the release pipeline (build, sign, publish, deploy to staging, wait for manual promotion). A manual trigger, gated by a required approver, promotes a specific already-built artifact from staging to production.

Trade-offs and pitfalls

The most common design mistake is using one trigger type for everything, typically push-triggering the whole pipeline including slow and expensive stages, which either makes every PR painfully slow or trains the team to ignore a chronically-red pipeline. The second most common mistake is failing to handle duplicate/overlapping triggers (multiple pushes to the same PR, a webhook firing twice) with idempotency or deduplication, which either wastes compute or, worse, causes two runs to race and produce an inconsistent result.

Direct answer

Track two running arrays indexed by "how many transactions used so far": buy[j] (best running profit while holding a share, having started the j-th buy) and sell[j] (best running profit while not holding, having completed the j-th sell), and update both for every price in a single left-to-right pass. This is O(n * k) time and O(k) space. There is also a special case: once k is at least n // 2, there can never be more than n // 2 genuinely profitable non-overlapping transactions regardless of how large k is, so the problem collapses to unlimited transactions, solvable greedily in O(n) time by summing every positive day-to-day price increase.

Algorithm

For each day's price, and for each transaction count j from 1 to k:

• buy[j] = max(buy[j], sell[j-1] - price): either keep the best "holding" position already found for the j-th buy, or start a new j-th buy today, financed by whatever profit was banked after the (j-1)-th sell.
• sell[j] = max(sell[j], buy[j] + price): either keep the best "sold" position already found for the j-th sell, or sell today's holding for today's price.

Because buy[j] on the right-hand side is this day's just-updated value, sell[j] on the same day can reflect a buy-and-sell on the same day (a net-zero move, which never hurts an optimal solution since it's equivalent to not trading), while still processing the array in one pass with two length-(k+1) arrays rather than a full 2D table.

def max_profit_k_transactions(prices, k):
    n = len(prices)
    if n == 0 or k == 0:
        return 0

    if k >= n // 2:
        return sum(max(0, prices[i] - prices[i - 1]) for i in range(1, n))

    buy = [float("-inf")] * (k + 1)
    sell = [0] * (k + 1)
    for price in prices:
        for j in range(1, k + 1):
            buy[j] = max(buy[j], sell[j - 1] - price)
            sell[j] = max(sell[j], buy[j] + price)
    return sell[k]

Why k >= n // 2 collapses to unlimited transactions

Every transaction consumes at least 2 distinct days (one buy day, one sell day), and a set of non-overlapping transactions can't reuse a day. So no more than n // 2 transactions can ever be simultaneously "active" in an optimal non-overlapping schedule; once the allowed k reaches that ceiling, the constraint is no longer binding; you may as well capture every single profitable up-move independently, since doing so never uses more than n // 2 actual buy/sell pairs (adjacent up-runs merge into one transaction each) and no constrained schedule can beat the unconstrained greedy optimum.

Worked example

from functools import lru_cache

def max_profit_memoized(prices, k):
    n = len(prices)

    @lru_cache(maxsize=None)
    def rec(day, txns_used, holding):
        if day == n or txns_used == k:
            return 0
        best = rec(day + 1, txns_used, holding)
        if holding:
            best = max(best, prices[day] + rec(day + 1, txns_used + 1, False))
        else:
            best = max(best, -prices[day] + rec(day + 1, txns_used, True))
        return best

    result = rec(0, 0, False)
    rec.cache_clear()
    return result

cases = [
    ([2, 4, 1], 2),
    ([3, 2, 6, 5, 0, 3], 2),
    ([1, 2, 4, 2, 5, 7, 2, 4, 9, 0], 3),
]
for prices, k in cases:
    fast = max_profit_k_transactions(prices, k)
    memoized = max_profit_memoized(prices, k)
    print(f"max_profit_k_transactions({prices}, k={k}) = {fast}  (memoized cross-check: {memoized}, agree: {fast == memoized})")

Output (verified by execution, and cross-checked against an independently-implemented memoized recursion over (day, transactions_used, holding) for every case, a genuinely different formulation, not the same array-DP checked against itself):

max_profit_k_transactions([2, 4, 1], k=2) = 2  (memoized cross-check: 2, agree: True)
max_profit_k_transactions([3, 2, 6, 5, 0, 3], k=2) = 7  (memoized cross-check: 7, agree: True)
max_profit_k_transactions([1, 2, 4, 2, 5, 7, 2, 4, 9, 0], k=3) = 15  (memoized cross-check: 15, agree: True)

For [3, 2, 6, 5, 0, 3] with k=2: the optimal schedule is buy at 2 (index 1), sell at 6 (index 2), profit 4; buy at 0 (index 4), sell at 3 (index 5), profit 3; total 7, using exactly 2 of the allowed 2 transactions, matching the DP's answer. For [1, 2, 4, 2, 5, 7, 2, 4, 9, 0] with k=3: buy 1 sell 4 (profit 3), buy 2 sell 7 (profit 5), buy 2 sell 9 (profit 7), total 15, again using all 3 allowed transactions and matching the largest 3 disjoint up-runs in the sequence.

Trade-offs and pitfalls

• k small vs k large is a genuine complexity cliff, not a smooth trade-off: for small k (say, single or low double digits), O(n*k) is fast and the array-DP above is the right tool. For large k (specifically once k >= n // 2), the same DP still gives the correct answer but does unnecessary work; recognizing and special-casing the collapse to the O(n) greedy is the difference between an interviewer seeing a complete answer and a merely correct-but-naive one.
• Off-by-one in the collapse threshold is a common mistake: it's n // 2, not n / 2 rounded up or n - 1; a schedule needs 2 distinct days per transaction, so n days support at most n // 2 non-overlapping transactions (floor division).
• The buy[j] = sell[j-1] - price recurrence is the crux most people get wrong on their own the first time: it's tempting to write buy[j] - price (buying doesn't "cost" anything against your own already-open position; it should reset from the state before this transaction started, i.e., sell[j-1], the profit banked from the previous, already-closed transaction).
• This is a good example of the topic's own boundary: the natural solution technique here is DP-style state tracking over transaction count, but the practical implementation is two flat arrays updated in a single array pass, not a full 2D recursive table, the same reasoning that keeps Kadane's algorithm and expand-around-center palindrome checks classified as array-manipulation technique rather than routed to a dedicated dynamic-programming topic.

Direct answer
State the purpose of the step, any precondition the reader needs to check first, the exact action to take, and what a correct versus incorrect outcome looks like, so someone with no prior context could follow it safely.

Structured elaboration

1. Purpose: one line on what this step accomplishes and, if relevant, when it's needed, so the reader isn't blindly executing a command without understanding what it's for.
2. Precondition: what needs to be true before this step is safe or correct to run (a specific state, a prior step completed, a specific time window).
3. Exact steps: the literal actions, specific enough that two different people following them would do the identical thing; avoid vague verbs like "check the system" in favor of specifics like "run command X and confirm output shows Y."
4. What to watch for: the signal that tells the reader whether it worked or something's wrong, and what to do in either case, especially for anything that isn't obviously reversible.
5. Scope it to one thing. A documentation entry that tries to cover every possible variation becomes hard to follow; a clear entry for the common case, with a pointer to a separate entry for edge cases, beats one entry trying to do both.

Worked example
"Restarting the cache service on a single node (use when the service is unresponsive but the node itself is healthy). Precondition: confirm via the dashboard that only this one node shows degraded health; if multiple nodes are affected, use the cluster-wide procedure instead, not this one. Steps: 1) drain traffic from the node using the standard drain command, 2) confirm the node shows zero active connections, 3) restart the service, 4) confirm the health check turns green within two minutes. Watch for: if the health check doesn't turn green within five minutes, do not retry the restart; escalate instead, since a repeated restart on an already-failing node can make diagnosis harder."

Each part (purpose, precondition, steps, what to watch for) is present in a few sentences, and the entry is scoped to the single-node case rather than trying to also cover the cluster-wide scenario.

Trade-offs and pitfalls

• Writing a runbook step that assumes context ("just do the usual restart") defeats the purpose; the whole value of documentation is that it works for someone without that context.
• Over-documenting every possible edge case in a single entry makes the common case harder to find; better to keep the common-case entry short and link out to edge cases separately.
• Documentation that isn't kept current is worse than none, because it's actively misleading; a runbook step should be revisited whenever the underlying process changes, not written once and forgotten.

Approach
Build the increment target as two implementations behind the same interface, an unsynchronized version and a synchronized one, then drive both with the same concurrent-increment harness so the harness itself is the reusable test asset, not a one-off script. go test -race (Go's built-in data-race detector, which instruments memory accesses at compile time and flags concurrent unsynchronized accesses to the same memory location) is the mechanism that turns "sometimes wrong" into "always caught," because the final-count assertion alone can pass by luck on a given run even with a real race present.

// counter.go
package counter

import "sync/atomic"

// UnsyncCounter has no synchronization: concurrent Increment calls race.
type UnsyncCounter struct{ n int }

func (c *UnsyncCounter) Increment() { c.n++ }
func (c *UnsyncCounter) Value() int { return c.n }

// AtomicCounter uses atomic.Int64: safe under concurrent Increment calls.
type AtomicCounter struct{ n atomic.Int64 }

func (c *AtomicCounter) Increment() { c.n.Add(1) }
func (c *AtomicCounter) Value() int { return int(c.n.Load()) }

// counter_test.go
package counter

import (
	"sync"
	"testing"
)

const goroutines = 50
const perGoroutine = 1000
const wantTotal = goroutines * perGoroutine // 50000

func TestUnsyncCounter_Increment(t *testing.T) {
	c := &UnsyncCounter{}
	var wg sync.WaitGroup
	wg.Add(goroutines)
	for i := 0; i < goroutines; i++ {
		go func() {
			defer wg.Done()
			for j := 0; j < perGoroutine; j++ {
				c.Increment()
			}
		}()
	}
	wg.Wait()
	if got := c.Value(); got != wantTotal {
		t.Errorf("UnsyncCounter: got %d, want %d (lost %d increments to the race)",
			got, wantTotal, wantTotal-got)
	}
}

func TestAtomicCounter_Increment(t *testing.T) {
	c := &AtomicCounter{}
	var wg sync.WaitGroup
	wg.Add(goroutines)
	for i := 0; i < goroutines; i++ {
		go func() {
			defer wg.Done()
			for j := 0; j < perGoroutine; j++ {
				c.Increment()
			}
		}()
	}
	wg.Wait()
	if got := c.Value(); got != wantTotal {
		t.Errorf("AtomicCounter: got %d, want %d", got, wantTotal)
	}
}

Actual execution results
Running go test -v . (no race flag, functional assertion only) against this exact code: TestUnsyncCounter_Increment failed with counter_test.go:26: UnsyncCounter: got 39081, want 50000 (lost 10919 increments to the race), and TestAtomicCounter_Increment passed. The exact lost-increment count is inherently nondeterministic (it depends on the Go scheduler's actual interleaving that run), so a re-run will not reproduce 10919 exactly, but the failure itself (a final count below 50000) is reliably reproducible in kind on any unsynchronized run with real goroutine contention.

Running go test -race -v .: the race detector printed a WARNING: DATA RACE report identifying two concurrent writes to UnsyncCounter.n at counter.go:10 (the c.n++ line) from two different goroutines both inside Increment, with full stack traces for both racing accesses, then failed the test additionally with race detected during execution of test (that run's final count was 28796 of 50000, again a different nondeterministic value from the same underlying bug). Running go test -race -v -run TestAtomicCounter in isolation passed cleanly with no race warning, confirming atomic.Int64 is race-free under the identical harness.

Key points
The harness intentionally reuses the exact same goroutine-fan-out shape for both implementations so that "which counter is under test" is the only variable, which is what makes the pass/fail contrast meaningful rather than an artifact of a different concurrency pattern. perGoroutine = 1000 is chosen high enough to make interleaving between goroutines during the increment near-certain on this hardware; too low a value can let the naive counter pass by luck even without -race.

Complexity
The increment operation itself is $O(1)$ for both implementations; the harness does $O(\text{goroutines} \times \text{perGoroutine})$ total increments, here $50 \times 1000 = 50000$.

Edge cases
Zero goroutines or zero increments per goroutine (harness must not deadlock on an empty WaitGroup, verified trivially since sync.WaitGroup supports Add(0)); a single goroutine (no actual race possible, both implementations must agree, which serves as a sanity check that the harness's counting logic itself is correct before trusting the concurrent case); and running the race-detected test repeatedly in CI, since a race that is timing-dependent can occasionally NOT trigger the detector's specific warning on a given run even though the underlying bug is always present, which is why CI should run -race on every PR rather than treating a single clean race-detector run as proof of safety.

CI configuration
Run go test -race ./... as a required check on every pull request (not just a nightly job), because a race that doesn't manifest as a wrong final count on a given run can still be flagged by the detector's happens-before analysis even when the visible output looks fine; treat any WARNING: DATA RACE in the output as a build failure regardless of the test's own pass/fail status, since -race failing the test binary already does this by default, and keep -race on for any package containing goroutines, not only ones the team suspects of being unsafe, since the entire value of the detector is catching races nobody suspected.

Trade-offs and pitfalls
The race detector roughly doubles memory use and slows execution meaningfully (Go's own documentation states this, without a specific multiplier claimed here since it is environment- and workload-dependent), which is real cost but not a reason to run it only occasionally: a race is a correctness bug, not a performance regression, and the whole failure mode this task demonstrates is that the plain functional assertion (got != want) can pass on some runs even with the bug present, so relying on it alone gives false confidence. A second pitfall is writing the harness with too few goroutines or too few increments each, which lets a genuinely broken unsynchronized counter pass simply because contention was too rare during that particular run; the fix is not a bigger fixed number but running the concurrent test multiple times in CI (or with -count=N) so an intermittent pass does not get treated as proof of correctness.

Approach (SDET voice)
I design selectors to be stable, readable, and resilient to layout/visual changes. I prefer semantic attributes and layered fallbacks so tests fail for real issues, not UI churn.

5 concrete rules / patterns

1. Prefer stable semantic attributes (primary): use data-test or ARIA attributes.
   css

   [data-test=signup-button]
   

2. Use accessible selectors next: roles/labels visible to assistive tech.
   css

   button[aria-label="Sign up"]
   

3. Prefer IDs/classes only if stable and owned by test/dev contract; avoid styling-only classes.
4. Use component-level anchoring: scope selectors to a unique parent to avoid collisions.
   css

   div[data-test=signup-form] [data-test=submit]
   

5. Fallback: avoid fragile text/XPath; if necessary, use relative XPath tied to semantic attributes, not indices, and add retries/timeouts in framework (not long sleeps).

Selector to avoid (and why)
Avoid brittle indexed XPath that breaks when layout changes:

//div[3]/ul/li[2]/a

Why: depends on DOM order/position, not semantics — extremely flaky as UI evolves.