How to Identify the Right IT Candidate for Your Project

Why keyword matching is not enough

Most requisitions get matched the same way. Someone takes the job description, pulls five or six keywords, and searches a job board or an ATS. The resumes that come back all have the right words. So why do so many of them fail in the first client interview, or worse, in the first month on the project?

Because a keyword tells you a person was near a tool. It does not tell you what they did with it. I have seen resumes with Jira, SQL, Agile and Azure listed under every single role, and the candidate could not explain one requirement they wrote. And I have seen quiet resumes, badly formatted, from people who carried a whole go live on their own. The right candidate is the one who will actually help the project, and finding that person takes a few more steps than a search string.

Start with role clarity before you look at anyone

You cannot identify the right candidate if you do not know what right looks like. Before sourcing, ask the hiring manager or the prime vendor a few plain questions:

• What will this person deliver in the first 90 days? A data migration, a set of user stories, a test plan, an interface? Outcomes tell you more than a list of duties.
• Who will they work with every day? Business users, developers, an offshore team, the client's leadership?
• What is a must have and what is nice to have? Most job descriptions list fifteen skills. Usually three or four really matter.
• What went wrong with the last person in this seat? This one question often tells you more than whole job description.

Also ask about the environment. Is the project in build, in testing, or in support? A strong builder can be bored and restless in a support role, and a steady support person can struggle when there is no design yet. Same title, very different person.

If you are a vendor, this is where you add value. Plus the prime or client will notice that you asked. Vendors who send three well matched resumes get more interviews than vendors who send ten keyword matches.

Look for evidence of delivery

Ask for the story, not the list

The best screening question I know is simple: "Pick one project on your resume and walk me through what you personally did." Then keep asking. What was the problem? Who asked for it? What did you build or write? What went wrong? How did you know it was done?

People who did the work answer with names of systems, real decisions and small details that nobody would invent. People who were only near the work stay general. They say "we" for everything and cannot tell you what "I" did.

Check that the details hold together

Look at the dates, the team size and the scope. Does a two month contract really include "led the full cloud migration"? Does a junior title line up with "owned architecture for the enterprise"? Small inconsistencies are not always a problem, but they are a reason to ask. We cover the bigger warning signs in our article on red flags in IT candidates.

Ask for work samples where it makes sense

For analysts, a redacted requirements document or process map. For developers, a walk through of code they wrote or a public repository. For testers, a sample test plan. Not every candidate can share these, and that is fine, but the ones who can usually stand out quickly.

Judge domain fit honestly

Domain experience is sometimes everything and sometimes not much. A claims system project needs someone who already understands an 837 and an 835. A CRM rollout for a hospital marketing team probably does not. The mistake is treating every requisition as if the domain is a must have, and then rejecting strong people for no real reason.

So decide this during role clarity. If the domain matters, screen for it first and test it with real questions. If it does not, focus on platform skills and delivery. We go deeper on this in healthcare IT versus general IT consultants.

Test communication early

Most IT projects fail on communication before they fail on technology. A consultant who cannot explain a problem to a business user, or who goes quiet when they are blocked, will cost the team time every week.

You can test this in the first call. Ask the candidate to explain a technical concept to you as if you were a business stakeholder. Ask how they handled a stakeholder who changed requirements late. Notice if they listen to your question or answer a different one. Also notice how they write. Their emails and messages during the process are a preview of their status reports.

Use references and trial questions the right way

References are useful only when you ask the right person the right thing. A colleague who sat next to the candidate is less useful than a manager or a client lead who saw their output. Ask specific questions: What did this person own? How did they handle pressure near a deadline? Would you hire them again for the same kind of role?

Trial questions work the same way. Do not ask trivia that anyone can search. Ask a short scenario based on the actual project. For example:

1. Describe the real situation in two or three sentences, such as a failed interface, a disputed requirement, or a report that does not match the source system.
2. Ask the candidate what they would check first, and why.
3. Add one complication halfway through and see how they adjust.
4. Ask what they would tell the business user at the end of the day.

Ten minutes of this tells you more than an hour of "tell me about yourself".

Put it together in a simple scorecard

To keep everyone honest, score each candidate on the same few things: role fit, evidence of delivery, domain fit (if it matters), communication, and reference quality. Write one line of evidence next to each score. When a client asks why you submitted this person, you have an answer that is more than "the keywords matched".

At iCareTechno we screen this way for every requisition, whether it is a developer, a business analyst, a project manager or a healthcare IT analyst. If you want to see how we work with clients and vendors, take a look at our IT staffing services.

Written by

Israr Kazmi

Israr Kazmi is the founder of iCareTechno, the IT staffing, recruitment and consulting division of iCareBilling LLC in Chicago. He writes about hiring, vendor relationships and careers in IT.

More about the author