the question
i've had a question stuck in my head for about a year now: what makes an engineer exceptional?
not good. not senior. exceptional.
i've asked this to dozens of people — engineers at tako, outside of tako, founders, CTOs. and spoiler: we're not ending this post with a clean answer. but i do have a story that changed how i think about it.
the label vs. the reality
i joined tako about ten months ago as a software engineer. one of the first things i heard about the company was the quality of the team. if you open linkedin and search for the engineers there, you'll find people who've been through nubank, mercado livre, uber, amazon, google, quintoandar, ifood. the list goes on.
and i know that for a lot of people, especially in the bay area, this kind of labeling is thrown at you every day. it's always about where you work, what school you went to, whether it was an ivy league. and the logic is simple: if place X is good and person Y works at place X, then person Y must be good.
but is that true?
sometimes, sure. but when a company has been around for five or ten years with a mature product, the core has already been built. the systems are stable. you can show up, do decent work, have great work-life balance and, honestly... coast a bit. statistically, the bigger the company and the more mature the product, the easier that is.
the engineers at tako aren't people who just passed through big tech. they're the ones who left. every one-on-one i had in my first weeks, the story was the same: "i left because the sea was too calm."
they couldn't stand being a cog in the machine. they wanted to own the whole process.
that's what pulled me in. i saw a massive problem surrounded by a group of people who literally couldn't sleep well until they'd solved it.
what makes an engineer exceptional?
so the next question is obvious: what actually makes an engineer exceptional inside a startup?
there's a lot of talk these days about being exceptional, about learning to recognize "what greatness looks like." but the problem is most people don't really understand what that greatness actually is.
one of my first conversations at tako was with lucas, who was roughly the fifth engineer at the company. he'd been through places like cielo, bex, porto, and mercado livre (there i go with the labeling again).
he brought three other engineers to tako — people he called the best he'd ever worked with.
my question at the time was: what made them "the best"? well-written lines of code? updating linear like a maestro? writing PRDs like nobody else?
he couldn't really articulate it. and honestly, most people i asked couldn't either. but over time, after asking this same question to a lot of different people, i think i have a bit more clarity.
and it connects directly with something happening in the world right now.
code is no longer the bottleneck
writing code has gotten dramatically easier. i don't think i need to ask how many of you have already incorporated AI tools into your daily work — whether coding or anything else.
a moment that crystallized this for me: i was watching a behind-the-scenes video of the stranger things directors, showing how they wrote the script for the final season. and there, in the background, in their browser, was a ChatGPT tab open.
if the stranger things writers are using GPT, i think it's safe to say we've moved past the "should i use AI or not?" debate.
when you can produce code 10x or 100x faster than before, a lot of things obviously get easier. and the conversation becomes: programmers are going to become product managers. the bottleneck is shifting from writing code to understanding what to build.
and honestly? that framing scares me a little. not because i think my profession is ending, but because i never understood how that wasn't already the job from the start.
the answer to "what will engineers do when code is no longer the bottleneck" isn't that engineers will transform into something else. it's that the best engineers were already doing this. the tools just made it impossible to ignore.
the recruitment story — when the ball isn't round enough to kick
let me show how this plays out in practice.
earlier this year, we decided it was time for tako to expand. quick context: over the past few years, we built payroll, termination, vacation management, and onboarding — all the core pieces of a company's HR department.
the natural next step was: what comes before onboarding and also has a process full of massive pain points? recruiting.
and here's where it gets interesting. when you hear "new product area," the engineer brain says: great, open the IDE, pull tickets, let's code.
but the ball wasn't round enough to kick.
we knew expanding into recruitment made sense. but understanding the biggest pain points of that process meant completely deconstructing the mindset we'd built over months of working on payroll agents, and learning to feel the pain of a completely different group of people.
so the first thing i did wasn't opening claude code. it was cold DMing about 40 talent acquisition people and asking: what's the worst part of your job? got 30 minutes for a chat?
(almost a role reversal)
then iterating. which of these pain points are real and recurring? what tools already exist to solve them? and for the tools that exist and are good — why aren't people using them?
what i found is that the whole process is a mess. on both sides.
on the candidate side, especially for early careers: job postings get thousands of applications within hours. people get rejected by AI agents reading one-page CVs without even understanding what they're evaluating. and candidates never find out if they passed or not — they end up in limbo in a "talent pool" for the company to fish from months later when a new position opens.
and here's a wild stat: research shows that candidates who receive feedback (even negative) are 3.5x more likely to reapply to the same company. ghosting people isn't just rude. it's bad business.
on the company side? equally miserable. each screening interview takes about 30 minutes. if you have a thousand applications and a team of one or two recruiters... the math is basic, and their lives are even more miserable than the candidates'.
on top of all that, the process is full of technical and cultural tests that don't even make sense — they exist purely to shrink the funnel and make the recruiter's life a tiny bit less awful.
all to create a false illusion of fairness, so they can say "we don't treat candidates like numbers and we go through the entire process manually." as if the person interviewed at 2pm on a monday, after the recruiter had a peaceful weekend in the countryside, had the same chance as the person interviewed at 5:30pm on a friday, when the recruiter just wants to get to happy hour.
so we asked ourselves: which part of this process is worth betting on?
and the answer was: screening interviews. not a robot pretending to be human. think of a bucket that takes everything the company knows about the role, everything the candidate brings, and lets the candidate talk freely for 30 minutes with real follow-up questions.
the question isn't whether companies will use AI in recruiting. they will. the question is: how much context will they have when they do? the one-page CV? or a 30-minute conversation where the candidate actually talks about who they really are?
the candidate wins by actually being heard. the company wins by having real context on those 500 people they used to just discard. it works 24/7, in parallel, with no scheduling. and it's consistent — without the N biases that exist in a normal interview.
being a great engineer is not being an engineer
so why did i tell that whole story?
because the answer to "what makes an exceptional engineer" was hidden in there the whole time.
the role of engineering was never just writing code. but it was easily confused as being mostly that. with or without claude code, the easiest part was always sitting down with well-defined requirements and translating them into some programming language.
being a great engineer sometimes means not being an engineer.
it's being in the entire workflow. it's knowing that sometimes your job is product. sometimes it's sales. sometimes it's getting on a call with a frustrated recruiter and feeling their exhaustion in your chest.
the recruitment story is the proof. the hardest part wasn't building the agents. it was those first weeks where i wasn't writing any code at all. my job was to become someone in talent acquisition, even if temporarily. to feel their pain so deeply that i started predicting edge cases — not from requirements someone handed me, but from having lived the frustration.
because if you stay in your engineering box, the distance from the product means you can't see the real solution. you see requirements that came from someone else, filtered through their view of the problem.
so if i had to boil it all down:
first: be objective. cut the noise. find the problems that actually exist versus what people think the problem is.
second: be relentless about getting data. not dashboards — human, messy, real data. 40 cold DMs. sitting in on interviews. watching someone use a broken tool and seeing where they wince.
third: become the person whose problem you're solving. even if just for a few weeks. feel it so deeply that their pain becomes your pain, and you start losing sleep over it. it's the same feeling i saw in the engineers at tako — who couldn't rest until the payroll product was built.
and you know that extraordinary team, the "what greatness looks like" that i mentioned? it comes from this. a group of people, with different biases and perspectives, who by becoming obsessed with the same problem, can converge on a solution that actually serves those people. the magic isn't the code. it's the obsession.
never be the smartest in the room
one last thing.
if there's a single piece of advice that has guided every decision i've made, it's this:
never be the smartest in the room. never.
when i joined tako, i felt like there were all these incredible engineers... and then me. i didn't have the answers when everyone else did. that's frustrating. it's uncomfortable. but it's the only environment where you actually grow.
i've been at tako for ten months. there's still so much i haven't learned, so much i haven't explored. and that's exactly what makes me get up every day.