The Gap Between Prep and Real Building
There’s a version of interview prep that’s entirely theoretical. You memorize system design frameworks, practice behavioral questions, and grind through mocks until your answers sound rehearsed. I did some of that. But the thing that actually changed how I showed up in interviews was building Bookmarked — a full-stack app that saves tweets directly to a Notion database through a Telegram bot.
Building something real surfaces problems you’d never encounter in a mock. What do you do when the Telegram webhook and the Notion API have different rate limits? How do you handle a failed sync without losing the user’s data? These aren’t questions you can answer from a framework. You have to build through them.
What Bookmarked Taught Me About System Design
Before I built Bookmarked, I could talk about message queues in the abstract. After building it, I understood why you’d want one — because synchronous API chaining is a liability when one service is slower than another. I ended up with a simple retry mechanism instead of a full queue, which was the right call for the scale, but I understood the tradeoff I was making and could articulate it precisely.
That kind of reasoning — knowing what problem a pattern solves and when it’s overkill — is exactly what interviewers probe for in system design rounds. It’s hard to fake if you haven’t built anything real.
How Having Real Projects Changed the Interview Dynamic
The moment I started walking interviewers through Bookmarked instead of a to-do app, the conversations got more interesting. Engineers asked follow-up questions. They pushed back on architecture choices. One interviewer spent twenty minutes on the Telegram webhook flow because he’d built something similar and wanted to compare notes.
That’s a completely different dynamic than reciting answers. Real projects invite real conversation, and real conversation is where you actually demonstrate what you know rather than what you’ve memorized.
What Recruiters Actually Want to Hear
They want to see that you’ve hit real walls and made real decisions. Not that you’ve followed a tutorial to completion, but that you encountered a problem, weighed your options, and chose one with a reason. The “why” is everything. A mediocre technical decision with clear reasoning reads better than a perfect decision with no explanation.
Build something you actually use. The specificity of a real problem, and the authenticity of having genuinely solved it, comes through in a way that polish alone can’t replicate.