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:
- Can you solve programming problems?
- Can you communicate the solution and your opinions? (this is more important
than what your solution and opinions are).
- 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'.
Can you solve programming problems?
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 for 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.
Whatever tool you choose, go get some deliberate practice writing algorithms.
You just have to do a lot of them. There are a couple dozen programming puzzles
you're likely to see during an interview. Someone who has tried many or
all of them would have an advantage.
Can you communicate?
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 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 talking 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
Do you know what's happening in technology?
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,
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
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 October 3-4 at Ancient City Ruby in Jax Beach! I hope to see you there.
Photo by Thought Catalog on Unsplash