When I switched from medicine to software engineering I was really surprised by the interviewing process. During my first interview I answered all of the questions correctly, but the CEO did not want to hire me over concerns around: “How can a nurse be good at computers?”. Roll the clock forward and the same person did his very best to prevent me from leaving.

With the best of intentions, the interviewing process is like speed dating.

Do any of these describe your hiring experiences?

• Why do so many of the people we hire struggle to be successful?
• Some of the people we hire turn out to be our most valuable people!
• Some of the people we hire wind up being toxic to our culture :/
• Why can’t we seem to find any good people?
• Why is retention such a challenge?

Resumes provide minimal value

I’ve done hundreds of interviews over the years and for the past few years I don’t really even look at the candidates’ resumes. I’ve honestly found pretty much zero correlation between a resume and what the candidate can do (or actually wants to do).

When screening for a software engineer I try to jump into coding as quickly as possible. I find it pretty terrifying how often candidates (with glowing resumes) fail my challenging questions:

How would you print a string to the terminal?

Acceptable answer:

print(“hello world”)

> How would you print the contents of a text file?
>
> ```
# Acceptable answer:
with open("/etc/services") as fh:
    for line in fh:
        print(line.strip())

Sadly, many candidates struggle with basic questions like this. More often than not I’d say the candidates produce code that’s not even remotely close to being syntactically correct. It’s pretty unfortunate. One suggestion to improve this would be to ask simple technical questions earlier in the process, for example:

• What happens when you add 1 plus “1”?
• How would you write a function that prints “hello world”?
• How much time does it typically take for https://google.com to load?
• How exactly do you determine how much memory your program is using?

Interviews don’t capture culture well enough

When candidates are able to write code in their language of choice, the next goal is to try to interview for culture fit. My experience has been that this is extremely hit or miss. The stress of interviewing alone can cause someone to act differently than they would normally. A few examples of culture that often get missed:

• How does the candidate actually respond to the code review process?
• Does the candidate wind up focusing more on finding problems than fixing them*?*
• Does the candidate have a good balance of idealism and pragmatism?
• What happens when the team doesn’t agree with the candidate?
• Can the candidate ship things?
• Does the candidate support the things they ship?

Requirements are often wrong

I can’t tell you how many people I have spoken with that intend on asking questions around sorting, data structures, and algorithms to a person interviewing for an SRE position. Similarly, when interviewing for a machine learning expert, interviewers forget to ask them questions that asses their ability to do the basics (things like Git or using a terminal).

An interview should have emphasis on what the person would actually do for the job.

Ideas on how to improve things

Trying to get hired

Provide links to work you have done. These examples should actually implement the basic things that all good software should involve:

1. Source control management (example: Gitlab or Github)
2. Codified build process (example: make, gradle, even a shell script, whatever is idiomatic)
3. Tests that provide value
4. Documentation (even just a decent README.md will suffice)
5. Build process (example: Travis)
6. Release process (containers, platforms, archs, oh my!)
7. Downloadable releases (my example)

These are some of the most basic things that all companies have, and we live in a modern age where you can implement these using free online services. Sending a link to this provides orders of magnitude more value than a resume. Bring your laptop to the interview, and be prepared to show code you’ve actually written (as long as doing so doesn’t violate any legal or ethical rules).

Trying to hire

Post what you’re actually looking for, and be prepared to demonstrate how things work internally. For example the next time I interview at a company I expect to ask questions along these lines:

1. Can I see something along the lines of git log --oneline --since="last week" for of your popular repos?
2. What are the engineering goals?
3. What has been the response to poor performing staff over the last year?
4. How is performance measured?

Ask questions that might give you a sense of “who they are”. Here are a few example questions I’ve used in the past:

• What blogs do you subscribe to and how do you find them?
• What is your preferred editor, and how do you manage its configuration?
• If you get a new laptop what kind do you prefer and what would you do to set it up?
• What tools/techniques/things are you playing with at home right now?
• How do you backup your personal computer?
• How did your last on-call rotation go?

They might sound like silly questions, but if you’ve never tried questions like these you might be surprised by what you hear.

Stop obsessing over algorithms

This one is potentially just a pet peeve of mine, but I’ll describe it anyway. The process of interviewing a software person almost invariably involves assessing basic skills. For the majority of companies this means asking questions about data structures and algorithms. I would argue these are not basic skills at all. Basic skills are things like:

1. Setting up a computer for use with developing software
2. Editing software and knowing how to test it locally
3. Familiarity with the review, build, and deployment process
4. Knowing how to instrument code to expose metrics (Prometheus or the like)
5. Having a desire to gain team consensus on design before implementation
6. Basically the same things the candidate should have sent you a link to!

Once basic skills are assessed it’s time to move onto domain specific skills. Here are a few examples of what I mean by that:

1. Describe infrastructure via markup that can be consumed by a tool to consistently create the infrastructure it describes.
2. Create a two column layout where the right column contains rows that might expand vertically.
3. Consume radar images and filter them for noise.
4. Design a data store that could help keep track of what’s happening in a production line (say cars or something).
5. Be aware of the details about zero-day exploits released the previous day and if they impact us.
6. Create a mechanism to load balance traffic for a service that’s mid way through a migration from old to new infrastructure.
7. Create a queue that supports specifying message priority.
8. Describe the type of queue you’d need to solve a particular type of problem.
9. Design a search algorithm for a particular type of data.

If you happen to think all of these are best measured by asking questions about data structures and algorithms… you are mistaken. Sure there are lots of roles where these skills are essential, but there are also lots of roles where an algorithmic genius would fail practically.

Focus instead on take home coding exercises

Instead of trying to determine if the person can code on a white board, try to simulate how coding actually works. Maybe something like this:

1. Come up with a problem you actually have, and write up the requirements.
2. Give these requirements to the candidate.
3. See if the candidate wants to discuss the design before implementation.
4. Let them implement the solution on a computer, with coffee and headphones… like all good software is written.
5. See how they iterate, document, test… (all the things).
6. See how the code looks and if you like it bring them on site.

This might sound crazy, but I think these ideas would work better than what most companies do today. The process is also expensive, but how much does it cost to manage an employee who’s not successful? If the candidate isn’t interested in solving a problem you actually have, then that’s information itself - right? If you don’t believe this idea can work I challenge you:

If you happen to be looking for a Go programmer and have an interesting problem, I just might take vacation and solve it ;)

You’ll (potentially) get a working solution to your problem, the candidate would learn a lot about your company - who knows what might happen.

Final words of wisdom

1. Expect the candidates linked code to be lacking and imperfect in countless ways, just like the code at your company.
2. If you found any of this interesting let me know. I play well with others :)