What were interviews like before Leetcode?

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.

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?

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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!)

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.

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.

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.

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.

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

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

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.

The same as Leetcode but on whiteboards.

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 : shalomagency247@outlook.com

Thanks.