From Candidate to Interviewer: What I Refuse to Repeat
/ 6 min read
Not anymore.
A couple of years ago, I was the candidate.
Confused. Tired. Checking my email more times than I want to admit.
I remember one weekend in particular. I spent hours on a take-home assignment. I submitted it on Sunday night, slightly proud of what I had built.
On Monday morning, I got a rejection.
Two lines. No feedback.
That moment stuck with me.
Now I’m on the other side. And if you’re involved in hiring, this part matters.
Because here’s the uncomfortable truth: many of the things we complain about as candidates are still the default when we become interviewers.
If you’re curious, I wrote about my experience going through broken hiring processes as a candidate here.
Vague roles. Endless loops. Take-home tasks that go nowhere.
At some point, you have to decide.
Either you repeat the system. Or you take responsibility for your part in it.
If you hated interviewing and now repeat it, you are part of the problem.
Most hiring processes are inherited. And no one really owns them.
That is why the same problems keep showing up.
These are three things I try to get right every time I’m involved in hiring:
- Be clear, honest and transparent
- Respect candidates’ time and give something back
- Make technical tasks realistic and useful
1. Be clear, honest and transparent
One of the most frustrating things I experienced as a candidate was talking to companies that did not even know what they were hiring for.
You ask simple questions:
- What team would I join?
- What are the main challenges?
- What does success look like?
And you get vague answers. Or no answers at all.
At some point you stop asking, because you realize they do not know either.
I understand that in large organizations you might not know the exact team yet. That is fine.
What is not fine is hiding behind that uncertainty.
If you cannot clearly explain your hiring process, you do not understand it well enough.
And that has consequences. For you as a hiring manager, and for every candidate going through it.
Feedback is usually where this becomes obvious. Either it never arrives, or it is so generic that it could apply to anyone.
What I try to do differently
From the first conversation, I make things explicit:
- The full process
- Who is involved
- What we evaluate at each step
- What candidates should evaluate about us
I also explain how we work:
- What kind of engineers we look for
- How the company operates
- What we believe in, including how we think about AI
Transparency should increase as candidates invest more time.
If someone is close to joining your company, they should not be guessing what they are walking into.
That includes the uncomfortable parts.
I talk openly about the messy areas of our codebase. What is not ideal. Why it ended up like that. What we are doing about it.
I have had moments where I thought: “Did I just share too much?”
But here is the alternative.
A candidate joins, and two weeks later realizes things are very different from what they expected.
That is not a hiring success. That is a delayed failure.
If a candidate joins and feels surprised, your hiring process failed.
2. Be mindful of invested time and give something back
That weekend I mentioned earlier was not the only time.
There were multiple processes where I kept going through rounds thinking:
“This is not going anywhere, is it?”
Still, you continue. Because maybe you are wrong. Maybe the next step will change things.
Then it ends exactly how you expected.
Not rejection.
Predictable rejection after unnecessary effort.
That is worse.
Where processes break
This is a pattern many hiring managers underestimate:
Candidates go through multiple steps. They invest more and more time. Nothing fundamentally changes. They get rejected.
From the company side, it feels like a normal process.
From the candidate side, it feels like wasted time.
And here is the uncomfortable part:
A process that wastes candidates’ time is a broken process. Even if you hire great people.
Because you are optimizing for outcomes while ignoring experience.
What “giving back” means
Candidates are investing time. You should return value.
That means:
- Giving real feedback on their work, like you would do in a code review
- Sharing advice if they are looking for direction
- Being honest about where they stand
Even if you do not hire them, they should leave with something useful.
If a candidate invests hours, you owe them more than a template rejection.
What I changed
We designed a process with:
- A limited number of steps, four in our case
- A clear goal for each phase
- A commitment to respond within one week after every step
The full process takes around a month.
No endless loops. No unnecessary rounds.
And this matters more than most teams think.
Because the majority of people who interact with your hiring process will not join your company.
But they will remember it.
They will talk about it.
And over time, that shapes your ability to attract talent far more than any employer branding campaign.
3. Make technical tasks useful and realistic
I have done many technical interviews.
The worst ones felt like going back to university.
LeetCode exercises. Abstract problems. Tasks disconnected from the actual job.
Or building a generic demo app from scratch that no one will ever use again.
You spend hours creating something that has zero relevance outside the interview.
What these tasks miss
They do not show how someone actually works.
They do not show:
- How they think through real problems
- How they make decisions
- How they deal with trade-offs
- How they connect engineering with product
They measure how well someone performs under artificial constraints.
Not how they would perform in your team.
What I look for instead
A good task should feel like real work.
It should:
- Be close to the product
- Reflect real challenges
- Be open-ended
There should not be a single correct solution.
Because real work does not have one.
What matters is:
- How the candidate thinks
- What they prioritize
- How they explain their decisions
I also pay attention to how they use tools.
Including AI.
We do not restrict it. We encourage it.
That is the environment they will work in. Anything else is a simulation.
The goal is not to see if someone can pass an interview. The goal is to understand how they would work with you.
One important nuance
There are cases where a candidate does a great job.
Good solution. Solid thinking. Clear communication.
And still, we decide not to move forward.
Not because they are not good.
Because they are not the type of engineer we need in that team.
A good process should make that distinction early. And make it clear.
Final thoughts
Most hiring processes are not intentionally designed.
They are inherited, patched, and rarely questioned.
That is why the same problems keep showing up.
But once you have been on both sides, it becomes a choice.
If you hated interviewing and now repeat it, you are part of the problem.
You will not fix hiring overnight.
But you can decide what you tolerate in your own process.
You can:
- Be clearer
- Be more honest
- Respect people’s time
- Design evaluations that reflect real work
And that is where it starts.
Not with a perfect system.
With someone deciding not to repeat a broken one.
What comes next
This post focuses on principles.
In a follow-up, I will break down the exact 4-phase process we use. Step by step. What happens in each phase, what we evaluate, and how we try to keep it fair for both sides.
Because principles are easy to agree with.
Designing a process around them is the hard part.