SDET Interview Preparation Guide - Junior Level (FAANG Standards)

Direct answer. Extract the shared setup into a fixture that provides the RESOURCE (a workspace, an environment) but let each test still supply its OWN specific data, so the extraction removes duplicated boilerplate without hiding what each individual test actually depends on.

Before (duplicated setup)

def test_parses_valid_file():
    tmp = tempfile.mkdtemp()
    os.makedirs(os.path.join(tmp, "data"))
    with open(os.path.join(tmp, "data", "a.txt"), "w") as f: f.write("id,value\n1,10\n")
    os.environ["TEST_MODE"] = "1"
    try:
        assert parse_file(os.path.join(tmp, "data", "a.txt")) == [{"id": "1", "value": "10"}]
    finally:
        shutil.rmtree(tmp); os.environ.pop("TEST_MODE", None)

def test_parses_empty_file():
    tmp = tempfile.mkdtemp()   # identical setup duplicated
    os.makedirs(os.path.join(tmp, "data"))
    # ...

After (extracted fixture)

@pytest.fixture
def test_workspace():
    """Extracted shared setup: temp dir + TEST_MODE env var, torn down automatically."""
    tmp = tempfile.mkdtemp()
    data_dir = os.path.join(tmp, "data")
    os.makedirs(data_dir)
    os.environ["TEST_MODE"] = "1"
    yield data_dir
    shutil.rmtree(tmp)
    os.environ.pop("TEST_MODE", None)

def write_csv(dir_, name, content):
    path = os.path.join(dir_, name)
    with open(path, "w") as f: f.write(content)
    return path

def test_parses_valid_file(test_workspace):
    path = write_csv(test_workspace, "a.txt", "id,value\n1,10\n")
    assert parse_file(path) == [{"id": "1", "value": "10"}]

def test_parses_empty_file(test_workspace):
    path = write_csv(test_workspace, "b.txt", "id,value\n")
    assert parse_file(path) == []

Verified: both the original duplicated-setup tests and the fixture-based tests pass (4/4), confirming the extraction preserves identical behavior.

Why this avoids the 'too-generic setup' trap

The fixture provides only the ENVIRONMENT (a temp workspace, the env var) -- the SPECIFIC data each test cares about ("id,value\n1,10\n" vs. an empty file) stays visible right in each test function via write_csv, not buried inside the fixture. A reader looking at test_parses_empty_file can see exactly what makes it different from the valid-file case without opening the fixture at all; if the fixture ALSO decided what data to write, failures would require reading the fixture to understand what's actually being tested.

Trade-offs and pitfalls

• A fixture that grows to accept many parameters to customize its behavior per-test is drifting back toward the same 'god function' problem seen elsewhere -- if that starts happening, it's often a sign the fixture is trying to serve two different needs and should split into two smaller fixtures.
• pytest's automatic teardown (the yield pattern) removes the need for manual try/finally, but the same discipline (isolate one test's state from another's) applies in any test framework, even ones without built-in fixture teardown -- the PRINCIPLE (extract environment, keep data visible) transfers even where the specific mechanism differs.

Direct answer

A concrete story: a service occasionally returned stale pricing data to a subset of users, detected via a customer complaint rather than any internal alert (since the values were plausible-looking, just wrong, not obviously broken); the root cause traced to a caching layer that keyed its cache entries incorrectly, causing two logically-distinct pricing contexts to collide and overwrite each other's cached value, and the permanent fix corrected the cache key's uniqueness rather than just adjusting the cache's expiry time.

Structured elaboration

How it was detected: a customer support ticket reported seeing a price that didn't match what should have applied to their account tier, with no corresponding error or alert on the engineering side, since the returned value was a real, validly-formatted price, just the WRONG one; this is a useful detail because it illustrates a class of bug (returning plausible-but-wrong data) that's structurally invisible to error-rate-based monitoring, and only surfaces via a downstream consumer noticing a substantive discrepancy.

How it was reproduced: confirming the report wasn't a one-off required identifying the PATTERN, not just the single instance; checking whether other users on the same account tier around the same time window also received an unexpected price showed a small but real cluster, ruling out "one weird one-off" and confirming a systemic, reproducible mechanism worth a full investigation.

Debugging tools and techniques used: traced the pricing-lookup code path for the affected requests, and found it flows through an in-memory cache keyed, it turned out, on account tier ALONE rather than on the combination of account tier AND region (pricing legitimately varies by both); when two users on the same tier but different regions made requests close together in time, the second request's result could overwrite the first's cache entry under the shared, insufficiently-specific key, and a THIRD user (same tier, either region) arriving shortly after could then receive whichever region's price happened to be cached most recently, regardless of their own actual region.

The root cause: a cache key that didn't include every dimension the underlying value actually varied by, a classic caching-correctness bug: the cache was implicitly promising "this value is valid for anyone with this tier," when the real invariant needed was "this value is valid for anyone with this tier AND this region."

The permanent fix implemented: updated the cache key to include region alongside tier, restoring the correct invariant; also added a specific integration test that exercises exactly this scenario (two regions, same tier, interleaved requests) to catch a regression of this specific mechanism in the future, since the original bug had shipped without any test covering this particular combination of dimensions.

What you learned that helps you avoid similar bugs: whenever introducing a cache, explicitly enumerate every dimension the cached value can legitimately vary by, and verify the cache key includes ALL of them, not just the ones that happen to be obvious or top-of-mind at implementation time; a caching bug of this shape is especially dangerous specifically because it fails SILENTLY (no error, no crash, just occasionally-wrong data) and is invisible to typical error-rate monitoring, which argues for treating "does this cache key capture every dimension of variation" as a deliberate design-review question on any future caching work, not something to verify only after a bug report arrives.

Trade-offs and pitfalls

The tempting quick fix, once the symptom (stale/wrong cached price) was understood, would have been to simply reduce the cache's TTL (expiry time), which would have reduced the WINDOW during which a collision could produce visibly wrong data without fixing the actual collision mechanism at all; the permanent fix specifically addressed the cache KEY's correctness, not the expiry duration, since a shorter TTL would have masked the bug's visible frequency without removing its root cause.

Direct answer

The number of ways to climb an n-step staircase, taking 1 or 2 steps at a time, satisfies $ways(n) = ways(n-1) + ways(n-2)$ with base cases $ways(0) = 1,\quad ways(1) = 1$: exactly the Fibonacci recurrence. This is a dynamic programming (DP, an algorithm-design technique that solves a problem by combining solutions to overlapping smaller subproblems, storing each result once) problem: solve it iteratively in O(n) time and O(1) space by keeping only the last two values.

Structured elaboration

Recognizing the DP shape before writing code

Three signals in the statement point to DP rather than a search or greedy approach:

• The question asks to count the number of ways, not to produce one path. Counting problems over a sequence of choices are a strong DP tell.
• The number of ways to reach step n depends only on the number of ways to reach step n-1 and step n-2 (you arrived at n either from n-1 with a 1-step move or from n-2 with a 2-step move). That is optimal substructure: the answer for n is built purely from answers to smaller instances.
• If you tried the direct recursive translation of that recurrence, the same subproblem (say, ways(5)) gets recomputed many times as different branches converge on it. That repeated, overlapping recomputation is the second DP hallmark, and it is what memoization or an iterative table removes.

Two ways to compute the same recurrence

This is the same base-case-plus-recurrence shape as the two standard ways of computing a Fibonacci number:

1. Top-down (memoized recursion): recurse naturally, but cache each ways(k) the first time it is computed and return the cached value on repeat calls.
2. Bottom-up (iterative table): start from the base cases and build upward, which lets you discard everything except the last two values since nothing further back is ever needed again.

Worked example

from functools import lru_cache


def climb_stairs_iterative(n: int) -> int:
    """Bottom-up DP: keep only the last two values. O(n) time, O(1) space."""
    if n < 0:
        raise ValueError("n must be non-negative")
    if n <= 1:
        return 1
    prev, curr = 1, 1  # ways(0)=1, ways(1)=1
    for _ in range(2, n + 1):
        prev, curr = curr, prev + curr
    return curr


@lru_cache(maxsize=None)
def climb_stairs_memo(n: int) -> int:
    """Top-down DP: recursion + memo cache. O(n) time, O(n) space (call stack + cache)."""
    if n <= 1:
        return 1
    return climb_stairs_memo(n - 1) + climb_stairs_memo(n - 2)


if __name__ == "__main__":
    for n in [0, 1, 2, 3, 4, 5, 10]:
        it = climb_stairs_iterative(n)
        me = climb_stairs_memo(n)
        assert it == me
        print(f"n={n}: {it}")

Running this prints:

n=0: 1
n=1: 1
n=2: 2
n=3: 3
n=4: 5
n=5: 8
n=10: 89

Trace for n=5 by hand: ways(0)=1, ways(1)=1, ways(2)=1+1=2, ways(3)=2+1=3, ways(4)=3+2=5, ways(5)=5+3=8, matching the printed value.

Complexity

• Iterative (bottom-up): time $O(n)$, space $O(1)$ (two rolling variables).
• Memoized recursion (top-down): time $O(n)$ (each subproblem computed once), space $O(n)$ for the cache plus the recursion call stack.

Edge cases

• n=0 returns 1 (there is exactly one way to be already at the top: do nothing).
• Negative n is invalid input; the iterative version raises rather than silently returning a wrong count.
• Very large n on the memoized version can hit a language's recursion-depth limit even though the iterative version has no such ceiling, since it never recurses.

Trade-offs & pitfalls

The iterative form is the version you want in production: same time complexity as the memoized form but without the call-stack and cache overhead. The memoized form is worth showing once to demonstrate you understand why naive recursion is slow (its unmemoized call tree branches into two children at every level, giving exponential time), but it is not the answer you should ship. A common wrong turn is to stop at "it is Fibonacci" without stating the DP recognition criteria the question explicitly asks for, or to hardcode the base cases as ways(1)=1, ways(2)=2 instead of grounding them at ways(0)=1: both are correct if applied consistently, but mixing the two conventions mid-derivation is a frequent source of off-by-one bugs. For n large enough that even O(n) is too slow (very large n needed for a single query, not many queries), matrix exponentiation gets this down to $O(\log n)$ time by expressing the recurrence as repeated squaring of a 2x2 matrix, at the cost of noticeably more implementation complexity; it is depth beyond what this question requires unless the interviewer explicitly pushes for huge n.

Five test types map to three CI/CD stages, based on how much confidence each buys versus how much time it costs.

Where each type executes, and why

To place the top two rows precisely: a component test differs from a unit test by including a piece's real in-process collaborators instead of mocking everything, and differs from an integration test by still faking anything external like a database or network call.

The underlying trade-off, made explicit

Unit and component tests buy fast, precise confidence about logic, which is why they are the safe types to let block every merge: a false positive is rare and a true positive is almost always worth stopping the merge for. Integration and UI tests buy broader, more realistic confidence, but at meaningfully higher cost and with real risk of flakiness producing false positives, so only a small, carefully curated slice of them should be allowed to block a merge; the rest should run on a slower cadence where a failure gets investigated without holding up unrelated work. Performance tests answer a different question entirely (capacity, not correctness) and are noisy enough commit-to-commit that gating a merge on them directly would produce too many false alarms; they belong in a monitored, threshold-based alerting flow instead.

Trade-offs and pitfalls

The main pitfall is over-blocking: putting the full UI or performance suite in the merge-blocking path "to be safe" reliably backfires, because the resulting slow, occasionally-flaky gate trains developers to rerun blindly or bypass it, which defeats the entire purpose of having a gate. The discipline is choosing a SMALL, high-confidence subset for the blocking path and trusting the rest of the suite, running on a faster feedback loop than "never," to catch what the blocking subset misses.

Direct answer
Precise wording matters because a reader acts on what the words literally say, not on what the writer meant; vague or ambiguous phrasing lets each reader fill in the gap with their own assumption, and those assumptions frequently disagree.

Structured elaboration

• Ambiguity creates silent forks in understanding. Two readers of the same imprecise sentence can each walk away confident they understood it, while holding two different, incompatible interpretations, and neither realizes there's a disagreement until it surfaces later, usually at a worse time.
• Vague quantifiers are a common culprit: words like "soon," "significant," or "most" mean different things to different readers and different things in different contexts.
• Precision does not mean verbosity. A precise sentence can be shorter than a vague one; "by Thursday 5pm" is both more precise and no longer than "soon."
• To enforce more precise terminology: agree on and write down a small shared glossary for terms that get used loosely (what counts as "done," what "urgent" means for this team), review drafts specifically looking for vague quantifiers and ambiguous pronouns ("it," "this") whose referent isn't obvious, and normalize asking "what do you mean by X specifically?" in review rather than letting it pass.

Worked example
Imprecise: "We'll ship the fix soon, once we've done a bit more testing."

What actually happened: one stakeholder read "soon" as "later today" and told a customer to expect it that day; the engineering team read it as "sometime this week" because "a bit more testing" meant a multi-day regression pass. The customer was told an incorrect date because two people read the same sentence and reasonably reached different conclusions.

Precise version: "We'll ship the fix by end of day Thursday, pending a two-day regression test that starts tomorrow."

Same information, but now both readers have the same understanding, and if the regression test finds something, "Thursday" is a concrete promise that either holds or needs an explicit update, rather than a vague one that quietly slips.

Trade-offs and pitfalls

• Being maximally precise about everything is exhausting and unnecessary for low-stakes communication; reserve the rigor for statements other people will act on or make commitments based on.
• Precision can be used dishonestly too, to sound more certain than you actually are; if you genuinely don't know the date, the honest and still precise move is "I don't have a firm date yet, I'll confirm by Wednesday," not a confident-sounding guess.
• Enforcing a shared glossary only works if it's actually referenced in practice, not just written once and forgotten; it needs to show up in review habits, not just documentation.

Direct answer

Genuineness comes from preparing anchors, not sentences: fix on two or three reasons that are actually true for you and one piece of concrete evidence for each, then let the exact wording vary each time you say it out loud. A memorized paragraph is what reads as rehearsed; a stable set of true reasons delivered conversationally does not.

The framework

1. Distill to true anchors: two or three real reasons, stated as short phrases you could reorder, not a scripted paragraph.
2. Attach one piece of evidence per anchor, something you can point to, a project you shipped, a decision you made, a specific artifact (a writeup, a contribution, a tool you built), not just an adjective about your enthusiasm.
3. Practice out loud in varied phrasing (talk it through with a friend, or record yourself once) so the delivery adapts to the actual question asked instead of triggering a memorized block of text.
4. Prepare for the skeptical follow-up. If a panelist pushes back with something like "a lot of candidates say that," the recovery is to go one level more specific, naming the exact detail or artifact behind the claim, not to repeat the same sentence with more emphasis.

Worked example

Anchor: I want to work on problems where the constraint is real users, not a benchmark. Evidence: on my last project I chose to spend extra time on the failure case that affected a small fraction of users because that was the part a benchmark wouldn't have caught. When an interviewer followed up with "a lot of candidates say that, what makes it true for you," I didn't repeat the claim, I walked through the specific failure case and what I changed because of it. That's the difference between an anchor with evidence behind it and a line that just sounds good on its own.

Trade-offs and pitfalls

The failure mode in the other direction is under-preparation: showing up with no anchors at all produces rambling that also reads as unconvincing, just for the opposite reason. The goal is prepared content, delivered unscripted.

Direct answer

Feature flags and canary releases should be treated as an additional testing dimension: your test matrix needs to cover both the flag-on and flag-off code paths explicitly, and a canary environment should validate the flagged behavior with real (limited) traffic before the flag is enabled more broadly, rather than trusting that pre-merge tests alone cover what happens once the flag actually flips in production.

Structured elaboration

• Targeted testing for flag-on vs flag-off: since a feature flag effectively creates two code paths, both need explicit test coverage; the flag-off path is often the existing well-tested behavior, but the flag-on path is new and needs the same rigor, not an afterthought "we'll test it once it's live" mentality.
• Flag matrices in the test matrix: for a feature interacting with multiple existing flags, the combinatorial space can explode; a pragmatic approach tests the flag in isolation (on/off against default other-flag state) plus any known-important flag interactions, rather than attempting exhaustive combinatorial coverage of every flag combination.
• Canary validation of flagged behavior: once code is deployed but before the flag is broadly enabled, the canary stage should specifically validate the flag-on behavior against a small slice of real traffic (or a synthetic slice designed to exercise the new path), checking the same health signals (error rate, latency, business metrics) you'd use for a canary deploy, but scoped to the flag's specific impact.
• Rollout sequencing: a full rollout usually means the flag ramps gradually (0% then a small percentage then more) independent of the deploy itself; the pipeline's job is to make sure each ramp step is validated against real signals before the next ramp step proceeds, similar in spirit to a canary deployment gate but driven by the flag's rollout percentage rather than the deploy's traffic percentage.

Worked example

A new checkout discount feature ships behind a flag, deployed to 100% of instances but initially flagged off everywhere. Pre-merge tests cover both flag states explicitly. Post-deploy, the flag ramps to 1% of traffic; a canary-style check specifically monitors checkout error rate and discount-calculation correctness signals for that 1% slice for a defined bake period before the flag ramps further, with an automatic flag-disable (not a full rollback, since the flag itself is the safety switch) if the signals degrade.

Trade-offs & pitfalls

The common mistake is testing the flag-on path thoroughly pre-merge but never validating it again once real traffic actually exercises it, treating the flag purely as a deployment-safety mechanism rather than also a testing dimension in its own right; without canary-stage validation specifically scoped to the flag, you can ship a flag-on path that passed every pre-merge test but behaves differently under real production conditions.

I would address it privately and early, before frustration turns into teamwide resentment. I would start with a direct but nonjudgmental conversation: "I've noticed a few commitments have slipped, and it's affecting our planning. Is something blocking you?" The point is to understand the cause, not accuse them.

If they are overloaded or unclear on priorities, I would help clarify scope and agree on one realistic next step. I would also ask for smaller, more frequent check-ins so issues surface sooner. If the pattern is about skill or confidence, I would offer support or pair on the hardest part.

At the same time, I would keep the rest of the team informed only at a necessary level, without gossiping or blaming. If the misses continue after a clear conversation, I would bring the facts to the manager in a neutral way: dates, commitments, and impact. That protects the relationship while still protecting the team. The goal is accountability with respect, not public pressure.

For example, say the teammate is Priya, and the missed commitment is the payments-service integration tests: she has said she would finish them by Friday three sprints in a row and hasn't. I would message her directly: "I've noticed the payments-service tests have slipped the last three Fridays. Is something blocking you, or is the estimate off?" Priya explains she has also been pulled into unplanned support tickets and didn't want to flag it. We agree on one realistic next step: she owns just the critical-path test cases by Wednesday and hands the rest to me, and we add a five-minute check-in every Monday and Thursday so a slip surfaces mid-sprint instead of at the deadline. Two sprints later, one of those check-ins catches a new blocker early and the deadline holds.

Direct answer

I evaluate the refactor suggestion on its merits before reacting to the timing pressure: is it solving a real, quantifiable problem, what would it cost in effort and risk, and can I capture most of the benefit through a phased approach that does not gate the release. Then I bring leadership the trade-off explicitly rather than unilaterally deciding to defer it or to blow the deadline.

Structured elaboration

Evaluate necessity and expected ROI (return on investment: what you get back relative to what you put in). I ask what specific pain the current design is causing, recurring bugs, hard onboarding, brittle deploys, an approaching scaling wall, how often that pain actually bites, and what would measurably improve after the refactor. A refactor suggested on stylistic grounds with no quantifiable pain point gets a very different answer than one tied to a recurring production issue.

Estimate effort and risk. I break the refactor into its actual components and estimate each rather than treating it as one opaque blob, then identify the riskiest slice, usually the piece touching the most call sites or the least-tested code path, since that risk, not the total size, is what actually threatens the release timeline.

Propose a phased plan with mitigation and fallback. I split the work into an in-scope slice that addresses the most urgent, best-evidenced piece of the pain without touching the release-critical path, and a deferred slice that happens after the release. I define a fallback explicitly: if the in-scope slice introduces instability close to the release date, what is the rollback path, a revert point or a feature flag.

Communicate trade-offs to leadership. I present it as a real decision with named costs on both sides, ship on time with the refactor deferred and a known, bounded risk still present, versus a short delay that meaningfully reduces that risk, rather than presenting the refactor as unavoidable or dismissing it outright.

Worked example

A peer reviewer flags that the data ingestion pipeline's error handling is inconsistent across three code paths, and suggests a full unifying refactor estimated at three weeks, ten days before release. Evaluating necessity: recent incident history shows two of the three paths caused actual production incidents last quarter; the third has not. ROI: unifying the two higher-risk paths addresses demonstrated pain directly; the third is lower priority. Effort and risk: fixing the two proven paths is estimated at four days, touches a well-tested module, and has existing test coverage; the third path touches a legacy component with thin coverage and is the genuinely risky, three-week piece.

Phased plan: ship the two-path fix now, low risk, addresses proven pain, fits before the release, and defer the third path to the following sprint with a tracked ticket and a temporary compensating control, extra monitoring on that path, in the meantime. Fallback: the two-path fix ships behind existing CI test gates with no flag needed given the coverage, but if a regression appears in staging within 48 hours of the release date, it reverts immediately and ships post-release instead. To leadership: "the reviewer's concern is valid and backed by two real incidents. Fully addressing it as suggested would delay the release; addressing the two proven-risk paths does not, and I will track the third as a fast follow. Here is the fallback if even this smaller piece looks risky closer to the date."

Trade-offs and pitfalls

Treating "a peer review flagged it" as automatically requiring action before the release ignores that timing and severity both matter, not just that a concern was raised. Dismissing a legitimate refactor purely to protect the deadline trades a known, avoidable risk for schedule certainty, and can cost more later. Phasing the refactor means carrying some technical debt a little longer, acceptable when the deferred slice is genuinely the lower-risk one, not acceptable if it is actually the riskiest part being pushed off purely for convenience. Finally, presenting the decision to leadership as already made, rather than as a trade-off they get to weigh in on, is a problem especially when the release date is a business commitment they own, not the engineer's alone.

Direct answer. Sharing utilities, mocks, and fixtures between unit-level tests and higher-level integration/exploratory tests without coupling their LIFECYCLES means the shared code has NO opinion about scope or timing - a shared assertion helper or mock factory is a pure function/class that any caller can invoke at whatever scope IT needs, rather than something built assuming a specific test-level's setup/teardown rhythm.

Structured elaboration.

• What's actually shareable: assertion helpers (pure functions comparing expected vs actual), mock/stub factories (pure constructors of fake objects), and data-generation utilities (pure functions producing test fixtures) - none of these inherently care whether they're invoked once per unit test or once per integration-test session.
• What's NOT shareable without care: lifecycle-bound resources (a database connection, a browser session) - these have a scope (per-test, per-class, per-session) that unit tests and integration tests will usually want DIFFERENTLY (unit tests want a lightweight in-memory fake; integration tests want a real, more expensive resource), so the SHARED utility should accept the resource as a parameter rather than managing its own lifecycle internally.
• Managing dependencies: shared utilities live in their own package/module with their own explicit dependency list (ideally minimal - a shared assertion helper shouldn't drag in a full browser-automation dependency just because SOME callers happen to be UI tests), so a unit test importing it doesn't pull in unrelated heavyweight dependencies.
• Versioning the shared-utilities package itself: publish it as its own semantically-versioned package (MAJOR for a breaking change to a shared helper's signature or return shape, MINOR for a new pure helper added, PATCH for a bug fix), separately from either test level's own code. A unit-test-only consumer pins a version and upgrades on its own schedule, exactly like any other shared-library dependency, so a breaking change to assert_valid_order's signature can't silently break every unit test importing it the next time CI happens to reinstall dependencies - the same deprecation-window discipline (warn for N releases, then remove) applies here as it would to any other shared library.
• Decoupling technique: dependency injection again is the mechanism - a shared assert_valid_order(order, expected) helper takes plain data and asserts on it, usable identically whether order came from an in-memory unit-test fixture or a real API response in an integration test, because the helper itself never manages HOW order was obtained.

Worked example. A concrete shared utility: make_test_order(status="pending", items=None) (a pure factory, no I/O) is used identically by a unit test (constructing an order object entirely in memory to test a pricing function) and an integration test (using the same factory to build the REQUEST BODY sent to a real API endpoint) - the factory has zero knowledge of which context it's being used in, and neither test's lifecycle is coupled to the other's. Both consumers pin test-utils==1.4.*, so a future MAJOR release of test-utils (say, changing make_test_order's default status) requires each consumer to opt in deliberately rather than silently changing behavior underneath already-passing tests.

Trade-offs and pitfalls. The coupling risk shows up subtly: a shared utility that starts pure but gradually accumulates a convenience parameter like also_seed_database=True for integration-test callers has begun coupling its API to one specific test level's needs - the fix is keeping the shared utility strictly about DATA/ASSERTIONS, and letting each test level's own fixture layer handle its own lifecycle-specific setup around that shared, lifecycle-agnostic core.