Interviews: selling yourself – A contractor's view
Supposing you have made a good first impression and have not yet lost the contract, how do you proceed?
Mike Ferguson, a long-term development and database contractor thinks the interview is the sales meeting. "Interviews are sales. Contractors sell themselves."
Ferguson's technique is to establish what problem the company is trying to solve, and then present himself as its solution. "If you can turn an interview into a consultation then the job is yours," he says.
But I personally think you can run into trouble if you are giving a "consultation" to the wrong person. It is not always the IT manager or even project manager that has the final say, and it's too easy to alienate interviewers with over confidence or disguised criticism of their current plans. You must tread carefully.
One essential piece of advice Robert Wallace gives to his fellow contractors is to make sure you are aware of who is making the buying decision.
"Over the years," he says, "there have been occasions where I misread who had the real power. Once, I thought a human resources interview was a formality and I didn't take it seriously. After half an hour of easy banter, she refused to put me forward for the main project and sent me home."
Make sure you know who is making the decision
The people who together decide if a product or service should be purchased are known as the Decision Making Unit, or DMU. One of the first lessons at sales school is learning how to discover who is in the DMU and their respective roles. Wallace encountered the gatekeeper – people who manage the flow of information to others – they don't sign the cheques, but they have the power of veto.
In contractor interviews, typically technicians are gatekeepers who decide if you can do the job and then make recommendations to project leaders. In this case impressing just the project leader is simply not enough. I have fluffed several interviews because I failed to impress the technologist but got on famously with the project manager. In one case the agent reported I had started an internal argument about who had the real power to hire and fire.
This situation is a real issue for contractors. You rely on your technical skills to do the job but you are aware that your pay master, your ultimate client, is the project leader or technical director. You are a contractor because you have motivations outside the pure technology and job security of the permanent employee, and yet you have to come across as "just one of the team." Permie technicians are quite likely to take a dislike to you on the strength of your tie choice, technicians and PMs are motivated by, and are looking for, different things in a freelancer.
Yet impressing human resources with a favourable attitude can be just as critical for some companies, and it is up to you to, early on, establish who makes the decisions and what the influencing factors are.
The simple question, early on: "How will you make the decision?" is a classic sales line, but using it hardly makes you seem like a hard-nosed perverter of client's intentions. It merely offers a tiny advantage in a sometimes unclear world, and after all, a contractor is a small business person, any advantage should be seized with both hands.
The Salesman and the technician
Let's not forget it is a sales interview. It may be disguised in the traditional business of "they are interviewing you for a job," but your business and your livelihood depend on you making sales to clients. And your product is you.
You must give yourself the best chance of selling into the client company and of meeting your income expectations. Learning a few techniques of the salesperson and applying a bit of common sense can make sure you are offered the majority of appointments for which you are interviewed.
But before we get carried away matching their problems to your solutions and your features to their requirements, remember that IT people are not known for their social skills or their love of sales and marketing, so coming on too salesy in an interview can lose a job just as surely as failing the technical test. A technician gatekeeper will be suspicious of any overt sales technique he spots. You must be subtle.
It's not difficult to be subtle. After all, you know they will buy somebody, the hard sales work has been done by your agent, or you've previously made an excellent sales call to get you where you are, and you are in front of the client. You simply have to make sure the somebody the client hires is you.
Sell your benefits?
Sales people bang on about benefits as if their life depended on it, and most often their job really does depend upon it. The poor loves flit from contact to contact trying to sell while at the same time the sales manager is eyeing performance charts wondering which staff member to fire next. And as if that wasn't bad enough, most of their salary is based on making sales.
But so is yours.
You are in business for yourself.
You are a salesperson.
And a salesperson's mantra is to sell the benefits. A benefit is some tangible advantage a product or service offers to the buyer. In the IT freelance world, the benefits are what your can offer the client. They might include:
- Faster software development
- Controlled costs
- Well organised teams
- 24 hour training
Naturally you have to back this up with evidence, and that comes from your CV and your experience.
Contractor: "I've been working with xWidgets since 2001, and in my opinion many of the perceived problems are due to lack of training and experience. I've trained teams of novices at Fodgets and Bodgets and taken control of implementation for Grumbly Tops Ltd. In both companies there was a 20% reduction in product defects, and I'm certain we could do the same here."
In sales speak, it is called matching features to benefits. The features are your skills and experience, while the benefits are what those features and skills give the client. A feature of this contractor is his 20 year's xWidget exposure, which gives the client a 20% reduction in faults as a benefit.
You might be able to say your knowledge of SQL scripting can glean important business intelligence from impenetrable legacy systems, or your project management skills will help bring a project in on time and to budget.
However, the problem is not really identifying benefits, it's putting it across in interview so it doesn't sound silly, or worse, salesy. I don't pretend this is an easy exercise to do when you are a programmer or business analyst, but trying to think along the lines of features and benefits will get you closer to the mind of your customer. They are only taking on contractors to meet project deadlines or match some business goal they can't achieve with only permanent staff.
A unique selling point
If you can identify the one benefit that singles you out from all the other contractors in the pile on the interviewer's desk, then you have found your Unique Selling Point or USP. It's not to be sniffed at.
It is uncommon for a contractor to be so unique, however. But no one has the same CV and you should make the most of your differences by being very positive about all the experience you have amassed and how they relate to give you a unique vision of the IT world and your part in it. Enthusiasm is infectious.
For a while in my career I identified USPs in my own CV. I was one of the very first contract programmers to have used the Java language for commercial development back in 1995 which lead to several well-paid contracts and excellent experience as a designer. And very early exposure to Windows interface builders added a premium to my rates and an increase in interviews.
If you operate through an agent, it's certain that they will have identified your USP and will be using it to put pressure on the client to make a decent offer. So it's best you are aware of it yourself. But USP is not just about particular skills, it's also about the range and composition of your skills.
How many people combine Project Management with deep Web 2.0 knowledge? Are there other contractors who worked on Artificial Intelligence using C++ for IBM? Does modelling aircraft passenger flows give a unique perspective on banking transactions? I don't know, but somewhere in your CV lies your USPs for a particular role. You should try and identify them.