Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell HN: Stop Accepting Shitty Interviews

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 127 posts

Re: Tell HN: Stop Accepting Shitty Interviews

#61

Post by jiveturkey »

exdsq wrote: post #30
light_hue_1 wrote: post #12

> One of the recurring themes is the "leet code" interviews What makes these "shitty" interviews? They're very simple and they test for your ability to write code. They set the bar clearly and you have the ability to study for them with ease. Solve 200 of these problems once in your life and you'll never have an issue again. You'll breeze through all of these interviews. Compared to the alternative, where people ask…

Thank you for your application to extend our web forum built with Next.js. We query APIs from X, Y, and Z to offer Foo to 500 users. I see you have three years experience with Next.js and eight years working with X, Y, and Z! Excellent. We only have one question before we hire you - can you implement a Trie from scratch in an hour on this whiteboard without the internet? ...

I guess I understand the intent but I think you're off base for 2 reasons.

1. The question you are posing isn't hard. It's easy to borderline trivial, I would think so even for junior engineers who are recent grads.

2. Being skilled in a specific FE framework or any library/API isn't what you should be testing for unless you're hiring for simple task work. You really want to uncover ability (IQ) not familiarity. You want people that will grow with the company, not drag you down.

Re: Tell HN: Stop Accepting Shitty Interviews

#63

Post by asdff »

Barrin92 wrote: post #39

I personally like these questions a lot and I've used them in the past when I was tasked with hiring people because it basically boils down to a few things. One is that people who have a good grasp on algorithms, math or academic problems generally are pretty smart, and you can teach them practical coding skills very quickly while the reverse isn't true. so it's sort of like a IQ test. Secondly it rewards people who…

Take a step back and see how this leads you to miss out on plenty of candidates who could do the job, at the end of the day. These sorts of tests really just optimize for hiring people with time on their hands to study this stuff. Right off the bat having a heavy leetcode requirement probably excludes people with families or dependents, people with hobbies, or people who want to do anything after the bell that isn't staring at more code on an electronic screen.

I also think its a little backward to expect the candidate to be doing very much prep work in advance of the interview. They are in all likelyhood currently employed fulltime and busy with their life outside of that.

Instead I would focus on simply seeing if the candidate would be interested in the sort of work they would be doing, and giving as much detail as possible on what the job would be like for them. Job listings and corporate websites are often very opaque. It's one thing to get someone competent, but if they hate the job they will be gone in a year and you will be in the exact same place as you are today. If you get someone who might not know all the required tooling, but is very interested in the work being done, they will step up and be one of your most prolific employees before long and contribute to lasting institutional knowledge within your organization, rather than running off with their skills as soon as someone dangles a better paycheck in front of them.

Re: Tell HN: Stop Accepting Shitty Interviews

#66

Post by quanto »

On HN and elsewhere, there are so much deeply personalized emotions regarding LeetCode-style interviews. Instead of focusing on personal specifics, I am more curious about it from a social and systemic perspective.

1. If LeetCode problems are not only irrelevant, but actually turning away good employees, why aren't more companies shunning LeetCode problems? Tech is a very competitive field, and in the current climate of low interest rate, we (at least in the West) have more money than talent available. An employer with non-LeetCode interviews would have a significant market advantage. Is Google (and Netflix) being completely stupid even with their rigorous introspective take on hiring? If LeetCode is terrible for both the employer and the employee, why is it so popular? Are we all cargo-culting?

2. What is a better solution? How do we know it's better? There are proposed solutions, here and elsewhere, that make the candidates feel better about themselves, but for employers interested in hiring technically competent engineers, what is the solution? Requiring everyone to have a popular git repository?

Re: Tell HN: Stop Accepting Shitty Interviews

#67

Post by lordnacho »

chrisaycock wrote: post #20
majormajor wrote: post #2

So what do you propose as a replacement? In your case, they should've certainly dug into your open source, at least if it was directly in their line of business. I certainly love it when I ask a candidate "tell me about a project you found interesting" and they can go into details, talk about tradeoffs, etc. Sadly, most candidates can't . They can't come up with anything better than "well I rewrote the thing, and it…

I ask the same thing you do: "Tell me about a project you've worked on." There is tons of ground we can cover with that: * implementation choices with pros and cons * details about how the underlying system works * domain knowledge, where applicable * sample code where the candidate writes to mimic something from the system My interview style has always been: "Tell me what you know, and we'll see if that's true or no…

I work in the same industry as you and I agree. Your problems are never how to reverse a linked list, or finding the missing number. It's always tradeoffs: why does the business benefit from this technical decision over that one? What's the point of this language? What do you need in terms of hardware? How do you organise the code to suit the needs?

The interview that's always worked for me in hiring is where we talk about the issue and we see if the person understands the problem. There's an infinite number of things we can get into, and if the person is experienced they'll never run out of things to say. I've never hired someone who turned out not to know the basic things like some particular algorithm.

I suppose if we're talking the leetcode style interview loops, they normally have a system design part. That might be the closest to what I do.

Re: Tell HN: Stop Accepting Shitty Interviews

#68

Post by kodah »

friedman23 wrote: post #26
rgreasons wrote: post #21

Earlier quoted context omitted.

I think OP implied a better solution when mentioning interviews that mimic the job: present interviewees with a small take-home case study based on a real on-the-job problem. I have done a few of these and they have been much more enlightening experiences than any paired programming boilerplate live coding exercise. Even in situations in which my proposed solution weren’t up to snuff to land the job, the conversation…

> present interviewees with a small take-home case study based on a real on-the-job problem In my experience these are terrible. It becomes an arms race, what the company intended to become a 5 hour take home assignment becomes a 20 hour assignment because everyone else that's doing the take home assignment is also spending 20 hours. Take homes are a trap.

Personally, I like the idea of objective based take homes rather than time based. Then just have them check everything in on git so you can see how they work.

Re: Tell HN: Stop Accepting Shitty Interviews

#69

Post by exdsq »

jiveturkey wrote: post #61
exdsq wrote: post #30

Earlier quoted context omitted.

Thank you for your application to extend our web forum built with Next.js. We query APIs from X, Y, and Z to offer Foo to 500 users. I see you have three years experience with Next.js and eight years working with X, Y, and Z! Excellent. We only have one question before we hire you - can you implement a Trie from scratch in an hour on this whiteboard without the internet? ...

I guess I understand the intent but I think you're off base for 2 reasons. 1. The question you are posing isn't hard. It's easy to borderline trivial, I would think so even for junior engineers who are recent grads. 2. Being skilled in a specific FE framework or any library/API isn't what you should be testing for unless you're hiring for simple task work. You really want to uncover ability (IQ) not familiarity. You…

Everything is trivial once you know it. Good engineering principles like software architecture, for example being able to produce a sound Onion architecture with an accurate and well tested domain model, could be missed entirely by focusing on leetcode but is more important.

Edit: If you're looking for puzzle solving skills then give someone a puzzle

Re: Tell HN: Stop Accepting Shitty Interviews

#70

Post by barry-cotter »

wildrhythms wrote: post #42
friedman23 wrote: post #22

> Stop accepting shitty interviews Why should I stop? My personal experience is that many of the best companies to work for have shitty interviews. All I need to do is to study a bit and go through a 5 hour interview and I have a cushy high paying job? Sign me up. Complaining about interviews is missing the forest from the trees, I don't spend the majority of my working life interviewing, I spend it working. So if pr…

What a strangely adversarial comment. In my experience, I can gather more information about a candidate's ability in just 15 minutes talking 1 on 1 with them rather than hours of Leetcode busywork. Funneling candidates through an annoying, needlessly rigid, and blatantly time consuming process is not a good thing, and probably leads to perfectly qualified people being denied; a system that optimizes for 'signals' tha…

Even if you're correct about your ability to sniff out talent you don't scale, and you can't be implemented by someone with eight hours of training, or replaced by automated testing, or a pencil and paper test. Legible processes that are known to work to within some tolerance are great for large organisations.

If you can tell if someone's good within fifteen minutes of talking to them you should be able to get rich by setting up a software consulting company or startup with other people's false negative rejects. That's equivalent to being able to take mine tailings and spit out gold.

Post reply on HN