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

121–127 of 127 posts

Re: Tell HN: Stop Accepting Shitty Interviews

#121

Post by novok »

Nextgrid wrote: post #103
novok wrote: post #60

In interview design there are a lot of trade offs. Coding something quick within an hour? "It's too time constrained." Take home interview question? "It takes way too long for the busy professional who already has a job, and plus, even if we time constrain it, they'll put way more time in. Or they'll cheat with friends." Ask to see previous code? "Many good candidates do not do open source and couldn't tell us what t…

Reading this it seems like the company's objective isn't to hire someone but to find every possible reason not to hire them.

This are real responses and complaints about changing interviews from leetcode type to not leetcode type, or to fix other common issues and anxieties that people have in interviews. Every interview type has issues and you have to choose as a company what negatives you want to accept for which items you want to favor.

And yes, a bias towards avoiding the false positive is a explicit goal of many engineering interviews, and I think google has said so explicitly.

Re: Tell HN: Stop Accepting Shitty Interviews

#122

Post by jiveturkey »

usrbinbash wrote: post #107
jiveturkey wrote: post #61

Earlier quoted context omitted.

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…

> Being skilled in a specific FE framework or any library/API isn't what you should be testing for Knowing how to implement some arcane algorithm is also not what you should be testing for. It tells me ZERO about this persons ability to code in the real world. It may not even tell me they understand the algorithm...they may have just memorized the pseudocode implementation well enough. > You really want to uncover ab…

a) sure and that's why you aren't literally administering an IQ test. it's highly subjective and flawed. so?

b) of course it is! no dispute whatsoever. that's why it's 6 months to become productive in any new job in the first place. But you want someone that can BECOME familiar and can UNDERSTAND the framework du jour.

When I hire an appliance repairman I want a guy that understands how the machine WORKS and can troubleshoot it from that knowledge base. Not someone that can swap in a fuse as long as the machine tells him which fuse is bad. I want someone who is knowledgeable with DISHWASHERS not someone that is an expert in MIELE seeing as I have a BOSCH or I've modified my miele beyond recognition anymore.

If you need seat warmers the story is different. Then sure, you just want a miele certified repairman.

Re: Tell HN: Stop Accepting Shitty Interviews

#123

Post by chrismcb »

What is a "shitty"interview? I certainly hope you don't mean a whiteboard interview where you are asked to solve and code a small problem? Probably the best type of interview our industry can give What is a "mimic the job"interview? How do you do the in 45 minutes? Using tools the interviewee may never have seen? I think asking a few coding questions is the best interview.

Re: Tell HN: Stop Accepting Shitty Interviews

#124

Post by usrbinbash »

jiveturkey wrote: post #122
usrbinbash wrote: post #107

Earlier quoted context omitted.

> Being skilled in a specific FE framework or any library/API isn't what you should be testing for Knowing how to implement some arcane algorithm is also not what you should be testing for. It tells me ZERO about this persons ability to code in the real world. It may not even tell me they understand the algorithm...they may have just memorized the pseudocode implementation well enough. > You really want to uncover ab…

a) sure and that's why you aren't literally administering an IQ test. it's highly subjective and flawed. so? b) of course it is! no dispute whatsoever. that's why it's 6 months to become productive in any new job in the first place. But you want someone that can BECOME familiar and can UNDERSTAND the framework du jour. When I hire an appliance repairman I want a guy that understands how the machine WORKS and can trou…

I think we are completely in agreement about what constitutes skill, and what companies should look for in candidates.

The point where I think we disagree, and please correct me if I'm wrong, is: are LC style questions an effective testing method for these skills.

I say no, they are not, for 2 reasons:

a) implementing something like a non-trivial graph algorithm doesn't come up often in day-2-day work, and if it comes up, even some experienced developers look it up, just to make sure they got it right from memory. To borrow your dishwasher-analogy: I want the repairmen to know how a generalized dishwasher works, so he can repair Miele, Bosch, whathaveyou, but I don't need him to be able to program the DWs microcontroller on a whiteboard, or forge one of the pipes with nothing but a firepit, a hammer, anvil, crucible and some copper-scrap.

b) since all these questions are known problems, both in their solution AND their usage as test questions, we are facing a "learning for the test" dilemma: people can, and many do, just memorize these answers to pass interviews, same as many students in standardized test environments just learn how to pass the tests.

This is fundamentally different from understanding the subject. Again, I agree with you: I want someone who can answer these questions because he can apply generalized knowledge about algos and data-structures.

But I am not confident tests which rely on pre-fabricated and well known puzzles will give me that.

Re: Tell HN: Stop Accepting Shitty Interviews

#125

Post by tacosbane »

quanto wrote: post #66

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…

> 1. If LeetCode problems are not only irrelevant, but actually turning away good employees, why aren't more companies shunning LeetCode problems?

At the margin, most companies (probably close to 100% for many sectors) do not make money from code quality. I'd argue it's actually pretty far from the margin for most companies. See the overwhelming shittiness of almost every software product that's been around for more than a couple of years. Almost all products get worse over time but still some companies make more money. IP and market position are much more important. I think this can also explain why so many very successful companies never launch a successful second product: they didn't initially succeed because they're so much better at development than everyone else, they succeeded because of the serendipity of the initial product.

Re: Tell HN: Stop Accepting Shitty Interviews

#126

Post by benhurmarcel »

asdff wrote: post #46
hartator wrote: post #33

Earlier quoted context omitted.

Yes, it’s easy to forget we are in of the highest paying industry. But yeah interviews should skip some redtape and HR bs.

Still, it's not like any other field of engineering has something equivalent to leetcode. You don't make someone with a civil engineering degree and a resume of bridge building go up to a whiteboard and work out an irrelevant physics problem like it's undergrad again. You don't have an M.D. talk you through a hypothetical surgery. Only in computer science is there this metagame that you have to dedicate unpaid time t…

And other fields of engineering don’t pay nearly as well.

I’d choose a much higher pay over a reasonable interview.

Re: Tell HN: Stop Accepting Shitty Interviews

#127

Post by novok »

EvanKnowles wrote: post #101
novok wrote: post #60

In interview design there are a lot of trade offs. Coding something quick within an hour? "It's too time constrained." Take home interview question? "It takes way too long for the busy professional who already has a job, and plus, even if we time constrain it, they'll put way more time in. Or they'll cheat with friends." Ask to see previous code? "Many good candidates do not do open source and couldn't tell us what t…

Following a comment I saw on HN, we now have several code snippets that we ask them to read through (biggest is like 12 lines) and tell us, at a high level, what it's trying to do. Great results, we've found people who learnt all the lingo completely failed when it came to reading and interpreting code.

Yeah I like the 'debug the real code block' style of interview too!

Just pretty much anything that is not leetcode bingo is a real improvement.

Post reply on HN