Dealing with Fake Resumes in IT Consulting and How to Screen Them

Written by Jerry Virgo on 25 March 2017.

Anyone with enough exposure to the IT consulting industry has likely witnessed a newly hired consultant under-deliver and eventually need to be replaced, wasting valuable time and money in the process. Very often the root problem is due to candidates falsifying their resume and/or embellishing details about their qualifications. This is especially more commonplace in IT consulting, where positions need to be filled often – and quickly.

As an experienced IT consultant, I can certainly attest to this, as I’ve experienced this occur first-hand numerous times. Interestingly enough, there were a few common warning signs from the consultants who were eventually let go for performance.

Here are a few of the experiences I’ve had, and how they could have been avoided. These simple validation steps can be accomplished by both technical and non-technical interviewers.

Developers who don’t understand Version Control

Any developer who has worked in a collaborative environment will have experience with at least one version control system – such as GIT, Subversion(SVN), or Team Foundation Server. Many hiring managers simply ask “which version control systems have you used?” or a similar type of question during the interview process. A response will typically be satisfactory, with a list of platforms that aligns with what is shown on their resume.

But is that enough screening to qualify the consultant?

Simply put, no – and I can say with confidence that almost every developer I came across that falsified their resume had no idea how to manage the process for branching or merging version control repositories.

Screening a candidate for their understanding of version control systems is quite simple – just ask a few targeted follow-up questions.

Here are a few examples with some additional details for the non-technical crowd:

Describe the branching and merging process at your last position.
Developers with a few years of experience with version control tools should be able to provide some in-depth details about how they implemented new features and coordinated with other developers. It’s also a big benefit if they have worked in environments that had a code review/approval process.
Do you use a version control UI tool or the command line?
- For developers that use the command line – great! Ask them to provide a few common commands that they use (such as checkout out a specific branch, merging branches, or creating a new branch).
- For developers that use UI tools, ask them which ones they have used – this may seem like a simple enough question, but people often prepare for technical questions, not simple questions about version control tools. The most common tools are SourceTree or ones built into IDEs.

Each version control platform has its own unique methods of operation, so I the details I’ve covered have been generic – more technical interviewers that are screening for a specific platform will be able to go more in-depth with commands of operations about their platform of choice.

Regardless, this simple method of screening can be an effective way of discerning if the developer has falsified information on their resume.

Consultants who don’t understand processes and methodologies

The understanding of processes and methodologies extends beyond developers, and is far-reaching enough to apply to just about any technology professional – including project managers, business analysts, and quality assurance engineers, to name a few.

Speaking from experience again, I’ve worked with both technical and functional staff that had little knowledge about industry leading processes, tools, and methodologies, which resulted in poor decision-making and performance.

Consultants purporting to have years of experience in technical environments should be aware of many of the facets of these concepts, and there are many.

Here are a few of the most common concepts:

SDLC – Agile, Waterfall, SCRUM, Kanban
Vertical vs Horizontally aligned development teams
Testing – Unit, Integration, Automation, and UAT
Continuous Integration
Microservices and Service Oriented Architecture
Design patterns such as MVC or MVVM

Now here’s where screening these skills get challenging – not every consultant will know all of these concepts, especially if they’ve only worked in environments with less modern architecture (often on both ends of the scale – either enterprise or smaller development environments). This doesn’t necessarily detract from their technical or functional capabilities; they just may have not been in these types of environments.

There are two important factors on screening a consultant for this information. First, if they list any of these on their resume, especially if it’s in a description of a specific job, they should know more than just face-value information. Second, if the job requires these skills then it’s likely important that they have similar experience.

Again, the process for screening candidates on methodologies and processes involves asking follow-up questions, digging deeper into their knowledge of the topic.

For example, a consultant who has been in an Agile environment should know in-depth knowledge of creating stories, pointing systems (which vary in implementation) used in planning, and sprints, to name a few. In regards to testing methodologies and frameworks, anyone working within a team should know specifics about frameworks and implementation of unit, integration, or automation testing – although not all environments implement these practices, so it should be specific to what is listed on their resume or expected of the candidate.

More technical interviewers will also be able to ask about specific software and frameworks used or how implementation was handled in past work experience.

The reason why these questions are important is because more companies are moving towards modern architecture and processes – and as they do, they demand more talented resources. Inexperienced or inept consultants usually won’t last in these types of environments, and a strong work history and the ability to describe in detail their involvement in each job they had is an indicator that they actually worked there and contributed positively to the workplace.

Consultants who have another person interview for them

I have some very unpleasant memories about this topic, both from my experience in IT recruiting and as an IT consultant. While the practice is certainly less commonplace than it was 10+ years ago, this is still a recurring problem in the IT consulting industry, and the aforementioned screening methods may not be as effective if you’re interviewing the wrong person.

There are a few warning signs to be aware of:

Difficulty contacting the candidate
When I was working as an IT recruiter, it was actually rather easy to realize when you’re talking to an imposter once you know what signs to look for. Usually the person on the phone is a friend or someone assisting that may have an affiliation through another company, and setting up times to talk with them require a convoluted process of transferring a phone call or putting you on hold constantly.
Difficulty discussing their past experience.
Unless this person is extremely quick on their feet, they will have quite a bit of difficulty discussing past work experience, and may not have the candidate’s resume in front of them to reference. If they seem to be stumbling with answering questions about a particular workplace, ask some follow up questions to see how they respond – the inconsistencies will add up rather quickly, and may even end up with them terminating the call because “something came up”.

There are also a few additional steps that can be taken, and when applied to the other screening methods becomes very effective.

Obtaining copies of their identification, including any overseas identification if applicable, and verifying that these documents are accurate and reflect dates with work history.
Obtaining copies of their educational degrees.
Verifying that their work experience aligns with what is listed on their LinkedIn account.
Performing reference checks with detailed questions about their interaction with their candidate, while also ensuring that the references were fellow coworkers on the same client site, rather than affiliates that worked at the same consulting company.

Conclusion

Implementation of these screening practices are probably the most difficult piece of the process; it requires thoroughness and dedication. As I’ve mentioned several times in this article, the best screening is going to be through a subject matter expert, but even that person will still need to ask the right questions to properly qualify a candidate.

Do you have any additional screening methods that have worked well for you, or any consulting stories to share? If so, sound off in the comments below!