The Startup Hiring Lie Nobody Talks About
The biggest lie startups tell during hiring is “We have a lot of problems, and you can pick whatever you want to solve.”
This edition of the newsletter contains
Btw, enrollments are open for my Systems Design October cohort (sessions start 11th Oct, ~7 seats left). If you’d like to dig deeper into systems, their implementation, and how to design them the way they actually run in production, check out:
The course is completely no-fluff and packed with brainstorming and discussions that will shape your thought process and intuition. You’ll feel like you’re part of a real technical discussion happening at your workplace.
The Startup Hiring Lie Nobody Talks About
The biggest lie startups tell during hiring is “We have a lot of problems, and you can pick whatever you want to solve.”
It sounds great. It plays directly to what we engineers love - autonomy, impact, and ownership. But here’s the reality - this almost never happens. When a startup says this, it usually means one of two things:
A lack of clarity in leadership
They’re just trying to lure you in
Even in the rare case where you get some freedom, your work still has to align with business goals, product timelines, and team priorities. You’ll likely be working on whatever the product needs immediately, which is okay, but...
Most of these companies are in constant firefighting mode, so you might never have time to pull off what you wanted to. And honestly, if a company really lets you work on “whatever,” that’s a red flag.
It signals a lack of direction, focus, or urgency. Good leadership doesn’t offer infinite choice; it offers clarity and purpose on a limited set of problems. There is always a north star that is being chased.
Do not fall for startups without looking under the hood. Assess the clarity of their roadmap, the strength of their leadership, and how decisions are made. Ask,
What’s the team working on right now?
What are the top priorities this quarter?
How do you decide what gets built?
Can you share an example of when an engineer wanted to build something that didn’t align with goals? How was that handled?
Also remember: very early-stage startups might genuinely need people to wear multiple hats and solve problems across the board - but even then, choices are constrained by survival. And often, when founders pitch “freedom,” it’s not malicious - they just want to sound attractive to candidates and don’t realize how misleading it can be.
Good startups don’t sell you autonomy; they sell you clarity on why your work matters. Don’t get sold on freedom, get sold on focus.
By the way,
Being hands-on is the best way for you to learn. Practice interesting programming challenges like building your own BitTorrent client, Redis, DNS server, and even SQLite from scratch on CodeCrafters.
Sign up, and become a better engineer.
Here’s a video from me
I published a video - What exactly is the HTTP protocol and how to write a new one from scratch?
We all use the word protocol often, but what exactly are they?
HTTP is the most common protocol we use every day - whether it’s surfing the internet, writing backend APIs, or consuming them in our applications. But how does it actually look?
In this video, we go deep to understand what protocols really are, what the HTTP protocol is, how it looks, and what it takes to write your own protocol from scratch.
Give it a watch.
Here’s a paper I recently read
I spent some time reading Dremel: Interactive Analysis of Web-Scale Datasets
In 2010, Google had datasets containing trillions of rows, and running a query on this was a nightmare. Some time back, I read a paper from Google that talks about this very problem.
The paper is titled Dremel, and it is one of the most interesting papers that covers almost all aspects of system design.
The paper is about how Google built a system for low-latency querying over petabytes of structured data, without inducing the cost of data flattening or preprocessing!
At this scale, even MapReduce does not work; hence, Google built Dremel, which supports querying over such huge data without scaling linearly to thousands of nodes, supports trillions of records, and gives interactive latencies.
One thing that stood out was how they handled encoding of nested data, along with aggregating results bottom up to reduce the query response times.
If you’re into databases and want to dig deeper into query engines, building analytical infrastructure, or just curious about how to make structured data move fast, this paper is a must-read.
You can download this and other papers I recommend from my papershelf.
Three interesting articles I read
I read a few engineering blogs almost every day, and here are the three articles I read and would recommend you read.
Thank you so much for reading this edition of the newsletter 🔮 If you found it interesting, you will also love my courses
I keep sharing no-fluff stuff across my socials, so if you resonate, do give me a follow on Twitter, LinkedIn, YouTube, and GitHub.
Its very true. The founder must have clear idea on what they are trying to build.
Solving any & all problems doesnt help with growth.