How We Vet Engineers Before a Client Ever Sees Them

A CV and a coding test tell you surprisingly little about how someone will work inside a client team. Here is what I look for when vetting engineers we place.

At Outecho a big part of my job is deciding which engineers we put in front of clients. When we place someone into a client's team, our name goes with them. If they struggle, it is not just their problem, it is ours.

That makes vetting less about finding people who can code, and more about finding people who will be trusted inside a team they did not choose, on a codebase they did not write.

The CV is a starting point, not evidence

Most CVs look the same. The same frameworks, the same "responsible for developing and maintaining". I read them to decide what to ask, not to decide who is good.

What I look for instead is depth on one or two things they actually did. Not "I worked with microservices", but which service, why it was split, what went wrong, and what they would do differently.

We talk through real work, not puzzles

I rarely use algorithm puzzles. They test how much someone practised puzzles. Instead we walk through a real system they built, and I keep asking "why":

Why that database, why that structure, why that library?
What broke in production, and how did you find out?
What would you change if you had to scale it ten times?

People who built something for real can go several levels deep. People who were near something often stop at the second "why".

Fundamentals over frameworks

Frameworks change every few years. Understanding how HTTP works, what a database index actually does, how async code runs, why a query is slow, those do not. Someone strong on fundamentals picks up a client's stack quickly. Someone who only knows the framework is stuck the moment something unusual happens.

Communication is half the job

Placed engineers work inside someone else's team, often remotely, often in English as a second language. So I pay close attention to things that have nothing to do with code:

Can they explain a technical decision to someone who is not technical?
Do they say "I don't know" when they don't know, instead of guessing confidently?
Do they ask questions when something is unclear, or go quiet and hope?

The last one matters most. A developer who goes quiet when blocked costs a client far more than one who is a bit slower but raises problems early.

Ownership is the real filter

The best signal I know is how someone talks about mistakes. People who say "we had a bug, I found it, here is what I changed so it does not happen again" are the ones clients keep asking for. People for whom it was always someone else's fault tend to repeat the pattern.

Why it pays off

Careful vetting is slower and we turn down people who would probably be fine. But a placement that goes wrong costs the client weeks and costs us trust that took years to build. I would rather send one person a client keeps than three they have to replace.

If you hire engineers, what is the question that tells you the most about a candidate?