Hacker News Reader

Comment by CodeAndCuffs | Hacker News Reader

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

View on HN

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.

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.

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

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

Reply on news.ycombinator.com