A short list of software hiring don’t’s

18125b

Is it hard for companies to figure out how to hire good software engineers? Apparently so. A dev manager for one of the top fifteen startups in Seattle told a class I was attending recently that even finding good candidates in the first place is difficult: anecdotal evidence reports that companies sift 200 resumes using automation and/or manual inspection, call ten people, interview four on-site, and hire just one.

Companies can’t control the pool of applicants but it is surprising to find that they aren’t better at things they can control like being professional, courteous, and all those things you would imagine a company would be when trying to attract good employees. I recently went through a job search and experienced outright bad behavior from certain recruiters, interviewers, and hiring managers. The majority was great. There’s no doubt that most people don’t have a problem with this. But there are some who stink at it. It would be no wonder if it is hard for these people to find good candidates. If you are part of a team that’s trying to hire someone, learn from my experiences and observe this list of DON’T’S!

DON’T tell candidates that the job is for one thing when it is for another.

Even worse: don’t entirely neglect to tell them what position is being offered. You’d think that would be kind of important since you want to make sure that the candidate has all the information to decide whether or not to advance themselves as a good candidate for the particular position in question. “Software Developer” or “Software Engineer” is not a one-size-fits-all role.

This happened to me more than once. In one case, the recruiter told me that a company was hiring for multiple positions. She explicitly stated they needed Java developers for back-end web services. I agreed to move to a phone screen on the basis of the latter. When I was phone screened, I was asked only in-depth JavaScript questions. I don’t want to do full-time JavaScript development. I could have saved all three of us in the phone screen the hour if there was some honesty up front. In another case, I was told a Java position was what I was applying for, later to find that it was 80% PHP and 20% Java. This stuff matters.

But even worse, in another case I wasn’t told what the company was hiring for at all, besides “software engineer.” I repeatedly asked if there were at least particular skills and technologies they were looking for. Turns out it was a highly technical role where advanced data structures, concurrency, and security were desired. Incidentally, I had told the phone screener in answer to a related question that I did not want to pretend to be something I’m not and that I am not an expert on concurrency. No problem they said. Let’s bring you in for the on-site. But it took going in for over half a day in the on-site interview before I received the information that this was indeed what they were looking for. Look, companies, a little honesty never hurt anyone! Part of being professional is not wasting people’s time.

DON’T be late or reschedule on your candidates.

This is directly related to wasting candidate time. If it happened once in a blue moon and there was a really good reason for it, then that’d be one thing. But if you have a track record at your company of people showing up late for an interview, or going out of the office when they know they have a candidate coming in for one, then something is seriously wrong about your expectation to hire a respectable candidate while not showing them any respect. I have been on the receiving end of both situations. Someone called me for a phone screen over twenty minutes late in one case. And in another, someone didn’t even show up to an on-site interview. Both incidents happened at the same company, and Glassdoor reviews show they have done this to others. Luckily there was someone else there since it was scheduled with two interviewers to begin with. If you don’t respect my time, why would I want to respect yours by working for you?

This doesn’t have to be a loss, though. I had a great experience from a different company when the hiring manager had to go out of town. The recruiter clearly communicated this to me and remained in contact to find out when I was available. There were two options: reschedule or go ahead with an interview at the soonest available time. Ultimately, when most of the team was available but the hiring manager was still out, they decided to bring me in for the interview without the hiring manager present, and all was well. Clear communication saved the day, and I didn’t show up to find someone missing or end up waiting by the phone.

DON’T ask a candidate in a half hour or one hour phone screen a question that rightfully should take longer than that.

For some reason a lot of people want to do this. They don’t ask a design question. They ask for candidates to solve a Herculean design problem. They don’t ask a technical question. They ask a series of technical questions which ultimately result in a full web application. I’m serious. This happened to me. One example was to write the code for a web application which on the back end reads in huge text files in a distributed key-value store and then indexes them, and next provides an AJAX search on the front end. Through Collabedit. Bad form. If you wouldn’t expect your current regular employees to do something like this in an hour, why are you asking for it in a phone screen or a one hour block in a long interview?

For example: design a 911 dispatch system. Design an elevator. These are too big of questions. Someone wrote their PhD dissertation on the design an elevator question.

DON’T set up artificial constraints on a question unless you are clear up front that this is what you are doing.

In one interview I was given an interface with a method that took a Q object and returned an R object. When I asked any questions about Q or R, the interviewer refused to answer, but didn’t explain why.

DON’T be a jerk.

Hard to believe that this has to be on the list. In the same incident with the artificially-constrained interface interview question, when I would ask about objects Q or R, the interviewer would sternly say, “You don’t need to know that.” Or they would say “Why are you asking that?” and when I would explain, they would say “You have the interface.” So this is the behavior I would expect from working with you? See you later!

Another famous jerk move is to pull out a random brain teaser and then let the candidate spend the whole hour trying to solve it. Here is one well-known example. How is each line generated in the below?

0 0 0 1
3 0 1 1
1 3 1 0 2 1
3 1 1 3 1 0 1 2
2 3 4 1 1 0 1 2
2 2 1 3 1 4 3 1 1 0

The answer: each line except the first one states the number of digits seen in the line before it. So in the first line, there are three zero’s and one one, so the second line becomes “3 0 1 1.” Now looking at that line, we see one three, one zero, and two one’s, so we put down for the third line: “1 3 1 0 2 1″…and so forth.

Moving on to lesser sins…DON’T be disingenuous about how awesome your company really is.

Again, a little honesty goes a long way. Every place has its challenges and no place is perfect. If you pretend that your company is perfect and flawless to candidates applying for positions there, you are probably going to set off their red flag radar. Be honest about the challenges. Developers want a challenge anyway.

DON’T ask technical questions that are obscure or esoteric.

Here is where I actually agree with something Joel Spolsky said: “Just for fun, here is the worst interview question on Earth: “What’s the difference between varchar and varchar2 in Oracle 8i?” This is a terrible question. There is no possible, imaginable correlation between people that know that particular piece of trivia and people that you want to hire. Who cares what the difference is?”

And finally, DON’T ask technical questions with ONE TRUE RIGHT AND HOLY ANSWER.

Another label for these is “trick questions,” so long as only one answer is expected and candidates are graded down for answering another way.

I probably will write a whole blog post on this at some point. It deserves the full treatment. There are interview questions out there that job candidates either memorize and answer correctly or they flame out on miserably, but there is no third option. If there is a third option then we are not talking about one of these questions.

One example, in my opinion, is “I have to update the phone number in thousands of static HTML files sitting on a drive. How would you find them all?” The ONE TRUE ANSWER is grep it with a regular expression. That’s great and all, but there’s a lot of options. A really good dev with Python or Perl could probably whip up a script for you to do the find as well as replace it with something else just as quickly. It just depends on the person.

Usually people who ask these questions find them on the internet and don’t think much about whether they will reveal the fit of the candidate for their company and the work they are doing beyond the fact that someone out there said it was a good interview question.

Conclusion

A lot of these seem like common sense but I was surprised at my own experiences and listening to others’ experiences in the industry. Perhaps the reputation of our industry as a kind of wild west is showing a little too much in these examples. For more reading, check out the following links.

Leave a Reply

Your email address will not be published. Required fields are marked *