Hacker News Reader

Comment by mtnGoat | Hacker News Reader

Call me crazy but I always focus more on the individual and asking them personal questions more than delving into silly leetcode they learned for the sake of gaming a system and will soon forget.

My company works with a bunch of not so mainstream APIs so if I just waited for experts in everything we work on, I’d wait forever. I’d rather hire good, smart, people and then fill in the gaps in their knowledge. Smart, hardworking dedicated employees are much harder to find than leetcoders. And they learn really quickly with a lot less attitude and grandiose opinions of themselves.

View on HN

Leetcode measures nothing but your most basic understanding of a languages syntax, and your ability to memorize leetcode questions and common interview algorithms.

The only people to ever write a merge sort are either in/preparing for an interview, and John von Neumann.

If someone can fizzbuzz with a for loop, recursion, and a list comprehension, they probably know enough of that language to do your junior/mid-level job. If they get a problem they don't know, throw their hands in the air, slam their desk, and start crying, you may not want to work with them.

That should be the goal of interviews. Not flexing obscure language details or academics. You need to see if you can tolerate/enjoy working with this person, and how they handle a problem they don't understand. More time on the job is spent trying to figure out why this API isn't working, and discussing solutions, than writing sorting algorithms

It measures the most important thing, which is the ability of people to actually write coherent code, a skill which is lacking among many devs. and which is the most important artifact (of many) of an Eng.

...

"Most of the time in the interview, though, should be spent letting the candidate prove that they can write code."

- Joel Spoolsky, the Guerrilla Guide to Interviewing

...

" If they get a problem they don't know, "

Well they should be leeting on something at least a tiny bit novel in the first place, not over the top algorithms, but something that requires a bit of thought. No trick questions needed, just something a bit open ended.

[1] https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...

If Leetcode is solely measuring the lowest bar, what does that say about the people the company is looking to hire?

I guarantee an engineer sitting down with a candidate for just 15 mins will gather way more impactful, insightful, accurate hiring information than any hours-long Leetcode obstacle course ever has or ever could.

Unless that engineer gets them to write some code in that 15 minutes, you're fundamentally wrong.

An hours long leetcode assessment is not the answer, but you need the candidate to have provide proof that they can actually code, and "having a chat about it" doesn't prove it.

You need them to write some code AND have a chat about stuff.

I'm yet to meet anyone that can talk at a high technical level for 45 minutes about any subject, without actually knowing something about that subject.

I couldn't bluff my way through an interview with a senior C sharp developer, and if I'm interviewing a Go or Typescript dev I can tell within about 2 minutes if they actually know the language, and within about 10 how well they know it.

I'm not sure what else the practical code test tells me, apart from how much spare time they have.

"yet to meet anyone that can talk at a high technical level for 45 minutes about any subject, without actually knowing something about that subject."

You're not getting the point.

There are plenty of people with years of developer experience who can talk about things for 45 minutes, quite thoughtfully - and are still terrible developers.

Talking about music is not making music.

Nobody has the ability to judge the quality of a developer after only 10 minutes of talking to them about Typescript.

Knowing some arcane things about Typescript is not a measure of problem solving or coding ability.

"I'm not sure what else the practical code test tells me, "

It tells you something more important than how much they've read up about Typescript.

Typescript is simple / accessible enough, that I wouldn't even care if someone was familiar with it. I wouldn't even make it a requirement for the job even it was a TS focused job.

I would take a 'great all around dev.' any day over someone I knew to be very knowledgeable about TS but otherwise big question marks about their development ability.

Of course, the same holds true for memorizing algorithms - it's a nice signal that someone can do some fancy B-Tree stuff off the top of their head, but not really what you are looking for so interviews shouldn't be focused on that.

Typescript and most of it's best practices (most of the odd corners of TS are not important), can be taught very quickly to any decent dev.

> I would take a 'great all around dev.' any day over someone I knew to be very knowledgeable about TS

Well that's what I don't think you get much in a tech test.

Not many tech tests probe your ability to understand business requirements, nail the acceptance criteria, work with others to develop test cases, or even demonstrate ability to integrate with other services.

Those sorts of skills are what set experienced devs apart from bootcamp graduates IMO. And those sort of skills are easier to talk about than to demonstrate in a single time limited test.

You test those things with your other interview questions. No sensible interview process is exclusively an algorithmic coding assessment.

I'm not aware of any company that does that, but I may be corrected...

What do you think of Google’s process then, where interview questions are constantly refreshed and removed if they’re found to be leaked? I think the weakest form of these style of interviews (boring CRUD companies asking how to find a loop in a linked list) are used to argue against all algorithmic interviews.

Google's interview process lends itself to finding people who really want to work at Google. Nobody would go through that process to work for a small unknown company, even for the same total compensation.

> The only people to ever write a merge sort are either in/preparing for an interview, and John von Neumann.

Do you mean "for the first time and without errors"? I assume that most people should be able to give an overview of how a merge-sort works, and a pseudocode implementation.

> Do you mean "for the first time and without errors"? I assume that most people should be able to give an overview of how a merge-sort works, and a pseudocode implementation.

That’s fine if it’s relevant to the role. But my understanding is that a lot of those interviews, especially at the higher companies require you to get it right, quickly, without issue, under interview pressure. And if you don’t you probably won’t make it past that stage. Also don’t bother trying that stuff for typical CRUD roles at corps that won’t ever require anything those sort of skills, and yes that’s likely. I’ve been in environments where even if strong CS fundamentals could improve the product they won’t let you because it’s not a priority.

Why? It's really only in those contexts that's it's necessary to have it on hand. Unless you're in the context of needing it on-hand, it's trivia.

I wouldn't call it "trivia" but "fundamental knowledge". If the person you're interviewing went through college it should be easy. If they didn't, they probably read about it somewhere (or should have) and can describe it to you.

It's not as much a question to me of whether they've ever seen it, wrote it, or studied it, it's whether they know off the top of their head even which one it is or what the implementation looks like.

> I wouldn't call it "trivia" but "fundamental knowledge".

Something that will never be needed in a career can hardly be called "fundamental knowledge".

I don't remember anything about how merge sort works. If someone wanted to interview me on that, they'd convince themselves I can't code, despite decades of delivering production code.

> If the person you're interviewing went through college it should be easy.

I did study CS in university. A very top CS school, even (CMU). Probably I must've studied merge sort at some point, but the last algorithms class I took at CMU was almost 30 years ago. Not once have I needed that info since then, so it's long long forgotten. Its relevance to a software engineering career is nil.

>> Leetcode measures nothing but your most basic understanding of a languages syntax, and your ability to memorize leetcode questions and common interview algorithms.

90 something percent of people on earth will never be able to do any of that.

90% of people on earth also aren't programmers of any kind

Yeah. So 90 plus percent of people aren't going to be able to do anything like that. Hell 90% of the people who call them selves programmers can't code.

> If someone can fizzbuzz with a for loop, recursion, and a list comprehension, they probably know enough of that language to do your junior/mid-level job. If they get a problem they don't know, throw their hands in the air, slam their desk, and start crying, you may not want to work with them.

That's setting the bar pretty low.

If the candidate is from a serious institution he should be able to manipulate more complex data structures.

I want to talk about code just enough to know you can talk about it. Then, I"m trying to find out if you're curious, knowledge seeking, and refining your craft. I expect everyone I hire to get better over time and on long timespans measured in multiple years these other skills win out over point in time knowledge. Unfortunately, really identifying curiosity and growth mindsets is also hard.

You would think there has been research done in identifying curiosity and growth minds. Anyone? I think having a talk during lunch could answer this.

We are always more interested in their problem solving skills. We give them a very basic exercise like here is a drop down. As you can see, the items in the drop down are not in alphabetical order. We want you to change this at the sql level. How would you figure out how to trace back to the sql query that drives this drop down? It’s amazing how many supposed web developers won’t open the developer tools without our prompting them. And then, when they get in there it is obvious they have little familiarity with the developer tools. How exactly do people do web development without using the developer tools? I’ve been doing this for 23+ years and I can remember what it was like in the bad old days before firebug was created. Why would anyone want to continue to work in that past? Anyway, off tangent, it is interesting how even a very simple exercise, with lots of hand holding, can show a lot about people’s abilities to think through a problem logically.

This is a very good, practical solution to the problem (at least for junior web dev candidates)

The whole leetcode thing is atrocious. People practicing months to leetcode instead of working on actual projects. People who do actual work will fail the interviews.

What about the people who don't do actual work, but have a decent CV and a good story about how they do?

Have you ever experienced what it's like to try and hire decent developers or are you only offering the candidates' point of view?

In my experience more than 50% of the applicants who make through to an interview are the kind I describe in that first sentence.

Yes, I am interviewing, but I'm offering a real world problem to solve for candidates, not an exercise picked from Leetcode. I actually enjoy Leetcoding type problems, so I'd love to grind those, so I as a candidate don't have problems with those - although still I'd rather be building stuff.

The real world problem most of the time resembles understanding instructions, navigating in an existing codebase, implementing some feature. This gives really good insight into how much they've built, how much they know or how much potential they have - for example if they are unfamiliar with some things, they are always allowed to Google and if they do it efficiently, that's very telling about their potential.

With Leetcode you won't know whether the person has actual skill or experience to build something or they just practiced Leetcoding for 6 months straight.

Yeah I can’t tell whether I should put my limited energy leetcoding or working on contrived side projects in tech that’s not even a good fit just so I can put it on my resume to get past the screen.

>I'd wait forever

The biggest hires, like Microsoft, Amazon, etc - are fine with this. The core of the problem is companies become Uber corportizized, entirely separating employment from the work being done. Where HR are filtering resumes based on criteria they learned in university that applies to traditional jobs like accounting. Big corporate works despite inefficiency, due to economy of scale and control. Therefore they will wait and wait, and if they can't find a "senior full stack programmer 20 years in rust", then no matter - they'll just up the work on current devs and ultimately let the project fail because they can.

Good for them, but not all of us have billions and can wait for years for the perfect candidate while also constantly complaining about the lack of skilled developers. Some of us just train our own instead and get on with our lives.

Delving into the individual is complicated because it brings up enormous amounts of pop psychology. We're not as good as evaluating people as we think. It's nary impossible to tell how competent someone is in a discussion, really what we can see is their communications skills, presentation, confidence, and maybe EQ/general intelligence and hints of subject matter knowledge.

Leetcode, far from silly, is far more likely to get an idea of whether or not they can do the job ahead of them.

Joel Spoolsky speaks to this directly: get people to code.

In my younger years, I noticed that there was zero correlation between the quality of code of all of my mentors/seniors and their work ethic, composure, communication skills etc..

Great, thoughtful organized thinkers who could barely code. Great leaders with lazy schleppy code. Obnoxious weird guys obsessive over absolute perfection (to greater or lesser extent).

Leetcoding on completely irrelevant or arcane things is a waste of time, but given a very straight forward, general problem which 'homework' wouldn't have helped with - works well.

A big misunderstanding about leeting is people think that the problem being solved is 'test worthy', like an exam - and really it shouldn't at all.

The other issue relates to people's ability to slog through documentation and find solutions to tricky problems because that's what we do 1/2 the time but is harder to test.

Someone who can take basic requirements, understand them, communicate the tradeoffs, and write something approaching 'clean code' after a couple of iterations - that's worth gold. It also requires kind of a 'rounded experience' with a bunch of tech so that they have at least a bit of intuition for it.

I honestly feel the best devs are not the one's extohlling some kind of genius, or deep knowledge, but rather more of an 'extreme common sense' where they can absorb all of the fuzz of a situation and produce something simple and coherent.

I feel the 'personal' issues relevant will also come out well enough during some basic leeting, though obviously that part of the interviewing has to be done.

I absolutely disagree with this. Engineers are perfectly capable of walking through a problem with a candidate and almost immediately measuring their ability in how they approach it. In fact, I would argue that engineers are the most qualified to assess a candidates engineering ability.

If the contention is that Leetcode measures the bare minimum, the lowest bar, the 100-course material, then what does that say about the people who are being hired? An interview should be far more nuanced and compassionate than that.

Well you're disagreeing with the best practices of the industry.

Spolksy articulates it well here [1]

"Engineers are perfectly capable of walking through a problem with a candidate and almost immediately measuring their ability in how they approach it"

Software is not Engineering in the classical sense, and almost zero software is Engineering, and almost zero developers have a formal Engineering background.

The material reality of Software is understanding problems spaces and producing coherent solutions, sometimes at different scale, sometimes using different bits of tech, but a degree of coding ability is definitely a necessary aspect.

So if we adjust your statement: 'Only a developer can judge a developer' - of course - that's the point of leeting.

In what scenario would 'talking' in abstractions about something be more useful than 'actually doing it'?

Coding is a huge part of the job. Of course, it's not everything, and some devs. may have really strong skills and yet a narrow view of things, but that's actually easier to change.

Getting along is important as well, so that's why we have an interview ... but there's no avoiding leeting/close whiteboarding.

[1] https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...

Reply on news.ycombinator.com