Prep framework

One reusable method for telling truthful stories, organizing portfolio evidence and reviewing an answer. These are editorial preparation tools, not employer scorecards.

Browse interview guides →
01SCAELE story structureShape one truthful story, then adapt it to the question.
S

Situation

What was happening? Identify the user, the system and the consequence.

C

Constraint

What limited the solution: time, data quality, compatibility, budget or risk?

A

Action

What did you personally decide and do? Explain the alternative you rejected.

E

Evidence

What observation, test, artifact or measured result supports the claim?

L

Lesson

What changed in your understanding? State a limitation without hiding it.

E

Extension

What would you change next time, or under a different constraint?

02Three-column portfolio notesConnect a requirement to evidence and a question to verify.

Requirement or theme

1Language or framework

2Data or reporting

3Integrations or APIs

4Support or reliability

5Collaboration

Evidence you can show

1Small implementation, test and review note

2Query with a clearly defined row grain

3Sequence diagram with timeout and retry paths

4Incident timeline and prevention check

5Truthful project story with your own decision

Assumption to verify

1Version, runtime and code-review expectations

2Timezone, freshness and source ownership

3Source of truth and failure recovery

4Escalation and change-control boundaries

5How the team evaluates a useful outcome

03Review at three levelsCorrectness → operability → communication.
  1. 01

    Correctness

    Does the answer preserve its contract?

    • Exercise empty input, duplicates and boundaries.
    • Check whether the query preserves the intended rows.
    • Name the design’s source of truth.
  2. 02

    Operability

    Can someone run, observe and recover it?

    • Trace a slow or unavailable dependency.
    • Use an identifier to connect logs, requests and data.
    • Describe how stuck work is detected and recovered.
  3. 03

    Communication

    Can another engineer assess your reasoning?

    • State assumptions before solving.
    • Explain the alternative you rejected.
    • Make the claim testable and invite a follow-up.