Hacker News Reader

Comment by kolbe | Hacker News Reader

"it's less useful as a "this person will excel" test and more useful as a "this person won't fail miserably" test."

This is also an unproven statement with dubious validity.

I come from the trading world where the leetcode equivalent is a brain teaser. After much deliberation, the only thing we could think of for why a brain teaser was useful was that it often proved someone wanted the job so badly that they memorized all the brain teasers. And that type of dedication and drive is what we really wanted.

To me, I don't understand why someone who develops with advanced IDEs, using complex tools and libraries, is in the least bit judged by putting them in front of what is essentially a text editor, and asking them to solve a problem that's of no relevance to their job, using no tools that they're comfortable with

View on HN

You can use all the IDEs and tools and libraries you want, at the end of the day you still need to know how to read and write code. If you can't pound out a FizzBuzz-level without help, no amount of tooling, IDEs, or libraries is going to make you capable of developing software.

Period. If someone tells me they can develop software in a language, and they can't write ~10 lines of code, that tells me they lied. It's like when getting lifeguard certified they require you to dive down to the bottom and grab a brick. Nothing at all in the day-to-day job of lifeguard requires retrieving submerged bricks, but the set of people who possess the swimming skills to be a lifeguard is fully included within the set of people who dive to the bottom to grab a brick.

Thanks for the brick example. I'm going to use that a lot!

Lifeguard here. The brick is actually part of lifeguard training, at least where I'm from.

At least for Red Cross certification, the training is a mix of teaching and test. The basic swimming skills are basically a test, as it's incredibly unlikely that someone would develop those in the 2-3 days that the course runs.

When I was a young lad you had to pass basic, intermediate, and advanced swimming classes before signing up for the guard class. Each class took about two weeks of daily lessons at the local pond.

This qualified me to sit next to a pool in a condo complex where no one ever swam for eight hours a day. Best job I ever had.

It's just as easy to analogize it as picking up a brick is to lifeguard training as it is to say it's swimming in melted chocolate is relevant to lifeguard training.

Your question has no scientific justification. It just is a problem you can do, and you like yourself and think you're awesome. So you think it finds people like you. But even that isn't scientifically supported.

If you think trying to use machismo like declaring your opinion as fact with a "Period" emphasis is somehow a substitute for evidence, then you're talking to the wrong person.

I'll take someone whose Github repo shows talent, dedication and passion, but who misspelled an include header in their brain teaser over the inverse any day of the week. But you do you. Neither you nor I have a lot of evidence to support our preferences either way.

You are either deliberately misinterpreting what I'm saying, or are unaware of just how muddy the hiring pool is for software jobs. If you post a software role, you will get a significant number of applicants who will struggle to write FizzBuzz. Not on grounds of misspellings or missing semicolons: they genuinely have no idea how to code. If you have them code for you, it's really not hard to spot.

Digging through a couple GitHub repos is a good way to find good developers versus poor ones. The goal of a leetcode question is to separate the developers from the non-developers. And you can do that pretty adequately with 2 questions: "Tell me about something you've worked on" and "Hack together a solution to this trivial question".

Anyone who hasn’t sat in the interviewer’s chair would be shocked at how many “Senior Software Engineers At BigCo” can’t even write a program that “displays a countdown of all even numbers from 100 to 2, each on a different line.” There is literally no baseline level of knowledge that is a given, like there is for, say, a doctor.

Sure but then why do people do leetcode hards coding brain teasers? This is like asking a journalist to write a sentence that is reversible when you just want to know he speaks English.

It strikes me as counter productive to select for memorization for a job based on research and collaboration. It's easy, but then the whole "software development is costly and error prone" problem looks self inflicted.

This is a decade old story, but I was asked FizzBuzz for the first time without knowing what it was, and got it fundamentally wrong. This was three years into a career in which I alone had written a full equity arbitrage trading system in C++ that was making millions per year. I had written PDE solvers running in production for 50 traders doing $1bn worth of trades a day. I was not a liar.

The question did not "weed out someone who couldn't code." It weeded out someone who couldn't use a totally unfamilliar dev environment while being stared at and asked to "walk me through your thoughts" instead of letting me think. It left me distracted, thinking both "this is easy, what's the catch" and "wtf is the point of this?"

"Tell me about something you've worked on" is a totally fine question. I'm not arguing with that. But anything leetcode is not, IME. This becomes increasingly true as people's careers develop. If you've spent your last two years writing hyper low latency deserialization engines and packet processing, then you'd know that's what the job is about. In the macro, trading engines and game engines are one medium leetcode problem from an algorithms point of view, but they require teams of people and years of optimization and customization to make truly effective. I don't want to test for the person who can make a really basic solution in 30 minutes. I want to test for the person who can optimize a tiny fraction of it in 2 days.

That’s a disingenuous argument enabling somebody with a massive ego problem.

1) most people here, I believe, don’t have a problem testing a developer’s code writing acumen.

2) People weigh something. Bricks weigh something. It’s the same exercise. The analogy in software would be the difference between asking someone to write _an_ function that can do x vs write _the_ function your company uses to do x.

3) the lions share of counterarguments here propose using real world exercises vs toy problems

I think you're missing the point of the comment about tools.

Programmers skew anxious. In theory there's no difference between writing basic code on a whiteboard and writing it in an IDE. But in practice, an interview is a novel, high-stakes environment with a bunch of judgy strangers. So if you then have people do the interview using tools that are unfamiliar, a notable percentage of them will be thrown off.

Once I switched to encouraging people to bring their own tools (own laptop, own editor, preferred language), I saw a marked decrease in people bombing interviews. Some of the people you might have put in the "they lied" bucket were, at least for me, just ones who got really nervous and so were unable to grab the brick.

To me, that's a bad interview, because the job isn't going to be high-stakes whiteboard coding. It's going to be sitting quietly in a comfortable and safe place and gradually improving things. The more an interview can be like that, the better.

Isn't the brick test pretty close to a work-sample test?

I've always assumed the brick was meant to simulate a drowning swimmer, whose rescue is pretty clearly part of the lifeguard's job. I guess a mannequin would be more realistic, but it still seems pretty close.

It selects for people who prefer solving puzzles to doing work. Source: I am one.

I prefer solving puzzles -as- my work. If I’m not doing work that gives me the opportunity to take a Problem Solved Victory Lap every once in a while, I don’t want the job.

Reply on news.ycombinator.com