CoderPad Uses CoderPad to Hire Engineers. Here’s How.

When we opened our latest software engineer role, we had 100 applications within 24 hours. By the end of the first week, without running a single ad, we had 160 candidates in the pipeline.

That’s a lot of signal to sort through. And it forced us to be honest about something every engineering leader eventually confronts: a hiring process is only as good as its ability to protect your team’s time while treating candidates fairly.

We’re CoderPad. We build technical hiring software. So yes, we use our own product. Here’s what that process actually looks like.

Start with the right goal at the top of the funnel

Maxime Cheramy, our Director of Engineering, was direct about it: “The goal is simply not to waste time with candidates who cannot produce anything.”

Not “find the best developer.” That comes later. To start, we focus on filtering out candidates who aren’t ready, without filtering out candidates who are just stressed. Those are different problems, and conflating them leads to a screen assessment that’s too hard, that maybe you’re proud of, but that your ideal hire fails on a bad day.

The screen exists to protect your live interview capacity. Save your judgment about “great” for when the humans in the interview together.

Design for layers in the process, not one knockout question

Max’s screen has five layers, each with a specific job:

1. Easy multiple choice only. If a candidate fails easy questions, that’s signal. If they pass a hard one, you don’t know if they knew it or asked an AI. At the screening stage, easy questions have more diagnostic value.
2. Simple coding exercises, like SQL. Quick, low-friction, still revealing.
3. Two CoderPad Projects. Job-realistic work: build a backend API, work within a real codebase structure. Projects are where candidates demonstrate they can actually ship something, not just solve a puzzle. CoderPad’s Projects feature lets you build these assessments and review the work in a shared environment, including replaying how a candidate approached the problem.
4. A video question. Not a behavioral prompt about “a time you showed leadership.” Candidates are asked to explain something they just built in the assessment. It’s specific, it’s fresh, and it’s much harder to prep a generic answer for.
5. A puzzle element. Some signal about how someone handles ambiguity is still worth having.

Don’t test for surprise – Tell candidates what’s on the test

Candidates are told in advance what to expect: React, SQL, a project, a video question. This is intentional.

If someone fails after knowing what’s coming, that’s a bad sign. If they prepare and pass, that’s fine. You’re not testing surprise. Amazon sends detailed prep documents to candidates, including the questions, which is a good example. Preparation is a proxy for how someone approaches real work.

Connect the screen to the live interview

The live technical interview includes a brief debrief on the screen assessment. Not a deep review, but enough to see how candidates explain their own choices and whether their verbal technical reasoning holds up. CoderPad’s playback lets interviewers review how a candidate worked through a problem before the live round, so you’re not starting cold.

Max still asks non-technical questions in the technical interview, because it’s often the only real conversation before a decision gets made. Specifically: are you more of a builder, someone who cares about what gets made and why, or a craftsperson, someone who cares about how? Neither is wrong. With a smaller team, that distinction matters as we have different needs at different times.

The AI question

Every technical hiring team is sitting with the same problem: how do you evaluate candidates when AI can write production-level code?

Max’s current answer: easy multiple choice is more valuable now, not less. Project questions shift from “can they write this” to “do they understand what they built.” Video questions create accountability to the work product even if AI assisted. Live interviews let you probe in ways that reveal whether the candidate understands their own output. We test for AI at every step.

The goal isn’t to catch people using AI. It’s to design an assessment where AI assistance doesn’t mask the signal you’re actually after.

What we’re learning by doing this

160 candidates in a week is a real volume. Working through it with our own product keeps us honest about where the friction is and what it feels like to be on the other side of what we build.

If you’re designing a technical screen and starting from “what’s the hardest problem I can give them,” try starting from “what’s the minimum I need to see to protect my team’s time?” That question usually gets you somewhere better.

If you’re running a process, think of different types of questions to understand the skill level you need. Be focused on job-specific questions over puzzles – unless your company actually builds puzzles.

Overall Lessons

• Dogfooding works best when you’re designing a real process under real constraints, not a demo. Max had 160 candidates and a hiring need — that pressure produced better product insight than any internal exercise would have
• The test is a means to an end. The goal is to protect the live interview stage for candidates who are worth the time, not to find the hire through the screen alone
• Question design can’t be separated from process design. Picking questions in isolation — or looking for one golden question — misses the point. Each stage has a job to do, and the questions should serve that
• How you frame a question changes what you learn. The video question works because it asks candidates to reflect on work they just did, not perform under abstract pressure. Small framing decisions have a big impact on signal quality
• Preparation transparency is a feature, not a risk. Letting candidates know what’s coming filters for the right things and produces more authentic responses. Surprise is not the point
• With AI in the picture, the profile of a strong hire is shifting. Deep technical experts and strong builders are both valuable. Generalists who are neither are harder to place on a team that’s moving fast with AI assistance