Cracked Engineers and How to Find Them

Building a fast-growing startup means I have to talk with a ton of engineers going through our hiring process and I’ve had to sit through many interviews where someone rattles off their resume like they're reading a grocery list:

• "Increased user engagement by 12%."
• "Improved test coverage to 89%."
• "Aligned stakeholders on critical product launch."

Cool story - but I have no idea what any of that actually means, and honestly I don't really want to find out.

When Bugra and I started HockeyStack, it was just the two of us in a room, building a very crappy v1 from scratch. Just to hit an arbitrary deadline to show off something nice to prospects. We were the definition of scrappy — two college dropouts who believed we could code our way to something that people would actually pay money to use. And somehow, we did (unraveling that story requires its own series…)

But when it came time to hire our first engineer, we faced a problem: how do you find people who are actually... well, like us? Resourceful people that would be able to handle any type of engineering challenge we throw at them and actually come out on top.

The valley has a trendy term for this now: cracked engineer. It’s kinda the next iteration of the so-called 10x engineer. Well I don’t really like to confine people into terms but let’s play the game for the sake of this post. Over the years, I think we've learned to spot certain signals that tell us when we're talking to a truly cracked engineer and I want to go over some of those here.

‍

The Childhood Hacker Origin Story

Almost every great engineer we've hired has some version of the same story. They discovered coding young, not because they had to, but because they were obsessed with building something. Or more likely “hacking” something.

For me, it was trying to predict lottery tickets. I was maybe 13 or 14, watching my family randomly pick numbers every week with the hopes of winning a big money prize (they never did), and I thought to myself, "There has got to be a pattern here." And surely I can crack this pattern before my sophomore year of high school.

So I spent an entire week during our summer holiday, teaching myself Java (because I thought that's what everyone used — spoiler: think again), trying to scrape historical lottery data and find patterns I could predict with code.

It didn't work, obviously... If it had, I'd be on a beach somewhere sipping my dirty martini instead of writing this blog post. But those sleepless nights taught me something magical: with just a screen and a keyboard, you could (try to) build literally anything. And if you were good enough, it would actually work.

One of our engineers told us about becoming so obsessed with a game his friends were playing that he started hacking it to win. Another spent high school reverse-engineering mobile apps just to see how they worked and tried building his own apps afterwards. When people tell these stories, their eyes light up. You can feel the sleepless nights they poured into their pet projects.

That passion? That's the foundation everything else is built on.

‍

School Is Optional, Side Projects Are Not

Since Bugra and I are both dropouts, it probably doesn't surprise you that we don't really care where someone went to school — or if they went at all. One of our first interview questions is always: "Tell me about something cool you built while you were still in school."

Here's what we've noticed: if you're truly passionate about coding, college usually takes about 1-2 years max before you realize you can accomplish way more in your free time than in any classroom. For us, it took 3 months before we booked our flight to SF. For most people, it means they're already building side hustles and cool projects while juggling coursework.

The projects they choose to work on during this time? That's what shapes the kind of engineer they'll become. Are they building something because it's fun and challenging, or because they think it'll look good on a resume? The difference is everything.

‍

Technical Problems > Business Metrics

Now I’m not saying business metrics don’t matter. That’s what pays the bills alright. But remember those engineers who loved talking about how their feature increased user adoption by 8%? Yeah, we don't really vibe with them.

Cracked engineers don't boast about business metrics or test coverage percentages. Their proudest moments are when they solve genuinely hard technical challenges or build something unexpectedly cool. When you ask them about their previous work, they don't start with the business impact — they dive straight into the technical problems they had to overcome.

They'll tell you about the clever shortcut they found to avoid rebuilding an entire system, or how they chose an unconventional tech stack that solved a problem everyone thought was impossible. They get excited about the craft itself, not the usage dashboards that resulted from it.

‍

Being There Together No Matter What

Working at a startup is intense. Every other week there are new urgent things that might make or break the company. We need people who care so much about what they're building that when something needs to ship urgently, they're the first to volunteer for weekend deployment duty.

But here's the thing — cracked engineers aren't martyrs working alone on a mountain. They're the ones who build those all-star teams where everyone's willing to unblock and help each other, no matter the hour. Need a code review at 9 PM? They've got you. System goes down on Saturday? They're already ssh’ing into the server.

This isn't about grinding for the sake of grinding. Everyone needs to recharge and relax before pushing back up. But this principle is about being surrounded by people who care as much as you do, and being willing to move mountains together when it matters.

‍

Running Toward the Hard Stuff

The engineers we love most have three things in common:

First, when they commit to something, they find a way to make it happen — even if it means getting creative or unconventional. They don't just accept "that's impossible" as an answer. Usually it’s not impossible but just pretty damn hard. But that means it is still solvable.

Second, when problems show up (and they always do), these engineers don't run away or wait for someone else to fix it. They're the ones charging toward the fire, sleeves rolled up, ready to figure it out.

Third, and maybe most importantly, they take real ownership. In a startup, you get a lot of autonomy, but that comes with ambiguity. Not everyone can thrive when there are no guardrails and you're genuinely responsible for the thing you're building. Cracked engineers don't just survive in that environment — they love it.

‍

The Blind Optimism Factor

At the end of the day, cracked engineers understand what it takes to build something from literally nothing. They have this almost irrational optimism that they can figure out any problem and build any solution, even when all logic suggests otherwise.

That blind optimism? That's what lets them actually make the difference between an idea that stays an idea and something that changes the world.

‍

Closing Thoughts

When we interview engineers now, we're not looking for someone with the perfect resume or the most impressive past company experience.

We're looking for that person who spent their teenage years building random stuff just because they liked the thrill, who gets excited about technical challenges and jumps on problems no matter the situation, and who has the audacity to believe they can build anything and everything they put their mind to.

Because honestly? Those are the people who actually do.

If this sounds like you and you're curious about what we're building, we'd love to hear your origin story. Drop us a line — we're always excited to meet fellow builders :)