We stopped reading resumes the way most companies read them about four years ago. We still look at them. But the question we're trying to answer is different.
Most engineering hiring processes are built to filter for technical competence. Ours is built to filter for something harder to measure and more important to the work we do.
What We're Actually Screening For
The word "empathy" sounds soft. In an engineering context, it isn't.
What we mean by empathy is the ability to hold someone else's experience in your head while you're making technical decisions. To ask: who is going to use this? What are they doing right now? What will confuse them? What will frustrate them at 11pm when their deadline is tomorrow?
An engineer with high technical skill and low empathy builds systems that are architecturally impressive and experientially terrible. We've worked alongside enough of them to know.
An engineer with moderate technical skill and high empathy builds systems that are coherent, humane, and maintainable — because they're constantly asking whether what they're building actually makes sense to a person.
"You can teach a smart person a new language in a week. You cannot teach them to care about the user."
What Our Process Looks Like
We don't have a whiteboard coding round. We have a conversation.
We ask about a time they built something they were proud of — and then we ask what they'd change. Not "what went wrong technically." What would they change about the decision-making, the communication, the understanding of the user.
We ask: "Tell me about a time you pushed back on a product requirement." What we're listening for is whether the pushback was based on technical preference ("I don't like this pattern") or product understanding ("I don't think this is what the user actually needs").
We give them a scenario and ask what questions they'd ask before writing a single line of code. The quality of the questions tells us more than any algorithm exercise.
The Mini SaaS Program as a Filter
We've formalised this through our Mini SaaS Program. Every Akvasoft engineer builds and launches a real SaaS product before joining a client team. The program doesn't teach empathy directly. It creates the conditions for it.
When you've built something and watched real users struggle with it, you develop a reflexive awareness of the user perspective. You stop abstracting users into "personas" and start thinking of them as specific people making specific decisions under specific pressures.
You also develop a tolerance for the uncomfortable feeling of being wrong about what users need. That tolerance is more valuable than any technical skill.
Why This Matters for Partnerships
We work with clients for years, not sprints. The engineers who succeed in that environment are the ones who can hold the client's business problem in their heads alongside the technical problem. Who pick up the phone when something is off. Who write the Slack message that says "I've been thinking about this feature and I'm not sure it's the right call."
That kind of judgment can't be hired from a resume. It can be screened for, trained for, and evaluated over time.
The resume tells you what someone knows. The conversation tells you how they think. We've always cared more about the second one.