What can you expect at your first programming interview?

Coding interviews are like kind of like your standard interviews anywhere else, but with a couple of curveballs that get thrown in sometime. And these curveballs are what make them unique.

In my time I have both interviewed many others for hire and I have myself attended many an interview as well. So to answer this question in more detail, I will throw in elements from both perspectives in order to paint a better picture.

They are long...

Across the board, every interview that I've had with a company of any size for a developer position has been a multi-day (sometimes multi-week) process involving meeting with 5-6 people, sometimes meeting with those same people more than once and on different days (very awkward).

This probably has to do with a few reasons, but I'd wager that it really comes down to paygrade. Developers typically tend to earn above the median at most companies due to the more complex nature of the day and the specilization of it. And so companies want to make sure that they are getting their monies worth.

The longest interview that I can recall having spanned 3 different days in a 1 week period, with one of the days being 8 hours long (lots of waiting). Patience is a virtue as they say. I did end up getting that job and spent a fair amount of years there.

Live coding

Every programming interview that you attend will include some form of live coding in front of a group of people. The medium on which you are coding will solely depend on the company of course, though I rarely actually had to code on an actual computer.

Typically a whileboard will do just fine and sometimes even just a sheet of paper (not as exciting). This is a good time to also show off your problem solving and social skills. Talking through things and communicating is definitely important.

From an interviewrs perspective, note  that you probably don't have to actually get the correct answer. But if you are close or around the ballpark, then typically that's enough to show that given more time you would have gotten to a coherent solution.

Mathematical algorithms

This is my least favorite part, both in interviewing and in being interviewed. Why you may ask? Well, because in real life I never really use algorithms. I don't create bubble sorts or heap sorts or binary search trees when I build a website. But, asking those questions seem to be a part of the current model. And it does not feel like that is changing anytime soon.

If you are fresh out of college, then this might benefit you as more than likely those formulas are still present in your memory. I've you've been coding for a few years however, then you might need to brush up and learn to code a BST or red-black tree and pretend like they are amazing.

Puzzles?

Yeap, there's puzzles too. And not fun or easy ones either. But more complex and ethereal ones with no real answers.

"How many baseballs can you fit in a 1969 Camaro?"

"What? uh...2,000? No..20,000...?"

The idea with this being that it will test your logic and problem solving skills on the spot with little to no time to prepare.

Many of the bigger tech companies have become infamous for asking these questions. I personally began the practice some years ago, but quickly abandoned it as I  found that time was better spent asking actual relevant questions, such as "How do you prevent SQL injections?" or really anything else that is relevant to the job at hand.

In a nutshell, this is your typical programming interview regardless of how many years you have been doing it, whether 1, 10 or 20.

Are they perfect or do they make sense? Depends on who you ask or how you define "sense". I still think there are better ways to gauge programming experience and problem solving abilities and in the near future the process will take 15 minutes and you can start working the next day.