by Jake Worth on August 6, 2019

Some folks I know are preparing for their first technical interviews. In this post, I'd like to share what I've learned about technical interviews after several years in this field.

The way I approach technical interviews is a bit backward. It begins with a question: what is a technical interview trying to prove? I've been on both sides of a few, and I'd argue it's the following:

1. Can you solve programming problems?
2. Can you communicate the solution and your opinions? (this is more important than what your solution and opinions are).
3. Do you know and care about what's happening in technology?

Today I'll break down these three questions, and how I might suggest showing a decision-maker that the answer to each is 'yes'.

You may be aware of a blog post titled 'Why The New Guy Can't Code'. I didn't write that post, but I think it suggests a truth: lots of people who want to be programmers struggle with basic programming problems.

This is doubly true in high-stakes situations, like an interview. It's hard to be clever when sitting next to a person you barely know. I wish this weren't a part of the hiring experience, but it is. Not every company has the ability to assign a take-home project, and that practice has its own biases. So in the meantime, it's worth trying to figure out how to handle solving a live problem.

My solution? Exercism.io.

Exercism is an open-source project designed to help people get better at algorithms. You sign up for an account, install a CLI, choose a language, pull an exercise, solve it, and push it up to the site.

Some stop here, but I think that's just when things get interesting. When I push a solution to Exercism, I like to browse other people's solutions. I look for solutions that have many comments or likes. Reading two or three remarkable solutions will teach you something. At this point I often refactor my solution, building muscle memory as I write better and better code.

To make this practical, heading into a technical interview you should be able to infer which language a technical challenge you'd face would employ. Let's say it's Python. If so, take a good look at the Exercism Python track. The question is likely to be very similar to one of those exercises, and require the same algorithmic and problem-solving skills.

Whatever tool you choose, go get some deliberate practice writing algorithms. You just have to do a lot of them. There are a few dozen programming puzzles you're likely to see during an interview. Someone who has tried many or all of them would have an advantage.

Communication is critical at a consultancy like Hashrocket. But it's just as important for any programmer. I feel that the technical differences between one junior developer and another tend to iron out after a couple of years; communication skills help you keep advancing after that.

The way I stay sharp as a communicator is whiteboarding, and a practice I share with my mentees is simple: go to the whiteboard early and often. Go to the whiteboard before you need to go to the whiteboard. Apart from the truth that a picture is worth a thousand words, drawing your programming idea on a wall is a great way to move forward when you don't know what to do.

Bigger picture, knowing how to draw a flow chart, what the symbol for a database looks like (stack of pancakes), or how a nested React tree maps to a hasty drawing of a webpage, helps us all share a visual language. Trying to draw a Redux state update will show you the parts that you don't understand.

There are a lot of ways to practice communication, such as pair programming, giving a lightning talk at a Meetup, or just talking. For me, whiteboarding is a fantastic way to strengthen this skill. And often in an interview, you're asked to whiteboard anyway. It's not scary if you do it often.

Stepping into the programming field, especially if you're a JavaScript programmer, can feel like trying to jump on a log floating quickly down a river. There's so much to know, and it seems like everybody else is so far ahead that you'll never catch up. How can you catch up?

I advocate a passive approach: whatever watercooler you frequent (Twitter, Medium, RSS, Reddit, email mailing lists, etc.), find the aggregators. These are people who read everything-- blog posts, release notes, conference announcements, Twitter fights-- and distill it down into a human-sized product. I subscribe to weekly email newsletters for React, JavaScript, Ruby, and Postgres. Each week, I scan the headlines and one or two articles. You build up a picture of the scene pretty quickly.

I'm trying to prevent a blind spot, like going into an Elixir interview and not knowing that Elixir 1.8 and 1.9 have been released. Is that a dealbreaker in a technical interview? Probably not. But why risk it? Companies that are a few years behind on their tech stack still want to get to the latest stack eventually, and they want to believe you can help get them there.

This isn't a comprehensive list; I'm sure there is a lot more you could do. Having a strong technical blog, a project you are proud of, or some unique background, helps. A lot of these traits get you into a technical interview in the first place. But once you're there, I want to see that you can write code, talk to me, and are living somewhat in the present day on the technology stack you want to get paid to use. To get there, practice algorithms and communication, and read technical news.

I hope this helps somebody in their first or second round of technical interviews. Please let me know on Twitter if there's something we've missed, or how you approach a technical interview.

Also, if you’re looking to practice coding, chat with other devs and hiring companies, and connect with the pulse of the Ruby and React communities, come join us on October 3-4 at Ancient City Ruby in Jax Beach! I hope to see you there.

Photo by Thought Catalog on Unsplash