Table of Contents
- Mock Interview Checklist (Go Backend Loop)
- Timing Guide
- Round 1: Phone Screen
- Round 2: Technical / Coding
- Round 3: System Design
- Round 4: Behavioral
- Red Flags / Green Flags
- Final Debrief
Mock Interview Checklist (Go Backend Loop)¶
A printable, self-contained checklist for running a full mock interview loop. Print it, tick the boxes as you go, and score each round 1-5 using the rubrics.
How to use: Run each round timed. After each round, fill in the rubric and jot one strength and one fix. Total loop time is roughly 3 hours including breaks.
Timing Guide¶
| Round | Duration | Format |
|---|---|---|
| Phone Screen | 30-45 min | Conversational + light coding |
| Technical / Coding | 45-60 min | Live coding, shared editor |
| System Design | 45-60 min | Whiteboard / diagram |
| Behavioral | 30-45 min | STAR storytelling |
| Wrap-up & feedback | 15 min | Debrief and scoring |
Scoring scale (used in every rubric below): 1 = far below bar, 2 = below bar, 3 = at bar, 4 = above bar, 5 = exceptional.
Round 1: Phone Screen¶
- Candidate gave a crisp 60-90s background summary
- Articulated why Go and what they have built with it
- Explained slices vs. arrays and the backing-array gotcha
- Described goroutines and channels at a high level
- Discussed error handling philosophy (errors as values)
- Solved a warm-up problem (e.g., FizzBuzz / string reversal)
- Code compiled and ran; handled an edge case
- Asked at least one thoughtful question about the role
Phone Screen Rubric¶
| Criteria | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| Communication & clarity | ☐ | ☐ | ☐ | ☐ | ☐ |
| Go fundamentals | ☐ | ☐ | ☐ | ☐ | ☐ |
| Warm-up coding | ☐ | ☐ | ☐ | ☐ | ☐ |
| Curiosity / engagement | ☐ | ☐ | ☐ | ☐ | ☐ |
Strength: _______________ Fix: _______________
Round 2: Technical / Coding¶
- Restated the problem and clarified constraints before coding
- Proposed an approach and stated complexity up front
- Wrote idiomatic Go (clear names, early returns,
defer) - Handled errors explicitly; no swallowed
err - Used the right data structures (map/slice/
container/list) - For concurrency: used
context,sync.WaitGroup/errgroup, no leaks - Tested with examples / edge cases; would pass
go test -race - Walked through the code and analyzed time/space complexity
- Responded well to a follow-up extension or optimization
Technical / Coding Rubric¶
| Criteria | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| Problem solving & approach | ☐ | ☐ | ☐ | ☐ | ☐ |
| Idiomatic Go & correctness | ☐ | ☐ | ☐ | ☐ | ☐ |
| Concurrency / error handling | ☐ | ☐ | ☐ | ☐ | ☐ |
| Testing & edge cases | ☐ | ☐ | ☐ | ☐ | ☐ |
| Complexity analysis | ☐ | ☐ | ☐ | ☐ | ☐ |
Strength: _______________ Fix: _______________
Round 3: System Design¶
- Gathered requirements and clarified scope before designing
- Estimated scale (QPS, data size, read/write ratio)
- Defined clear API contracts and data models
- Justified storage choices (SQL vs. NoSQL, caching layer)
- Addressed concurrency, backpressure, and rate limiting
- Covered failure modes, retries, timeouts, and idempotency
- Discussed observability (metrics, logs, tracing,
pprof) - Identified bottlenecks and a scaling path
- Stated trade-offs explicitly rather than presenting one "right" answer
System Design Rubric¶
| Criteria | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| Requirements & scoping | ☐ | ☐ | ☐ | ☐ | ☐ |
| Architecture & data modeling | ☐ | ☐ | ☐ | ☐ | ☐ |
| Scalability & reliability | ☐ | ☐ | ☐ | ☐ | ☐ |
| Trade-off reasoning | ☐ | ☐ | ☐ | ☐ | ☐ |
| Operability / observability | ☐ | ☐ | ☐ | ☐ | ☐ |
Strength: _______________ Fix: _______________
Round 4: Behavioral¶
- Answered using STAR structure (Situation/Task/Action/Result)
- Used "I" to convey personal ownership
- Quantified results with concrete metrics
- Had a genuine failure/conflict story with a lesson learned
- Showed collaboration and influence without authority
- Demonstrated growth and self-awareness
- Kept each story to 2-3 minutes
- Asked insightful questions about team, culture, and roadmap
Behavioral Rubric¶
| Criteria | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| Structure (STAR) | ☐ | ☐ | ☐ | ☐ | ☐ |
| Ownership & impact | ☐ | ☐ | ☐ | ☐ | ☐ |
| Self-awareness & growth | ☐ | ☐ | ☐ | ☐ | ☐ |
| Collaboration & influence | ☐ | ☐ | ☐ | ☐ | ☐ |
Strength: _______________ Fix: _______________
Red Flags / Green Flags¶
Red Flags¶
- Jumps to code before clarifying requirements
- Ignores errors or silently discards
errvalues - Writes concurrency with no cancellation, leaking goroutines
- Cannot reason about time/space complexity
- Blames others; no ownership in failure stories
- Rambling answers with no structure or measurable outcomes
- Defensive or dismissive when given feedback
- Presents one solution as the only right answer; ignores trade-offs
Green Flags¶
- Clarifies constraints and states assumptions explicitly
- Writes clean, idiomatic Go and tests edge cases
- Uses
context,errgroup/WaitGroup, and-racethinking by default - Thinks out loud and invites collaboration
- Quantifies impact and reflects on lessons learned
- Receives feedback gracefully and incorporates it live
- Discusses trade-offs and knows when "boring" simple code wins
- Asks thoughtful, role-specific questions
Final Debrief¶
- Sum each round's rubric scores and note the average
- Identify the single highest-leverage improvement
- Decide: Strong Hire / Hire / Lean Hire / No Hire (with reasons)
- Schedule the next practice loop focused on the weakest round
Overall recommendation: _______________
Top improvement for next time: _______________