Stories from my programming job interviews - on both sides of the table.

It’s easy to find people arguing that the hiring process in tech is broken, not good enough at filtering bad hires, favors people who don’t have a full-time job… I’ve been through a few interviews over the years, and I feel like although no process is perfect, it’s not too bad if people on both sides of the table know what to expect and have a plan.

People writing about internships⌗

An Algorithm for Passing Programming Interviews: malisper.me | Hacker News

How to conduct a good Programming Interview: lihaoyi.com | Hacker News

Data Structures & Algorithms I Used Working at Tech Companies: blog.pragmaticengineer.com | Hacker News

Internships as a student⌗

My first internship [success]⌗

  • Company size: ~100
  • Sector: consulting, business intelligence
  • Role: programmer (internship)
  • Referral: yes

The interview process was very approachable: no whiteboard coding, a short questionnaire about my experiences (and “what’s the last book you’ve read?", which we talked about for a while since we both loved the book I mentioned), and a chat with the president. This was a very humane company and we ended up with a group of good people who could work together well.

My first job in a big company [success]⌗

  • Company size: ~150'000
  • Sector: finance
  • Role: programmer (internship)
  • Referral: no

The process began with a 1-hour meeting with the team manager. A few days later, the person who would take charge of my internship took 1 hour to do some whiteboard coding, using simple questions such as:

  • What’s a lambda?
  • How would you sort an array?
  • Can you write a simple function that does X, Y, or Z?

My only regret was not meeting more team members during the hiring process, it turned out to be a sign that the team was not a very close-knit bunch. I ended up being seated on the other side of the office, and they’d forget to include me when going out for lunch, sad :(

At the time, the team didn’t have much of a process for interviews, so the content of an interview would depend on who was conducting it. A few years later, we would set up three big improvements:

  • create a standard list of questions to avoid bias from each interviewing having his favorite trick question
  • give a clear purpose to each of the meetings, to avoid wasting time by going in different directions during a single hour
  • try to make sure a candidate would meet most of the team members before joining This ended up making for an average of ~4 meetings from receiving a resume to hiring a candidate, which was probably not too bad compared to the industry standard.

This internship turned into a permanent contract after a year or so.

Finance in Hong Kong⌗

My first hedge fund [success]⌗

  • Company size: ~30
  • Sector: finance
  • Role: programmer (permanent employee)
  • Referral: yes

The whole hiring process was quite time-consuming, but enjoyable because the interviewers were quite friendly. It went through these interviews while working for another company, using evenings and half-days of paid leave.

First round: a questionnaire. A few pages (maybe 10?) of questions about Python, Linux, git, finance… the idea behind this was to get an overview of what a candidate knew, and what their blind spots were.

Second round: whiteboard coding. An hour of solving puzzles on a whiteboard, using questions that were not too difficult and gave room to explore more in-depth.

Third round: systems design. An hour of designing a system (drawing on a whiteboard) according to the requirements given by the interviewer.

Fourth round: take-home project. The goal was to write a CLI to fetch, shuffle, and display some data from an external API, in a week or so. I then went back to their office, and a few people reviewed my code, asked questions about my decisions and trade-offs, suggested improvements, and asked some general questions about the domain behind this specific project. I felt this project was scoped appropriately for someone who is working full-time and can only find a few hours here and there to work on side projects.

Fifth round: a phone call for a personality check by one of the senior employees.

I did meet most of the employees during this process, however, I didn’t meet the person who would end up being my manager, which in retrospect I should have made sure to do. I was fired from this company after ~2.5 years, which I believe shows no process, no matter how many steps it involves, can guarantee a good hire.

Rebound after being fired⌗

A discreet but serious hedge fund [failure]⌗

  • Company size: ~30
  • Sector: finance
  • Role: programmer (permanent employee)
  • Referral: no

This one involved a weekend project, writing a small C++ program, and sending it to the interviewer for review. Most of the problems could be solved by using the right data structures from the standard library. I also used CMake as a build system and dependency manager, and added some logging (using spdlog), tests (using GoogleTest) and micro-benchmarks (using Google’s Benchmark).

The second step was to spend a day in their office, roughly from 10:00 to 18:00, with a different person every hour asking questions on programming or trading. They invited me for lunch, which was very nice. Overall the process was rather enjoyable most of the interviewers knew how to drive a good conversation, although it amounted to a full 3 days of work, which would have been difficult had I not been unemployed at the time.

In the end, they decided to pass on my application and look for someone more senior with better knowledge of low-latency infrastructure and programming.

A famous hedge fund [failure]⌗

  • Company size: ~1'400
  • Sector: finance
  • Role: programmer (permanent employee)
  • Referral: no

The first step was an online coding interview using some Hackerrank/GoogleDoc hybrid website that allowed the interviewer to set up some problems, let me write code to solve them, and see my answers. This was for a Python programming role, so the questions focused on Python basics (how to pass a lambda to a function, how to use standard data structures, how to use decorators and context managers…). After receiving positive feedback from the interviewer, I was invited to the next round.

The second round was a phone call with the team manager, a business person (not a programmer). This was a bit more awkward as I didn’t have to answer that many questions - the interviewer spent a lot of time explaining how great the company was, explaining how overtime and lack of social life were expected. I didn’t receive any feedback from this round, but I was still invited to the next one.

The last round was a phone call with a high-level manager in the fund’s home country. The main question for this interview was: “Tell me about an impressive project you’ve worked on”. I can see how this can be a great question for some candidates, however at this point, I’d mostly worked on what I was asked to, and I didn’t consider any of that impressive. I could tell the interviewer thought the same.

In the end, they came back to me with the news that they didn’t think I’d be able to handle the job.

Google, during COVID-19 [success]⌗

  • Company size: ~140'000
  • Sector: Tech
  • Role: programmer (permanent employee)
  • Referral: yes

Much has been written on the internet about interviewing at any of the GAFA(-M, -N, etc.). My best friends while preparing for the interviews were Hackerrank, and Steven Skiena’s “The Algorithm Design Manual”. I focused on simple trees, graphs, sorting algorithms, and some basic dynamic programming, thinking that having solid basics would help me face most of the questions I’d be asked. If I couldn’t solve a difficult problem after 45 minutes, with help from my interviewer, so be it. I would read the chapter on a given topic from Skiena’s book, and implement the code in Python, writing some tests along the way to make sure my implementation was correct and I understood what I was doing.

After the initial “coding on Google Docs” filtering interview, the whole process had to take place remotely because of COVID-19, most of it in one day.

The coding interviews were very nice. The questions all started simple, and as I solved each step, the interviewer would add a new one on top (eg. reduce complexity, reduce memory usage…), until I either finished the problem or ran out of time. There was no big surprise, the questions were solvable using standard data structures and algorithms. In my case, I had to work with binary trees, basic graphs, and logic.

I probably flunked the systems design interview by over-engineering my solution from the start. Luckily the interviewer guided me back to a simpler solution, but by then I had wasted a lot of time. I guess the lesson here is to try to solve the problem, not recite design patterns.

The HR/personality interview was quite pleasant, nothing tricky, just a good conversation.

After a few days, I received the good news: my application would move on to the next step, ie “finding a team”. I had a few phone calls with managers (as I mentioned earlier, always meet the manager during the hiring process!), and ended up receiving an offer shortly after.

The experienced candidate who could not code [interviewer] [no-go]⌗

This candidate showed up with a decent CV, with a decade or two in large companies working on projects that looked serious. However, after 30 minutes of effort we still hadn’t finished solving this puzzle:

/*
 * Reverse a string. Feel free to use raw pointers,
 * the STL, Boost, or any common library you like.
 */
/* type */ reverse_string(/* type */ str) {
    /* your implementation */
}

It turned out this candidate was looking for something more on the management side, whereas we were explicitly looking for a C++ programmer whose main responsibility would be refactoring and adding new features to an existing codebase.

This was a lesson in filtering candidates properly before wasting their time making them come to our office.

The candidate who was good, but also not good [interview] [no-go]⌗

This candidate had a pretty solid resume, almost a decade of relevant experience, and I was very happy with the result of a technical interview I put him through. However, two other colleagues interviewed him right after, and they felt he wouldn’t be good enough for the team.

It turned out we had asked wildly different questions… because our two teams worked on very different projects. My team needed to iterate quickly on simple projects, so I asked questions about basic data structures, using the STL, and testing code. My colleagues worked on low latency software, so they asked about memory models, kernel bypass, and advanced optimization techniques.

Our manager took all of our feedback and ended up not going further with this candidate. My team decided to standardize a set of questions depending on which project the candidate would be working on, as we didn’t want to reject other potential good hires just because they didn’t satisfy the other team’s technical requirements. This proved to be very useful in the long run, as it also made it easier for people who were interviewing candidates for the first time, and it made our feedback more consistent.

The good candidate who didn’t convince everyone [interviewer] [no-go]⌗

We had a candidate pass our coding interview with flying colors, and the 2 interviewers came out of the meeting with a good impression of him. We invited him to meet the team confident that we’d hire him, yet after one hour, most of the team members were not convinced he would be a good fit and had a bad first impression of that candidate’s overall behavior.

We ended up with a “no go”, and it reinforced our belief that it was important for a candidate to meet most of the team before we took any decision, even if they seemed good enough technically.

The one who had a funny CV [interviewer] [go]⌗

I wanted to hire this candidate as soon as I saw the last section of his resume - it had a very funny line. We did however have a process to follow by that point, so we went through a technical interview, a meeting with the team, a meeting with the management, and he ended up with an offer as soon as we were done.

I handled the technical interview and it was great, we solved some quick puzzles on a whiteboard before talking about more general topics like how to serialize data when sharing between processes, what kind of data or programs should keep in memory or a database, what kind of database would be most appropriate, and so on. Although the CV had caught my eye first because of its discreet humor, they turned out to be a genuinely good candidate.