Hiring
How we vet: signals over puzzles
Our five-stage screen is designed around one idea: test what the job actually asks for. Here is what we look for, what we deliberately ignore, and why.
Every company that hires through Engagetal is trusting us with the most expensive decision they make. Every candidate who applies is trusting us with their time. Our vetting process has to respect both. It is built around one idea: test what the job actually asks for, and nothing else.
The five stages
- Profile and communication review. A person reads every application. We look at what someone has actually done, how clearly they write about it and what they want to do next.
- Skills assessment. For engineers, a code review and a systems exercise. For go-to-market talent, a case: a positioning problem, a pipeline to diagnose or a campaign to critique.
- Live panel interview. Sixty minutes with a senior practitioner, focused on decisions, trade-offs and the story behind the CV.
- Work sample. A short, scoped piece of work that mirrors the job, scored against a rubric we share in advance.
- Ongoing review. After every engagement, client feedback goes back into the person's profile. The bar does not stop at onboarding.
Why we don't use puzzles
Timed algorithm puzzles are popular because they are easy to administer and easy to score. They mostly measure whether someone has recently practised timed algorithm puzzles. Very little engineering work looks like that, and plenty of excellent engineers perform badly under an artificial clock.
A code review tells us far more. Give an engineer a realistic pull request with a few problems in it, some obvious and some subtle, and ask them to review it. Within twenty minutes you can see how they read code, what they notice, how they prioritise and how they communicate criticism. Those are the skills a team actually depends on.
We would rather see how someone reviews code than how fast they can reverse a linked list.
The same logic applies to go-to-market roles. We do not ask marketers for textbook definitions. We give them a real product with a real positioning problem and ask what they would do in the first thirty days.
What we look for
- Ownership. Do they talk about outcomes they were responsible for, including the ones that went wrong?
- Trade-off reasoning. Can they explain why they chose one approach over another, and what it cost?
- Clarity. Can they write and speak plainly about complicated things? Remote teams run on writing.
- Calibration. Do they know what they do not know, and say so?
What we deliberately ignore
We do not screen on college brand. We do not treat years of experience as a proxy for seniority, because two people with the same years can have very different depth. And we do not reward keyword-stuffed CVs that list every framework ever released. None of these predict how someone will do in the job, and all of them filter out good people.
Respecting candidates' time
The work sample is short and scoped, and we tell candidates exactly how it will be judged. Every stage ends with a clear next step. When someone does not pass, we give specific feedback. Good people talk to each other, and a process that treats candidates badly eventually runs out of good candidates.
What this means if you're hiring
When you request a shortlist, you receive four profiles, each with a scorecard, work you can read and notes from our panel. Your interviews can skip the basics and go straight to the questions that matter for your team. That is where most of the time saving comes from, not from rushing the decision.
