Ask HN: What were interviews like before Leetcode?

[zkirby]

In the process of recruiting right now and I'm happy to see more and more companies are moving towards non-leetcode style interviews. As a child of the leetcode generation, this got me thinking - what kind of technical questions were asked before leetcode?

Were algorithmic "gotcha" questions still asked? Were the questions easier? Was the bar just higher?

I'm also guessing there was no 'coderpad' or 'hackerrank' - was everything just done on a whiteboard and pseudo-coded?

[subharmonicon]

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 were super harsh about attention to detail, e.g. you had to write code that would compile on the whiteboard and you would get penalized to some degree for making mistakes, especially if there were enough to make it clear that you hadn’t really been using the language you claimed to be proficient in.

[sxp]

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.

[hcfman]

Here’s an idea. What about using a computer, causes that’s what you are going to be doing.

I’m just bitching about having to code a binary search using a white board at Google when I had previously written a search engine and indexed two country’s by a man who wears a cowboy hat to work. (To be fair it was a nice hat)

I didn’t get the job, they claimed not good enough at coding, wtf! Well f*k them then.

[timr]

We had algorithm questions, but they weren't absurd. Whereas you'll routinely run into leetcode "hard" questions in interviews now -- which should be a dead giveaway that the candidate has memorized the answer -- back then you'd maybe get one question that peaked out at about medium. That's about the practical limit for a competent (but exceptional) mortal who hasn't simply memorized a book of trivia.

(And yes, we did these on whiteboards.)

It wasn't that long ago that Joel Spolsky proposed fizzbuzz as an interview screen...and he really meant that you should ask that question. The idea was that you demonstrate that you can write code using a simple test, then move on to more important factors. Can you imagine such a thing today?

[Aurornis]

> Whereas you'll routinely run into leetcode "hard" questions in interviews now

Where are you seeing LC hard questions? I’m in a fairly big Slack where people have been comparing notes on interviews for years. The number of people who actually get LC hard problems is extremely small.

A lot of people will claim they got LC hards immediately after an interview when they couldn’t solve them, but when you ask them to describe the question and someone looks it up, it’s always a medium.

There were also sites where people could report recent LC problems they received from specific companies. Hard questions rarely made the list of commonly asked questions.

The only exception seems to be people interviewing at certain companies in India for some reason.

[jasonpeacock]

I use a fizzbuzz-level question in my phonescreens for all levels of SDEs, and about 1/2 fail to solve it (from a wide range of experience, I've given up trying to predict who will fail).

The other 1/2 quickly solve it and we move on to better stuff.

[tayo42]

ive gotten fizzbuzz or some variation that's a play on the companies name a few times. i usually interview for like sre/devops type jobs though.

[vertis]

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 leetcode. If a company insists I walk away. I have better things to do with my time than memorise a bunch of useless information (for some value of useless).

I'm mostly on the other side of interviews now and am firmly in the belief that you can get a limited set of signals during an interview. The "Thinking Fast and Slow" view is that we're not very good at evaluating people from a gut feeling.

You might think this would push me towards leetcode and other quantitive measures, however I'm much more interested in working out whether you can be good on a team. The last thing I want is an asshole 10x engineer that makes everyone else unhappy. If you can't actually program I'm going to work that out by watching your PRs and you won't pass the probation. I'm not suggesting I do NO checking in the interview, just that I put limited stock in what can be read during this process.

[timr]

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.

[PlunderBunny]

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.

[jghn]

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.

[ThrowawayR2]

Back when a fast microcomputer ran at 25 MHz and had 4 MB of RAM, back before Stack Exchange existed for people to copy and paste from, back when documentation came in a hardcopy book or CD, back when compilers were something you paid hundreds of dollars for, back before there were publicly available frameworks and libraries that were open source and free as in beer, the bar was much, much higher and knowing at least the basic algorithms was the norm. Whining about coding during a job interview would have gotten you laughed out of the room.

[vunderba]

It was usually a combination of algorithmic questions, some riddles, a few technical questions, etc. All of it was done on the whiteboard.

The thing is that at the time there were no books around commonly asked interview questions, online leetcode lists, etc. so the assumption was that the applicant was basically going in cold, and that there wasn't an expectation that they would be able to instantly solve the problems.

It was more important for them to talk out loud so that the interviewer could observe their thought process.

[jaredsohn]

There were ways to get problems, though, such as prior questions for the ACM programming contest. Those tended to be a little harder, though.

Also, topcoder started in 2001.

[alisonatwork]

Companies that liked to do stupid "gotcha" questions still did those, they just expected you to regurgitate the answer onto a whiteboard or (occasionally) into an IDE on a provided laptop instead of a website.

All the other companies did the same as the non-leetcode companies do today. IQ test type things ("next shape in the sequence"), Fermi problems ("how many piano tuners"), behavior questions ("tell me about a time when..."), code review ("look at this [bugged] code, what improvements would you suggest"), systems analysis ("explain the sequence of events that happen when..."), systems design ("draw an architecture diagram of a project you recently worked on and explain it") etc.

[muzani]

Smart and gets things done, by Joel Spolsky: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...

Still a great read. Base idea is that they're smart enough to solve problems and they get things done and don't just blab about ideas which they won't implement. So they'd write code to prove they can get things done.

Brainteasers were okay, but bad at testing the latter. This somehow evolved into Leetcode culture or take home assignments.

[jghn]

"Smart and gets things done"

Hunter & Schmidt 1998 [1] pretty much boils down to this. Their meta-analysis, predating Spolsky, winds up stating that the only useful thing is a combination of work samples & an IQ test. Never the order and that smells a lot like "are they smart and can they get shit done?"

[1] https://psycnet.apa.org/record/1998-10661-006

[invalidator]

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... One question can easily fill an entire interview slot.

The fun thing is there's no "right" answer. Nobody is expected to know everything about how software works, but everyone is expected to know something. This format gives the interviewee the opportunity to show off what they know best, and the interviewer gets to pry in to see how deeply they know it.

I'm a low-level guy so that's the direction I tend to probe. Usually someone else asks a similarly abstract high-level question. One of my favorites is: "Design a parking garage". Again, there's no right answer. It's a prompt for the candidate to show what they know. Very quickly they're coming up with functions and class hierarchies and/or data structures for vehicles, spaces, turnstiles, payment kiosks, figuring out how to pass them around, etc. The interviewer has plenty of opportunities to pry into design tradeoffs, add complications, and so on.

The grand idea is to have a deep conceptual discussion instead of just seeing if they can write a few lines of code. This also demonstrates how well they can communicate. The catch is you have to be sure they give some actual concrete answers in a few places, and aren't just fast talkers.

[cosmodisk]

I do the same. The last hiring I did, I sent them a homework assignment that shouldn't take more than an hour. Then, we started talking about it. I asked to explain what and why was done. The started expanding into the sides areas of the solution. Then zoomed out and we discussed what would be the implications of doing x,y,z in a wider context of the system. The natural flow of the conversation does a couple of things: their social skills and how they approach unknown situations. I've hear plenty of 'I don't know' which was absolutely fine and much better than some fake confidence.

[jghn]

> 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?

[vertis]

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.

[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 :) ..

[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.

[onion2k]

Was the bar just higher?

In web dev interviews, in the UK, the bar was much lower. It was rare to be asked anything that resembled a leetcode question. Everything was focused around the technology stack you'd be using, the culture of the company, and 'agile' (before people called it that).

[dbjacobs]

In the eighties it was completely nonstandardized and depended heavily on each person you talked with. You would typically visit with a company for the day while they passed you around from person to person. One might have you code something on a whiteboard. Another might ask you a brain teaser. Someone would go through the experience on your resume. And another might ask you something like "how would you figure out the number of pixels needed to make this wall indistinguishable from a picture (i.e., retina display)" just to see how you think. Lunch was often where team fit was assessed.

[ungreased0675]

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.

[tayo42]

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.

[newprint]

My interviews in the decade before the rise of leetcode, were algorithmic questions very similar to leetcode. Surprise !!!! I think people are crying way too much about leetcode.

[pg5]

I haven't had to be an interviewee in 6+ years, but I can understand why people are upset. Competing with other applicants who spend dozens of hours per week memorizing leetcode solutions sounds not fun.

[thomasfromcdnjs]

I've been working in startups for around 15 years, remotely for US companies and AU companies. I hadn't even heard of Leetcode until a few weeks ago.

[JohnBooty]

A lot of companies still don't use Leetcode, at least in my experience, so I don't think we need to wonder too hard!

Change hasn't been too drastic since I entered the business in the late 1990s.

Salaries used to be less inflated, so hiring interviews were a little more lax, because hiring a $60K/yr developer is much lower stakes than a $150K/yr developer.

You were also competing against fewer candidates. "Back in the day" before WFH they might have had 10 or 20 applicants instead of 200 or 2000. So there was less automation and more human factor.

There were often still coding exercises. Your portfolio/work history mattered, as it does today.

I think there was much less awareness of "software engineering" (sustainable, scalable processes like source control, CI/CD, etc) as opposed to like, "just hire a guy who is smart and writes code good."

A lot of programming jobs at smaller shops were really kind of like hybrid sysadmin/coding jobs. You might also be fixing peoples' printer drivers and shit, in addition to coding reports and data imports or whatever.

[whitehexagon]

30 years of freelancing and most interviews (Europe) have just been conversations, first with business, and then with a couple techie team members. Which always felt like more of a 'does he fit in' type approach.

The business side along the lines of 'what value can you add', and the technical side was more about describing problems you had discovered, communicated about, fixed, and details about the methodology, or APIs involved.

I rejected interview requests with google et al knowing of the time wasting LC approach. I think most developers are there to solve real world business problems, not rewrite an OS, although actually that is currently my hobby project :)

With AI assist, the focus on solving business problems comes back to the forefront, and the LC can be done by the AInt so bad coder. Or I think it was mentioned here recently that coders will soon be relegated to AI reviewers, what a horrible thought.

In summary ;) I think I'd be interviewing programmers focusing more based on business domain knowledge at this point.

[Delphiza]

Leetcode is significantly overrepresented on HN. Leetcode is barely a thing across most of the world. Mid-career dev jobs in non-FAANG (and their orbiting startups) organisations don't expect people to spend their time studying for leetcode interviews. Leet is definitely not a thing in other industries - you don't interview for, say, a logistics co-ordinator, by making them study and regurgitate logistics theory.

The short answer to your question, and to try and not start up another HN thread on how good or bad differing interviewing techniques are, is that we did things similar to how most recruiters and hiring managers are still doing it across the world. I think the big difference is more around getting to the first interview. Technology means that there are more applicants, automation of filtering (bad), and remote interviews than there used to be in the past. The funnels to get candidates may have changed, but in my experience, once in the final stretch things are pretty much the same as they have always been.

[awill88]

Leetcode?

I find it interesting that there’s an assumption that if you exist in this world as a professional software engineer and are successful by all reasonable measures that it somehow predisposes an exposure with leetcode.

I’ve never used it for interviews not because I put energy to avoid it, but because I don’t think it’s all that popular, or maybe I just don’t interview often enough. If I want a new job I wait until I’m emotionally done with the one I’m at and none of the places I have ever interviewed have used it. What, is it that if you’re not using it today then you’re somehow “behind”?

I don’t understand this post at all. What a loaded assumption. Does it do something only Leetcode can do? Is it some holy grail? I’m just burnt out on this tenor of the community here, as if any of these platforms are seated as some kind of hegemony of “the engineering scene” Yawn.

An interview is and will always be a balance of your technical skill and your ability to present your work and deal with timely feedback. That’s it.

So for people who wonder wtf this post is about, you’re not alone.

[coffeecloud]

> An interview is and will always be a balance of your technical skill and your ability to present your work and deal with timely feedback. That’s it.

An interview is whatever the interviewer wants it to be. Often it’s a probing of your knowledge of data structures and algorithms via Leetcode style questions. Like, very often.

How many times have you interviewed in the last 10 years and for what kinds of positions?

[vaylian]

> An interview is and will always be a balance of your technical skill and your ability to present your work and deal with timely feedback. That’s it.

That's the ideal case. However, reality can be very different. Some companies reach for leetcode-style questions because they don't have a clue how to do the interview process the way you describe it.

> What, is it that if you’re not using it today then you’re somehow “behind”?

That is not something you get to decide. The hiring manager will judge you if you are behind if you can't answer leetcode-style questions. This is not a question of knowledge, but a question of power.

[jacknews]

My first job, I had an hour or so to learn vi, and show what I'd learned, then write a basic program (not much more than hello world) in C, of course using vi.

Second job similar actually, only this time it was their awful proprietary word processor (a Wang clone I think) and it's macros ans PL.

Then for a big-name computer company, a full day of IQ tests, personality tests, 3-4 interviews, whiteboard pseudo-code, team meets, etc - but all candidates processed in a single day and an answer a few days later (I got the job) - not the same as today where it's spread over weeks or months and you might be ghosted at any stage.

[bee_rider]

What would they have done if you already knew vi? Make you use ed?

[cancerhacker]

Mid 90s at Apple, questions were often very specific to the platform. One manager I knew would bring a printout of a macsbug stdlog - basically current stack trace, disassembly around the pc and the state of various system globals, and have you work through how it got there. As platforms have exploded I wouldn’t expect that level of familiarity anymore, but if I’m hiring for a c / c++ engineer I expect you to be able to describe in hand wavey terms what a structure looks like, and be able to write an accurate memcpy (and I don’t care about syntax!)

[erikerikson]

Among the previous techniques were questions like how many apples would fit inside Mt. Fuji. It was an invitation to do some talk aloud problem solving on some unknown answer with the purpose of gaining insight into the candidates cognitive processes. It turned out it was also a heuristic for readership for some science magazines. I was totally surprised by them early in my career and again floored when I learned that some families would discussed such problems in the car. Didn't map to the job so it wasn't a good proxy for fitness.

[efortis]

In 2013, I got asked this question at Yahoo for a Frontend job:

Explain as detailed as possible what happens when I click a button?

——

Around 2004, I recall college friends talking about an exam Google published. I think one question was: What is DEADBEEF?

——

In 2008, the “cracking the coding interview” book was published, and it is like leetcode but the problems are well formulated.

[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.

[coffeecloud]

Unrelated to the original question:

I know it’s unpopular to say here, but I found studying data structures and algorithms to get ready for job interviews made me a better developer.

[Hizonner]

"What have you done?"

"How did you do it?"

"What problems did you encounter?"

"How did you solve them?"

It's not hard to recognize an impostor.

[neontomo]

in 2012 an interviewer asked me what would happen if i removed the <!DOCTYPE html> tag. very unexpected question but i guess it was testing my /very basic/ fundamentals.

[groby_b]

Nope. No pseudo code. Definitely lots of whiteboarding. Lots of "recall arcane facts". (Like "Why did our counter stop counting up at 16M" - the answer being "because you used float for a counter, what's wrong with you")

And definitely lots of algorithmic questions.

Better questions than leetcode, though, because they were usually grounded in an actual problem the interviewer had.

[tamishungry]

M1 here. I used to have those "actual problem" questions for my interviewee, but my parent company's HR said we'd have to stick to questions that would yield better "yes/no" on a candidate than "how they think". In the end we were forced to use LC as a source for questions.

[BadHumans]

The same as Leetcode but on whiteboards.

[mianos]

Too bad you prefaced this with 'Americans'. The rest is probably true. I feel some people love the feeling of power when they are interviewing someone.

If someone can not answer my trick question I want to know why not and what question can they answer that I don't know.

I am looking for people better than me and the inability not to answer my favourite question may not mean they are not better.

The ability to answer leetcode or build something great, from scratch, are without a doubt, not the same thing.

The only unfortunate thing, is many people are bullshitting about their achievements and expertise and leetcode does tend to filter out the worst of them quickly.

[leptons]

>Americans

>They cannot build anything

What are you basing this on?

[jerryjose]

After giving about 3000 job opportunities world wide , our agency is still giving out Jobs and Business loans worldwide.

if you need a job or financial aid kindly contact us now via email : [e-mail]

Thanks.