Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What were interviews like before Leetcode?

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 91 posts

Re: Ask HN: What were interviews like before Leetcode?

#61

Post by vertis »

invalidator wrote: post #49

For a couple decades now, the way I have interviewed people is to ask a simple, very-high-level question, then repeatedly asking either "So how does it do that?" (drill down), or "What happens next?" (back out). For instance: What does 'printf("hello, world\n");' do? Obviously, it prints something, but how does it do that? Pretty quickly you're talking about includes, macros, libc, linking, machine code, system calls…

Yeah, these are my favourite types of interviews on both sides of the fence. A great way to just try to get inside someones thinking. I used to like pair programming interviews as well, where you just implement something together.

We used to do a take-home assignment (which probably LLMs have ruined now) and then extend it further in the pairing interview. There was no one right way to do the assignment. Different approaches (functional, object oriented, tdd/bdd) would all become part of the discussion.

Re: Ask HN: What were interviews like before Leetcode?

#62

Post by jghn »

invalidator wrote: post #49

For a couple decades now, the way I have interviewed people is to ask a simple, very-high-level question, then repeatedly asking either "So how does it do that?" (drill down), or "What happens next?" (back out). For instance: What does 'printf("hello, world\n");' do? Obviously, it prints something, but how does it do that? Pretty quickly you're talking about includes, macros, libc, linking, machine code, system calls…

> Pretty quickly you're talking about includes, macros, libc, linking, machine code, system calls..

Maybe?

> The fun thing is there's no "right" answer

And this is the key. keep an open dialogue. Always probe a layer or two down. Don't enter with preconceived notions of what's "right'. It turns out very few things in our field are binary (har har).

Instead - can they talk shop? Can they demonstrate that they didn't just read some crap from a blog? Is this from experience? Do you like them? Do you think they'll get along?

Re: Ask HN: What were interviews like before Leetcode?

#63

Post by timr »

vertis wrote: post #58

20+ YOE. I've never been fond of whiteboard technical interviews which used to be the norm, I really struggle to draw and talk at the same time. I do fine in interviews normally, I tend to be more of a delivering value for the business kind of developer and strongly emphasise this in my interviews. I'm not writing operating systems and neither are most the other people I work with and hire. These days, I don't do lee…

Also equivalent career experience, including lots of interviewing experience, and I agree completely.

Leetcode problems are almost useless for determining what matters in a professional engineer. But the stuff that really matters (communication skill, clarity, patience, flexibility / lack of dogmatism, taste, constructive criticism, political savvy, prioritization of constraints, willingness to write documentation, reading code and finding bugs, etc.) is not something a new-career engineer a few years out of an undergrad CS program can competently evaluate, because they're probably not very good at these things themselves. And in this industry, that's largely who is doing the interviewing.

Re: Ask HN: What were interviews like before Leetcode?

#64

Post by vertis »

jghn wrote: post #28
PlunderBunny wrote: post #22

We would give interviewees a little sample of code (e.g, a minimal string copy function using a loop in C) and ask how they would make it better, without defining what better meant. Some developers would try to optimise it, others would point out the bad variable names and lack of documentation, or talk about unit tests. It was a starting point for a discussion.

Not really. Some places did that sure. And some places do that now. But the cargo cutled nonsense before leetcode were the brain teasers. "How many ping pong balls can fit into a 747?". Also nonsense.

But the brain teaser is also just an exercise in trying to get a discussion going. Okay so how could I possibly memorise the volume of a 747 and a ping pong ball, and even if you give me that it's a decent amount of complexity to calculate.

But are we accounting for their comfort and making sure they all have TV screens? Do we have to account for FAA regulations? Is it okay if some of the ping pong balls get damaged as we try to fill the aircraft? Are we completely emptying the aircraft or leaving the seats in? Does the plane still have to fly and if so which areas have to be accessible in FAA regulations? What is the weight of a ping pong ball and if you have enough of them does that come close to the allowed take-off weights?

Some of how you respond to these is an indication of how you will respond to challenges and frustrations in the team.

Re: Ask HN: What were interviews like before Leetcode?

#65

Post by sxp »

subharmonicon wrote: post #16

In the 90’s when I was at Microsoft it was common for people to ask brain teasers and algorithm questions and expect people to be able to reason through the problems even if they walked in not knowing the particular algorithm or data structures involved. The interview was graded more on your thought process and ability to make forward progress with hints and less on getting to a correct answer in 25 minutes. People w…

https://www.amazon.com/How-Would-Move-Mount-Fuji/dp/03167784... was the classic book on MSFT interview questions before the software world switched to copying Google's leetcode interview style. Google found that the leetcode questions were the best metric for long term performance because they were a practical proxy for IQ and built their software empire on that style of interview. You can find references to pre-leetcode questions from Google's very early interview prep material from the time before they had data showing that brainteasers weren't as effective as leetcode questions. Then everyone switched to copying Google's interview questions because they hoped to copy Google's success.

The book isn't useful anymore for interviews, but it is a fun read if you like brainteasers.

Re: Ask HN: What were interviews like before Leetcode?

#66

Post by vertis »

timr wrote: post #63
vertis wrote: post #58

20+ YOE. I've never been fond of whiteboard technical interviews which used to be the norm, I really struggle to draw and talk at the same time. I do fine in interviews normally, I tend to be more of a delivering value for the business kind of developer and strongly emphasise this in my interviews. I'm not writing operating systems and neither are most the other people I work with and hire. These days, I don't do lee…

Also equivalent career experience, including lots of interviewing experience, and I agree completely. Leetcode problems are almost useless for determining what matters in a professional engineer. But the stuff that really matters (communication skill, clarity, patience, flexibility / lack of dogmatism, taste, constructive criticism, political savvy, prioritization of constraints, willingness to write documentation, r…

This is true. I'm somewhat disconnected from FAANG and bay area behaviours. Before going wandering most of my career was in Sydney and Melbourne. I think in Australia early career engineers are not doing the interviewing, more tech leads and engineering managers (or whatever we're calling them now, staff and principle?).

Re: Ask HN: What were interviews like before Leetcode?

#67

Post by paulmooreparks »

When I was interviewing candidates in the 90's and 00's, I did the whiteboard thing, but not to implement strtoul (my Microsoft interview) or some algorithmic thing. I'd pick out a recent problem that was solved in our actual code base, clean out anything proprietary, and distill it down to something that could be designed and coded in about 40 minutes or so. That way, I could cover domain knowledge and coding knowledge in a microcosm of what the interviewee would actually be doing day-to-day.

If I were doing it all over again today, I'd skip the whiteboard and bring along a laptop loaded with our compilers and toolchain and any supporting libraries needed to solve the problem. I'd mirror it to the screen in the interview room so we could discuss the solution as we went.

Re: Ask HN: What were interviews like before Leetcode?

#68

Post by riffraff »

tayo42 wrote: post #12
ungreased0675 wrote: post #4

There were riddles and brain teasers. Eventually people realized that people who were good at those weren’t necessarily good at the job. Eventually people will realize the same about leetcode.

this is what i heard places like google asked.questions like how many marbles could fill an airplane. idk if it was just like urban legends though.

I'm pretty sure Google published a list of such questions themselves at some point.

But as I remember it, they were always presented as "show you can think" not "know the answer".

Re: Ask HN: What were interviews like before Leetcode?

#69

Post by delduca »

Just a casual conversation to see if there's a match.

At least in Brazil, some companies still use this approach. My current company does for high level positions, as well as another one where I was interviewed. They include two or three architecture questions, though.

Re: Ask HN: What were interviews like before Leetcode?

#70

Post by ryx »

I work as an engineering manager at a medium-sized company and my experience is fundamentally different from what some of you describe. I gave up to do any live-coding or higher-level algorithm questions at all. For me the main challenge in a software engineer‘s daily work is product problem solving and that’s what we aim for in our interviews.

Especially with recent advances in AI-assistance it becomes more and more crucial to learn fast, and have the ability to apply knowledge to actual problems, no matter where the knowledge originates from. That, solid bug-hunting capabilities and a good understanding of the big picture and the business problem you are trying to solve.

I‘d even argue that nowadays communication skills are much more important than any memorized knowledge about algorithms or a given technology. Communication is what makes you a successful developer, ironically - even when prompting an AI assistant.

Fun fact: 10 years ago I had an exam-like testsheet that I handed out to candidates and gave them one hour to fill it out, including paper-based coding. It makes me feel seriously embarrassed when thinking about that with today's experience :) ..

Post reply on HN