Uncharted Waters

Nov 14 2019   12:53PM GMT

The Resume Problem

Matt Heusser Matt Heusser Profile: Matt Heusser


SQL Joins ImageLike it or not, resume inflation is a real problem in Information Technology. Those that are willing to lie a bit are rewarded with better jobs and more money. If you are honest, leaving terms off your resume because you do not know the tech, you might not even pass the keyword-match algorithm. More than one person told me that resume inflation is just expected. “People say what they need to say to get in the door”, goes the chorus “You use the interview to figure out who they really are.”

Which brings the next problem.

How exactly do you figure out who cuts the mustard?

Earlier I suggested we have a crisis of confidence in software development that is leading to a lemon market. My suggestion was an audition. The simplest audition for a programmer-type may be to ask them to solve the simplest of programming problems in a language they claim competence in. Personally, I am a fan of SQL. When you think about it, SQL is basically venn diagram converted into a grammar something between English and set theory from Mathematics.

They claim SQL on the resume. You ask a simple SQL question. Start with an employee and job table, which share a job_id in common. Write a query to find all the employees with a last name of “Smith” and their salary, which is in the job table.

I post it on twitter … and then things go sideways.

SQL Interview No Good

The imperfect audition

People objected to my interview question for several reasons, including –

  • Hire for the person, not skills
  • I wouldn’t want to work for that manager
  • Oh, that’s easy to learn. Why get hung up on syntax?
  • In the real world, we’d just google it
  • A lot of people don’t learn SQL as new programmers, and may go years without encountering it.

This is after I clarified the position is senior, SQL is on the job requirements, it is listed on the resume, and the complexity of the request is trivial I am not talking about distinguishing between a LEFT OUTER JOIN and an INNER JOIN here. I’m talking about writing this query:

Select employee.first_name, employee.last_name, job.salary

From employe, job

Where employee.job_id = job.job_id

and last_name = "Smith"

What is going on here?

Problems with the SQL question

Okay, folks, the SQL problem isn’t the best; my bias is showing. It’s hard to say this without bragging — I haven’t used SQL on a daily basis in eleven years. I’ve gone on to do a lot of things. In the past two years, I probably spent twenty times the effort in quickbooks and accounting software than I have writing queries.

The only way I can imagine not being able to write such a query is if I had a traumatic brain injury or some other reduction in my intellectual capacity. This is … silly.

Then again.

Every time I believe I am right, and nearly every response is against me, it is an invitation to pause and reflect. It doesn’t mean I’m wrong — but I do respect my peers. Graham Harvey worked hard to get where he is, as did Tim Ottinger and Lanette. I don’t take their responses lightly.

Perhaps SQL simply is not as relevant as it was early in my career. Perhaps my years of working for an insurance company driven by databases impacts how I see the world. I might put REST API’s on my resume, yet fail at a trivial basic-auth API problem, able to solve it but “with a little help from google” in precisely the way everyone on twitter responded to my SQL comment.

Clear up the resume

When hiring a programmer, it’s easy enough to ask them to solve a simple abstract thinking problem. A sample problem involving iteration and selection, which is a fancy way to say “for”, “while”, and “if.” Along the way, try to figure out if there is a “gotcha” hidden in the problem that involves an unconsious bias. For example, the modulo operator in Fizzbuzz. Ask the candidate their strongest programming language, then ask them to solve the problem in that language. If they switch once the problem is assigned, from the language you are hiring for to what they do at the current job, that’s more than a bit of a yellow flag.

At some companies this might be enough. You might be working on automobile transmissions and have actual pre-defined “specs” that are complete and correct. For everyone else, it is interpretation, communication, and people-skills that will be key to success. In that case, I suggest a full-on simulation, from vague requirements to solved problem, designed to take twenty minutes to an hour. There are plenty of ways to do this. My personal favorite is the in-person interview, but you could do a take-home test.

Not knowing syntax doesn’t mean much. If the candidate can use stack overflow and figure it out in a reasonable time-scale,  that likely means they have less than five years of full-time experience with the tech. Compare that to the claims on the resume. If you have time, of course, you can let them take a few days or a week off of work and come in as a contractor, earning a little money, to see how they work with the team. There are culture issues with that — you’d likely need to be a pair programming shop, or at least open to it. If you give the person a laptop and expect them to work in a corner, by the end of week one they’ll be likely to have JIRA access.

The next problem is the straight-up lies. How do you confirm someone “architected” a system, or exactly what their role was?

I’ll save that for next time.

In the mean time, so you hate the SQL question. Okay. Fair enough.

How do you do better?

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: