A contractor’s CV lists the platform you use. That establishes a starting point for a conversation, not whether the person has solved the kind of problem you need help with. Building something new, investigating failures and keeping an unfamiliar implementation running are different assignments, even when the technology names match.
To assess IT contractor skills meaningfully, separate technology familiarity from relevant delivery experience, working context and interest in the assignment. The aim is not to find the most impressive profile in isolation. It is to understand whether someone’s experience equips them for the work and decisions you need them to take on.
Separate familiarity from relevant experience
Speaking about contractor matching at Digiventi, Sebastiano Piccinno describes looking beyond technical skills to the person’s interest in the type of project. That includes interest in its sector and scope. He describes CV screening against technical requirements as something AI can assist with, while retaining personal contact to explore expertise and interest.
Turn that distinction into separate questions:
- Technology familiarity: What has the candidate actually done with the platform, language or tool?
- Delivery experience: Have they carried out the kind of change or investigation this assignment requires?
- Working context: What support, constraints and decision-making responsibilities shaped that work?
- Assignment interest: Does the work you are offering match what they want to undertake?
In an ERP context, consultant Francesco Perrotta advises looking beyond a curriculum to the competence demonstrated in the initial conversation and investigating the consultant’s actual project experience. He also connects understanding the business context with identifying suitable solutions. For your interview, pursue the substance behind that experience: what the person understood, decided and delivered, rather than how confidently they describe a product.
Keep this individual assessment distinct from evaluating an ERP implementation partner, where the proposed team and staffing commitments also need scrutiny.
Make the assignment concrete before the interview
Give the candidate enough information to discuss the actual problem. A request for an “integration developer” leaves too much unspecified. Write a short assignment description covering:
- The current system: what connects to what, and what is known about the implementation?
- The required change: what should work differently, or what fault needs investigating?
- Important constraints: which operating requirements, access restrictions or dependencies must be respected?
- Available support: who understands the application, infrastructure and business process, and can they help?
- Decision ownership: what may the contractor decide, and what requires agreement from someone else?
Consider a hypothetical integration between an order system and a warehouse application. Building a new interface calls for a discussion about requirements, data mapping, failure handling and testing. Diagnosing an unreliable interface calls for questions about evidence, reproducing failures and separating possible causes. Maintaining an unfamiliar legacy implementation calls for understanding existing behaviour and deciding how to change it safely.
The stack could be identical across these assignments. The relevant experience is not. Ask candidates to connect their previous work to the particular challenge rather than treating any integration project as equivalent.
Be explicit about internal support, too. Someone who previously worked alongside an application architect and an operations team may have relevant technical experience, but you still need to discuss how they would work without that support. If nobody internally can direct the work, resolve the broader choice between staff augmentation and project delivery rather than leaving that responsibility implicit in an individual role.
Explore decisions, not just project descriptions
Build the technical conversation around comparable work. Ask the candidate to explain the original problem, their own contribution, the alternatives they considered and the constraints that changed their approach. When they describe a team achievement, follow up with: “Which part did you personally investigate, design or implement?”
Then connect that account to your assignment. What would they examine first? Which assumptions need checking? What information would change their recommendation? Ask how they would distinguish between competing explanations for a fault, or between alternative designs for a new interface.
Listen for reasoning you can follow, not simply familiar terminology. A useful answer should let you trace the connection between evidence, a decision and its consequences. Record unresolved questions rather than converting confidence or fluency into proof of competence.
Do not make confidential client documents a condition of the discussion. HeyScoutr’s consultant hiring guidance recognizes that confidentiality can prevent document sharing and suggests a walkthrough of the candidate’s method instead. Ask for an anonymized explanation, with sensitive details omitted. Keep the conversation focused on reasoning rather than asking the candidate to fix your production problem without an engagement.
Discuss interest directly and make the match explicit
Describe the less attractive parts of the work as clearly as the interesting ones. If the assignment involves investigation and maintenance rather than a new build, say so. Ask which parts appeal to the candidate, which concern them and what they would need to understand before committing.
Treat interest as a direct discussion about the assignment, not a personality score. Do not infer it from enthusiasm, sociability or a polished interview style.
Finish by summarizing the match: relevant experience demonstrated, contextual differences discussed, questions still open and expectations understood. Choose against those requirements, not CV keyword density. If you need support finding a specialist for application or integration work, explore software engineering support with that concrete assignment as the starting point.