As soon as I could, I participated in the interview process; I would receive my slot on a schedule and ask a candidate questions. I had feelings about what’s right for interviewing — many years of that. In the last six years I’ve done a lot more management, taken on more responsibility, and now run the hiring process for software engineers at my firm.

This post describes my progression from feelings to experience, and hopefully save someone else time in their own process.

Idealistic Sifting

I started interviewing candidates with what I had learned while being a candidate. My outlook could be summed up as the Diamond in the Rough Methodology (deprecated):

  • Read every resume thoroughly. Even the ones that HR and my management say are not worth my time.
  • Try to figure out what a candidate means when the language is unclear.
  • Look at the upside of posted experience and try to make the candidate fit the role.
  • Screen people for an hour or more.
  • Assume that people want to grow in how I want them to grow.
  • No coding tests! Mutual trust. I won’t belittle your self-documented experience.
  • Ignore buzzwords in resume.
  • No gotcha questions in screens.

As I saw it, the problem with interviewers is that they are all jaded and they do not try hard enough. All the advice is closed-minded. You need to respect every applicant.

I stuck to this methodology for too long (years!) after taking charge of interviewing. I thought that the difficulty I experienced in filling roles was a stream of bad luck, and if I worked harder — improved my skill at screening, interviewing — then my approach would work.

I brought in three consecutive poor-match candidates (including one complete fraud), my team was frustrated, and I had to review my process. I’m a compulsive note-taker, so all the data was there, I just wasn’t seeing the trend. I liked these people in conversation! We had great chats about software principles and difficult challenges and… they understood what I was getting at!

A coworker had been recommending adding a coding screen to the interview. Coding screens are demeaning and have a host of problems, but in that moment I was frustrated and conceded that I had to try something new. In those next couple of interviews, I felt like I was becoming part of the problem and I was embarrassed to bring the coding screen up with candidates.

Two months later, I moved it to the beginning of my screen. You don’t have to be leetcode to do a coding screen.

Why is Hiring Hard?

  1. A bad hire can be worse than not hiring.

    The work you had queued is not getting done, and you probably don’t have room in your budget to fix it with another hire.

  2. You can’t find a 100% alignment with your open position.

    You have to compromise, and it’s difficult to learn where. If you use PostgreSQL and they know MySQL and the role is CRUD-backend, it’s no problem. If they know C# and you are a python shop, it’s probably no problem. But there is a limit — and honestly you have a pile of work that needs to be done and you’re behind and you’re not budgeted to train someone up completely. You are, in turn trying to find a candidate that will work.

  3. There are many people trying to get in who shouldn’t be there.

    It is unbelievable. Partial list of categories: people trying to make an unjustified career jump; people who can’t back up their skillset; YOLO applicants; complete frauds. I’ve spent too much time disappointed and even angry at some of these cases, but over time it becomes part of the job.

    Most resumes are going to be passed on, most screens are going to be screened out. The trick is to accept that without becoming jaded.

Current Criteria for Technical Roles

(My perspective is from hiring for small business.)

  • Meets enough of the posted criteria, or is up-front and willing to discuss gaps

This is most of it. Be honest in your job posting. Be up-front with candidates about the job.

  • Will show up to work reliably or be up-front about distractions
  • Will contribute ideas and listen to those of others
  • Will not fall apart if given direction contrary to their expressed opinion
  • Will comment code, write tests, write meaningful commit messages, use JIRA, etc.
  • Knows langauge and toolchains of comparable complexity to what we do

If I catch the candidate lying, the interview is wrapped up quickly.

I still won’t do gotcha questions.

Having a full suite of side projects on Github is nice, but not a problem if you don’t.

Advice for Job Seekers

  • Get a friend to proofread your resume.
  • Do not list technology you can’t explain.
  • Do not buzzword your resume. Right this second (mid-2020), someone who lists “Big Data” is laughable because that was a hot buzzword four years ago.
  • Do not say that you have eight years experience with a technology because you used it once, eight years ago.
  • Having English as a second language is no problem as long as you can communicate.
  • Relax. If you don’t get the job, it’s ok. You don’t want to work at a place that doesn’t want you.

Advice for Interviewers

  • Take notes on every screen. Review your approach and your outcomes. Improve; it’s a marketable skill.
  • Use code screens!
    • I use Coderpad but there are a lot like it.
    • Don’t use algorithms questions. There’s an entire methodology around leetcoding that is both an arms race and a waste of time. Use a simple question from your domain.
    • Don’t use a stock question. I have had candidates try to google questions during the interview.
  • Read all the resumes that come into your organization. There are above-average people who don’t know how to market themselves and are value-plus. Hire them and then accelerate their career.
  • Prepare to be lied to. Don’t take it personally.
  • Don’t become a jaded asshole. There are good people out there.
  • Phone screens save your team time in interviewing. If you bring in three candidates who everyone passes on, you have done a bad job. If you screen a person out, you have probably saved your team time.