Skip to content

INTERVIEW.md

Latest commit

 

History

History
111 lines (73 loc) · 4.97 KB

INTERVIEW.md

File metadata and controls

111 lines (73 loc) · 4.97 KB
Raw

Post-Submission Interview Script – Fullstack Developer Challenge

Goal: Verify genuine understanding, surface LLM-assisted submissions, and assess communication. Format: 20–30 minute video call. Share screen of the candidate's own PR.

Opening (2 min)

"Thanks for taking the time. This is a quick walkthrough of your solution — we want to understand your thinking, not interrogate you. Feel free to refer to your code as we go."

Section 1: General process (3–4 min)

Ask these casually, but evaluate carefully:

  1. Commit history probe:

    "I see you committed [X] first and then [Y]. What made you change your approach between commit 2 and commit 3?"

    • Green flag: Specific memory of a mistake or refactor.
    • Red flag: Vagueness, "I just improved it," or reference to a generic AI suggestion.

  2. Tooling probe:

    "Did you use any AI assistants, Copilot, or ChatGPT while working on this?"

    • Acceptable: "Yes, I used it to generate a snippet for the Bloom filter, but I had to debug the hash function."
    • Concerning: "No" when the code is suspiciously perfect, or "Yes, for everything."

  3. Time probe:

    "Roughly how long did each challenge take you? Which one felt hardest?"

    • Green flag: Realistic times, personal struggle narrative.
    • Red flag: Uniform "all took about the same time."

Section 2: Challenge 1 – Stream deduplication (8–10 min)

Navigate to their deduplication code.

Defend the approach

"Walk me through your deduplicateApproximate. Why did you choose this windowing strategy instead of something else?"

Stress test their reasoning

"What happens if windowSize is 1,000 and the stream is actually only 100 items long?" "What if the source yields the same word every second for 24 hours? Does your exact solution degrade gracefully?"

Lateral requirement change

"The ops team says 1 TB is no longer the concern — they want exact deduplication on a 512 MB RAM box. No disk access allowed. What do you tell them?"

  • Expected: Reasonable pushback (exact dedup without disk or sufficient RAM is impossible). Tests honesty, not just coding.

Trapdoor question

"Your exact solution probably uses some kind of disk buffer. Why didn't you just sort the file and remove adjacent duplicates?"

  • Expected: Sorting requires random access or external merge sort; streams are sequential. Tests if they understand their own code.

Section 3: Challenge 2 – Booking schema (5–7 min)

Navigate to their schema and query.

Forensic reasoning

"You identified the junior's flaw. Imagine they come back and say, 'But I checked in the API layer that no other booking exists before saving.' Why is that still broken?"

  • Expected: Race conditions, distributed systems, lack of atomicity. Tests depth.

Constraint change

"Business now wants to allow back-to-back bookings (one ends at 10:00, next starts at 10:00) but still block overlaps. Does your schema/query handle that? Where would it break?"

Alternative evaluation

"If you had to do this with a document database like MongoDB instead of SQL, what's the hardest part to translate?"

Section 4: Challenge 3 – FrontOps (3–5 min)

Navigate to their Dockerfile / deployment description.

Operational reasoning

"Your staging URL changed because we migrated DNS. Show me exactly what your ops colleague changes and where. No code rebuilds allowed."

Versioning scenario

"The API team released /api/v2/. The frontend still calls /api/v1/. You want to let users opt-in gradually without redeploying the container. How does your setup handle that?"

Security check

"How does your runtime config mechanism defend against someone injecting a malicious API_BASE_URL via your config endpoint?"

Closing (2 min)

"Is there anything you ran out of time for, or anything you'd refactor given another hour?"

  • Green flag: Honest self-criticism.
  • Red flag: "No, it's perfect."

Evaluation Matrix

Signal What to look for LLM-aided risk
Commit history Iterative, imperfect, descriptive Squashed, perfect, generic
Code walkthrough Hesitation, personal reasoning, "I tried X and it failed" Smooth, rehearsed, detached
Lateral changes Adaptation, uncertainty, negotiation Blank stare, "I didn't think about that"
Trade-offs Specific sacrifices accepted None mentioned, or vague generics
Honesty about tools Declares AI usage with caveats Denies AI use despite polished submission

Decision Rules

  • Strong hire: Explains own code fluently, commits show organic development, adapts to constraint changes, honest about tools.
  • Hire with coaching: Code works, but reasoning is thin in one area; candidate is transparent about sources of help.
  • Reject / suspicious: Code is sophisticated but candidate cannot explain it, cannot recall commit stages, or refuses to discuss process.