About 10 years ago, I was show a piece of code (directly from their codebase) which was about 50 lines long and we had a technical conversation around it in which the interviewer asked me the following questions:

- What does this code appear to do (both technically and more importantly in the context of the business domain of the company)

- Are there are any red flags, edge cases, etc. that this code might not cover?

- If I were to rewrite it in the using modern libraries/tooling/best practices, what might I have done differently? High-level - we're not looking for you to physically write syntactically correct code here.

This is the same interview process that I now use on prospective applicants. In a single 30-60 minute dialogue it helps me answer questions such as:

- Can they size up and summarize existing unfamiliar code bases? In enterprise the ability to deal with legacy code is often more common than writing new code

- Can they re-interpret old code using a modern lens? For example if we're discussing JS/TS (requires vs imports, callback hell vs async await, XMLHttpRequest vs fetch). For python (nested lists vs dataframes, simple numpy regression vs pytorch, etc)

- Are they able to communicate and convey their thoughts in a coherent and logical manner?

The process I went through for my current position and the one prior to that were very similar, and pretty close to what I consider ideal.

In both of them, I was interviewed solo by the manager who I would work under, and that was followed up by being interviewed by the team I'd be working on, as a group. The manager was not present for that interview.

In both cases, the interviews consisted of talking about my past work and how I would apply my experience in the position, what sorts of things got me excited, that sort of thing.

In neither case was there any sort of intensive quizzing, but in both cases when the team interviewed me, I was given a trivial coding problem to work (the point being to give an indication of how I think).

In both cases, the interview process in its entirety took about 3 hours.

What I don't know is whether or not my background affects the sort of interviewing I get. I am very experienced and have a fairly impressive resume, so there is little question about my technical skills. That may mean nobody feels the need to test them in an interview situation.

I quite liked my $BIGCORP interview experience, during winter 2020 (read: COVID-19 was raging and everyone was still sheltering in place).

I was fresh out of a degree at Northwestern in electrical engineering, but I had no money and every reason in the world to get a job fast and get the heck out of my parents' spare bedroom. I was probably applying for 30 jobs a day as soon as the semester ended on 2024-12-20.

Four weeks later, $BIGCORP slots me in for a battery of 3 or 4 online tests, all based around things like mathematics, spatial reasoning, etc. They even threw an unknown programming language at me right there, gave me a brief rundown of its semantics, and said "Figure some stuff about quick and answer these questions. Now."

I have a sick side to me that loves these kinds of high-intensity performances, and two weeks after that, I flew out in the dead of a snowstorm before Day 1. Simple, efficient, and took absolutely no prep on my part beyond applying and being the kind of guy I am.

I had a terrific experience working there too. My colleagues were all sharp and diligent people. I didn't even mind the summary execution of the 100% work from home policy - alas, I had to move in August 2020 to be with my fiancee (now wife) in Finland.

I'm a frontend dev. There were a few preliminary phone screenings at first (from HR and the like) that weren't really about my duties. Then I finally got to talk to the dev manager, who asked me some basic background questions (experience, education, etc.). Altogether those didn't take more than like 20-30 min of my time combined.

Then I finally got through to the coding round, and talked to the frontend dev lead for maybe like 15-20 min, and got a realistic take-home assignment (make a simple frontend in the stack we'd be using). It only took a couple hours. A few days later we reviewed it together and he gave me a chance to explain the decisions I made along the way, complimented some parts of it, critiqued other parts (but respectfully and professionally, coder-to-coder, and left room for discussion).

I got the job and ended up working on his team, and it was an absolutely fantastic experience... one of my favorite frontend jobs ever, though I eventually left because of the bureaucracy above the team.

----

So what I liked: Realistic take-home, debrief and discussion. It felt like I was just working on an open-source project with dev-to-dev discussions about what worked, what didn't, and why, and given a chance to correct any issues. It was a lot like the actual code review and PR process would come to be once I got the job. It's much more representative of "will this person work well in our team, on the actual job they're going to do" instead of whiteboarding or grinding out leetcode.

What I didn't like: All the bureaucracy, repeating the same basic interview questions and introductions to a bunch of people who I wouldn't end up talking to again or working with. I wish they just had an interview team with different people all in the same meeting (once), and/or pass information between them as necessary instead of making me schedule separate meetings with different people just to rehash the same few questions.

I remember when I was interviewing for basically an apprenticeship for the job/career I do now. They asked us to prepare and deliver a 10 minute presentation on why we wanted the job, that we were to give after we had completed the interview. During the interview they asked some serious questions but also questions like “imagine you had to find out the weight of a Boeing 747, but you’re not allowed to use scales, how would you do it?”. And then things like “if you could be a sandwich, which flavour would you choose, and why?” - everyone on the interview panel seemed so serious, and so it was quite a weird, and also intense interview. At the end, I gave my presentation, with the last side being a pie chart of all the things I hoped to gain from the job, and then the pie chart morphed into a smiley emoji and said… and “JOB SATISFACTION” at the end they thanked me, and then I heard nothing for 10 days. Eventually they offered me the job, one day I was sitting with one of the guys who interviewed me, and he told me I did the best interview they’d ever seen, and I was like… thanks but what was with some of those weird questions? and he was like…

“Oh… we just wanted to see how you’d react to uncertainty, and ambiguity while in a stressful situation, you did really well”.

I actually think while the questions were not directly relevant to the job I do, it was a good way to test how I’d react in uncertain and stressful times.

I definitely feel stressed at work often, but I never ever externalise it. Even today, I had a situation that was so stressful, I was literally feeling like I couldn’t breath, but I just held my shit together and then when appropriate I left the room to have a drink of water and take a few deep breaths to get myself grounded basically to do it all over again.

I think it’s been the best interview experience because it’s lead to some of the most interesting and personally challenging life and career experiences and even though I don’t plan to be doing the job I do now forever, it truely has been a pretty life changing one and I think I’m pretty lucky overall.

An interview for a backend dev position with a CTO where the only technical question I had to answer was "how would you design a messaging service?". Looking back I find those open-ended system design questions best. They allow you to show your expertise and understanding in various topics and the dynamics of a meeting where you discuss some architectural challenges makes you feel like a partner in the discussion rather than a student during an exam. It resembles real life work environment situations much better than solving riddles or answering some framework-specific questions. It's also two-sided - you may learn as much about the interviewer as they learn about you. Another thing is that it just takes 20-30 minutes and you're done.

I was looking for a promotion within my company. One day when I was standing in the cafeteria waiting for someone else, the hiring manager walked up to me and said, “if anyone asks, I interviewed you.” Best interview I never had.

Tinder a while back. First and largest part of the interview was 3 hours where they left you alone in a room with the task of implementing a few simple endpoints end to end. Then everyone came back and reviewed your solution and asked questions.

I responded to their Craigslist ad via email detailing which parts of their stack I did and did not have experience with. For some parts of their stack I said I have never used this but I have used this similar thing.

Their first email response back to me was an offer which I accepted.