A polished CV and a confident interview tell you how well someone talks about development. They tell you much less about how that person writes, reviews and fixes code on a normal Tuesday. Plenty of teams learn the difference after a month of missed tickets.

The fix is not a harder interview. It is a short, fair process that lets a developer show real work before you commit. This guide lays out four stages, how to design a test task that respects people's time, what to ask in a live session and how to score the results without relying on gut feeling.

Why a CV and a Chat Are Not Enough

Résumés list technologies, not depth. "Five years of Python" can mean five years of building production systems, or five years of editing someone else's scripts. A friendly conversation rarely separates the two.

Interviews also reward the wrong traits. Fluent speakers sound senior. Quiet developers who write excellent code sound unsure. If your only filter is a conversation, you will often pick the better talker.

Evidence beats impressions. Work samples, code reviews and a small practical task show how someone thinks, how they handle ambiguity and whether they write code another person can maintain. Those are the traits that decide whether the engagement goes well.

A Four-Stage Process That Fits in a Week

You do not need a long hiring pipeline. Four short stages, in order, cover most of what matters.

1. Screen. Check experience against your actual stack, ask for two or three relevant projects and confirm availability and working hours.
2. Practical task. Give a small, realistic problem to complete on their own time.
3. Code review. Walk through their submission together and ask them to explain their choices.
4. Live conversation. Cover architecture, communication and how they handle trade-offs.

Each stage removes candidates who are not a fit, so the later, more expensive stages involve fewer people. Keep the whole thing within a week where possible, since strong developers rarely stay available for long.

Setting Up the Evaluation Before You Hire Dedicated Programmers

Teams that hire dedicated programmers usually evaluate more carefully than teams hiring for a one-off task, because the person will be embedded in the product for months. That raises the value of getting the decision right and justifies a little more rigor up front. Whether the candidates come from your own network or a provider's bench, the same process applies, and a reputable provider should be comfortable with you running it.

Before stage one, settle three things:

• The skills that matter. Pick five to seven that the role truly needs, not a wish list
• Who evaluates. Ideally someone technical on your side, or a trusted advisor if you have no engineers
• What a pass looks like. Write the bar down before seeing any submissions, so you do not move it for a favorite

Without these, every candidate gets judged on a different standard, and the decision drifts toward whoever felt most impressive in the room.

Designing a Test Task That Is Fair

A good task is small, realistic and tied to the job. A bad one is a puzzle with no connection to your product, or a disguised request for free work.

Some principles keep it fair:

• Limit it to two to three hours of effort. Anything longer filters out developers with full-time commitments
• Use a problem close to real work. A small API endpoint, a bug to fix or a component to build beats an abstract algorithm
• Provide clear requirements and a deadline. Ambiguity should be a deliberate part of the task, not an accident
• Allow normal tools. Documentation and search are part of real work
• Never use your live product code. Use a separate sample project so nothing sensitive leaves your hands

Paid tasks are worth considering for anything longer than a couple of hours. They signal respect and tend to attract more serious candidates.

When you read the submission, look at more than whether it runs. Check naming, structure, error handling, tests and whether the developer left notes on what they would improve with more time. Those signs separate people who ship maintainable code from people who ship something that merely works today.

Add Stack-Specific Checks

Generic questions only go so far. Each technology has its own pitfalls, and a developer strong in one stack can be average in another. Tailor part of your evaluation to the tools you actually use.

For back-end JavaScript roles, for example, questions about asynchronous code, error handling and API design reveal a lot. This guide on how to hire a Node.js developer lists the skills worth checking for that stack, and the same approach works for others. Write two or three stack-specific questions for each role, ask every candidate the same ones and compare answers on equal terms.

Use Independent Testing to Judge the Result

A task can look clean and still hide bugs. Instead of relying only on the candidate's own claims, run the submission against a short checklist: does it meet each requirement, does it handle bad input, does it behave under unusual cases?

If you have no QA resource, borrowing one is cheap compared with a bad hire. Professional software testing and QA services show what thorough verification covers, from functional checks to performance and security, which helps you build a sensible checklist even for a small task. Even ten minutes of structured testing will tell you more than reading the code in a hurry.

Questions for the Live Session

By the time you meet, you have their code in front of you. Use the conversation to understand how they think, not to quiz them on trivia.

About their submission:

• Why did you structure it this way?
• What would you change with another day?
• What was the hardest part, and how did you handle it?

About working style:

• Tell me about a time a requirement changed late. What did you do?
• How do you handle a task you do not fully understand?
• How do you document your work for the next person?

About judgment:

• When would you choose speed over a perfect solution?
• How do you decide when a piece of code needs rewriting?
• What do you check before calling something done?

Listen for specifics. A developer who names a real situation, a real mistake and what they changed afterward is usually more reliable than one who answers in generalities.

Red Flags Worth Taking Seriously

Some signals deserve a pause, even when the rest looks good.

• Cannot explain their own submission
• Blames earlier teams for every past problem
• Avoids saying "I do not know" and guesses confidently instead
• Delivers nothing by the deadline and gives no warning
• Gets defensive about review comments
• Gives vague answers about what they personally built on past projects

One flag can be explained. A pattern of them rarely can.

Score It Instead of Feeling It

Memory fades and charm lingers, so write scores down right after each stage. A simple sheet works: rate each candidate from 1 to 5 on a few categories and add short notes.

• Code quality and structure
• Problem solving
• Communication and clarity
• Fit with your stack
• Reliability, meaning deadlines kept and questions asked early

Weight the categories according to the role. A developer working alone needs more independence, while someone joining a large team needs stronger communication. If two candidates score close, run a short paid trial week with the finalist rather than guessing.

Conclusion

Testing skills before hiring does not need to be heavy. Screen against your real stack, give a small and fair task, review the code together, hold a focused conversation and score everything on a written sheet. The process takes about a week and replaces hope with evidence.

If you want developers who are comfortable with a structured evaluation, EmizenTech, a mobile app development company, works with US businesses on dedicated developer engagements, and the 14-day money-back window gives you room to confirm the fit before you commit further.