Searching for employment in the Information Technology field usually involves more than the usual job interview to determine whether you are a good fit for the role and the organization.
For the IT job-seeker the in-person interview is not just about being pleasant, eager and knowledgeable about the position and your potential employer. You are almost always asked to prove your claimed technical qualifications in some way. Some ways are more effective and meaningful than others.
The “no technical interview” interview
There are situations in which a technical interview is not really necessary. Contract positions are a good example: you are coming in to do a specific task, a task that you have carried out successfully on previous contracts. The interview in cases like this is often just introductions and verifying start dates and times. There may also be times when the position demands one or more specific certifications and if you have those certifications nothing more needs to be discussed about the technical side of the position.
The technical interview by non-technical people
It is usually a mistake to leave a list of “technical questions” with HR people to ask during a job interview. Having a list of questions does not ensure that the HR people can pose the questions or evaluate the answers correctly. In some cases such an interview can become almost comical. I interviewed for an IT admin job with an insurance company years ago. The interview was being conducted by a couple of young HR people. When they got to the “technical” questions they asked: “How much experience do you have with Compaq servers?” I replied that I had worked with NT Server and UNIX on a few different brands of hardware. They persisted: “But were they Compaq servers?” They rattled off a few more questions, each of which included a Compaq reference. I started looking around for a hidden camera, but they seemed serious.
I did not get that job but I did make a mental note to never apply there again. A bit of laziness on the part of the technical staff combined with a bit of incompetence on the part of the HR people combined to ruin the reputation of that company for me and any of my contacts that heard the story of my interview there.
“Versionitis”
We have all seen job requirements that included gems like “must have minimum of ten years’ experience with SQL Server 2019”. Issues with versions of software can sometimes be more subtle. I interviewed many years ago for a position as a Lotus Notes developer. I had spent the previous two years working with Lotus Notes 4.5 and had done lots of customization with LotusScript, web connectivity and automated emails. I was told during my interview that none of that mattered because the job I was interviewing for would entail working with Lotus Notes 4.6.
Most of us that have been in IT for a while know that software releases are part of a continuum and are not re-invented with each new version, despite what the press releases might suggest. Features are added and bugs are corrected. If someone has worked with multiple versions of a piece of software over the course of a decade, it would be foolish to assume that someone who has worked with only the most recent version would be more competent. If your candidate has not worked with the very latest version of a piece of software, a more reasoned approach would involve quizzing them on what new features they know have been added and how they would use those new features in the position they are interviewing for. Remember also that companies often upgrade to newer versions for security and support reasons and were not even fully using the features that were incorporated into previous versions. For example, at one job I was using Microsoft SQL Server 2008 but most of the code I wrote at another position using SQL Server 7 ten years earlier could have been dropped right in.
But can you “code”?
Lots of people are suggesting nowadays that writing programming code (the language never seems important) should be part of a grade school curriculum. There are “boot camps” that promise to turn you into a "software engineer" in a matter of weeks. It surprises me then, that in all the interviews I have had for IT positions I have only once had a chance to sit down at a computer and demonstrate what I could do. I think that like most people going to an IT job interview, I do lots of preparation including brushing up on the software listed in the job requirements where possible. For example, I once interviewed for a job at a software firm looking for someone with SQL skills. They suggested PostgreSQL experience and an exposure to Tableau would be “nice to have”. I downloaded the latest versions of PostgreSQL and pgAdmin onto one of my test systems along with a trial version of Tableau and practised for a couple of days. When it came to the “technical” part of the interview I was handed a sheet of paper and a pencil and asked to “write” some queries. I have been asked to do this on both paper and whiteboards in the past.
If you want to see your interviewee actually write some code as a test, then take the time to set up a proper environment on a safe machine (you do have a sandbox environment, right?). No one writes code on paper, not even pseudo-code.
I prepped for another interview with an e-commerce company that was using PHP and MySQL. Having just finished a similar project, I went to the interview armed with a bunch of code samples on disk hoping for an opportunity to explain their logic and maybe learn more about the system the company had created. My code samples went unviewed. Instead I was asked that old standby: “Why should I hire you?”
Some guidelines for a meaningful technical interview:
• Have technical staff present and involved in the interview with some prepared, thoughtful technical questions.
• Prepare a realistic test that simulates the role’s everyday environment (have a programmer sit down at a computer and actually write some code and/or troubleshoot code with errors present; have a support person field a couple of help desk requests; have a business analyst conduct a requirements interview with a user; have a systems person check someone’s permissions in Active Directory).
• Oversee the test in-person to observe how the interviewee goes about solving a problem, trying to understand their thought process and the steps they go through, checking their communication skills.
Show some respect for the interviewee by devoting at least as much time to preparing a meaningful interview as they have devoted to preparing for the interview.