Career & Interview
GitHub Showcase & Capstone README Generator
Panels open your GitHub link in the first three minutes. Make the README sell the work, survive the defence questions, and audit the repo before anyone else does.
README generator
Generated README.md
# Your Project Name > One line on what this does and who it helps. <!-- badge row: shields.io badges per technology --> ## Architecture <!-- link your draw.io / excalidraw diagram here --> ## Key engineering challenges solved - <!-- what hard problem did you actually solve? --> ## Local setup ```bash # clone, install, configure .env, run ``` ## Demo <!-- add a hosted link or a 30-second GIF --> ## License MIT
Capstone defence playbook — the 10 questions panels ask at your repo
Why did you choose this database / framework?
Name the constraint that decided it — data model fit, ecosystem, or team familiarity — then name one alternative you rejected and why. “We used MongoDB because our schema was document-shaped and we needed flexible sensor payloads; SQL would have needed heavy joins for our read pattern.”
How does it scale to 10x users?
Know your bottleneck's name. “At 10x, the API layer is stateless so we scale pods; the DB becomes the bottleneck first — read replicas and caching the hot paths buy us another 5x before sharding.”
Walk me through this commit history.
Open your repo and tell the story: setup → core feature → bugfixes → polish. Messy commits? Rehearse a 30-second summary of what each phase delivered, and say what you'd do differently (feature branches, conventional commits).
What was the hardest bug, and how did you find it?
Use a real one: symptom → hypothesis → how you bisected or logged → root cause → fix. “The report totals were off by one row; I bisected the aggregation query and found an off-by-one in a date boundary filter.”
What would you build next if you had one more month?
Have a prioritised answer: the feature users asked for, the technical debt that hurts, or the missing test coverage — and say which you'd pick first and why.
Which part is yours vs your teammates'?
Never blur this. Point to files/modules you authored and be generous describing teammates' work — panels cross-check, and honesty here is a hiring signal.
How do you handle secrets and configuration?
“Config comes from environment variables; .env is gitignored and only an .env.example is committed; production secrets live in the hosting platform's vault.”
How did you test it?
Name the layers: unit tests, a sample dataset, manual test cases for edge conditions. No tests? Own it: “Testing is the gap — here's what I'd cover first: the calculation module, because errors there are silent.”
Why is your architecture this shape (monolith vs microservices)?
Justify by scale, not fashion: “A modular monolith was right for two developers and one deployment target; splitting services adds ops overhead we can't fund yet.”
What happens when this fails in production?
Show failure thinking: logs, retries, graceful degradation, alerting. Even a small project should know where it breaks first and what the user sees.