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 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.
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.
“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.
Their first email response back to me was an offer which I accepted.
- 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?