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

101–110 of 127 posts

Re: Tell HN: Stop Accepting Shitty Interviews

#101

Post by EvanKnowles »

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.

Re: Tell HN: Stop Accepting Shitty Interviews

#102

Post by usrbinbash »

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…

> they test for your ability to write code.

Do crossword puzzles test my ability to write novels? No they don't, because remembering some obscure name for a medieval dignitarys hat of office doesn't mean I can write compelling immersive stories.

By the same logic, memorizing how some obscure algorithm is implemented doesn't test my ability to think about real world applications or code in the context of a large project.

Re: Tell HN: Stop Accepting Shitty Interviews

#103

Post by Nextgrid »

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.

Re: Tell HN: Stop Accepting Shitty Interviews

#104

Post by Nextgrid »

anduru_h wrote: post #79
wildrhythms wrote: post #59

Earlier quoted context omitted.

People shouldn't have to cram little tricks and algorithms into their brain just to pass a Leetcode challenge; that's the point. No real-world programming career is driven by such pointless exercises.

I would think that real world programming careers are affected by someone's ability to remember information and put in effort, and that's demonstrated by the time spent to study for the little tricks and algorithms that go into passing an interview. I think it makes things a lot less subjective - you put in the time, you win.

I don't think that expecting prospective developers to spend lots of unpaid time on a skill that's ultimately not going to be useful to the vast majority of them should be normalized.

Do you expect medical doctors to do an unpaid "trial" surgery as part of their interview? Do you expect lawyers to litigate a case for free before they'll be considered for a job?

As far as I know software engineering is the only field where in addition to experience & education you have to waste time gaming the interview process. Every other field seems to get away just fine hiring based on experience and/or education.

Re: Tell HN: Stop Accepting Shitty Interviews

#105

Post by tommiegannert »

"Past performance is no guarantee of future results."

I'll predicate this with: there are lots of shitty interviews, but I don't think it's because they ask you to reverse linked lists. It's because the interviewers don't know what questions they're trying to answer.

I'm coming up on 15 years of experience. I also feel like linked lists isn't really that relevant for my day-to-day. However, I still think coding interviews can make sense no matter the level.

If I only asked you about the past, I would miss out on at least three crucial pieces of information for the general full-time software engineer:

1) Are you still able to do the gritty work? Perhaps you wrote a great piece of FOSS ten years ago, but you completely lost it after that got going. Now you're managing PRs, but externally, it looks like you're still doing it yourself, because you're announcing the releases. This is useful even if I'm hiring you as a senior, and expecting you to mentor/guide those who are just starting out with the gritty work.

2) How* did you do the work? Was it luck, experience, genious? (Did you call a friend?) Can I give you a problem to solve, and feel confident you'll ask if you don't understand or think it's a bad idea? I.e. how do you react to the unknown?

3) Can you communicate with others around you about new topics? Are we speaking the same language? Can I feel confident you understand when I tell you a linked list is a bad solution. If I hire you as a domain expert, this is obviously less crucial. Again, the question is about the daily unknown, not the story you've had the chance to rehearse. (And if your job is simply to reiterate the same things over and over, I should probably just buy a book.)

You can use technical expertise in two ways: getting things done yourself, or building rapport with those who do. I have interviewed "seniors" who I wouldn't have wanted as mentors myself, because all they could do was talk. Lacking reasoning skills, or inclination to work together to get something solved.

That said, the focus should never be on the problem itself. It's ephemeral, as everyone keeps saying. There shouldn't be any gotchas or trick questions. The problem is just a way to get the conversation going. It must be small enough, and easily explained. When I only have 45 min at a Google interview, I don't have time to explain a problem I'm actually working on. There's too much domain knowledge required. Instead, I have to distill a problem I had in the past to something that's interesting, but simple. That's why we end up with reversing linked lists over and over again.

It shouldn't matter if the problem is fully solved or not in the end, as long as the method is sound, and we understand each other. It doesn't matter if we go on a tangent, as long as it's enlightening. Also, I'd add that I don't think programming interviews should be the only thing that's happening, especially not for people with experience. They just happen to be the most contentious, and come up a lot in discussions.

(As someone who helped build Spotify's tech recruitment pipeline, and having interviewed SRE/SWE candidates at Google.)

Re: Tell HN: Stop Accepting Shitty Interviews

#106

Post by edanm »

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 once would've completely agreed with your point idea. But since then, I've had multiple experiences of talking with someone who made a great impression, super knowledgeable, but couldn't actually write any code in a real-world setting.

This approach simply doesn't always work. Some people are amazing-sounding but terrible in practice. The reverse is also true - some people are terrible at talking about their work, but produce amazing code. (Their lack of communication skills might or might not hamper their actual job performance, depending on multiple factors.)

Re: Tell HN: Stop Accepting Shitty Interviews

#107

Post by usrbinbash »

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…

> 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 ability (IQ) not familiarity.

a) Cognitive ability isn't accurately measureable. Not with IQ tests, and certainly not with standardized puzzle questions the internet is making lists of which one to learn to crack interview @ company X

b) Familiarity is EXTREMELY important when working with complicated systems.

Re: Tell HN: Stop Accepting Shitty Interviews

#108

Post by denvercoder6 »

thurn wrote: post #10

People never talk about the most important metric for interviews: your target rejection rate . Google and Facebook need to do these interviews because of the number of applicants they get. Any process they design must definitionally reject 99% of people who go through it, and they found it is essentially impossible to hit that kind of rejection rate with just 'tell me about your work' questions. If your startup opera…

Can't they simply hire the first eligible person? One can go through resumes and filter out people who don't meet objective criteria(e.g. work experience, location). This should be trivial. Then once they have 30 good resumes, they can call these people for interview. Assuming 10% chance of each candidate meeting the job requirements, they have >95% chance of finding a good candidate.

With automated resume pruning, it shouldn't take more than two hours for initial pruning. Actually, the higher number of applications means they can put in stricter pruning conditions, leading to lesser manual pruning later on. Assuming 2 hours/person interviewing, it should take less than a 40 hours-person to close a position.

I'd guess there's also some benefit w.r.t company loyalty when hiring a good-enough candidate instead of the best-available. They would be less likely to switch jobs compared to someone who can solve a leetcode hard problem in 15 minutes.

Re: Tell HN: Stop Accepting Shitty Interviews

#109

Post by chrisaycock »

edanm wrote: post #106
chrisaycock wrote: post #20

Earlier quoted context omitted.

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 once would've completely agreed with your point idea. But since then, I've had multiple experiences of talking with someone who made a great impression, super knowledgeable, but couldn't actually write any code in a real-world setting. This approach simply doesn't always work. Some people are amazing-sounding but terrible in practice. The reverse is also true - some people are terrible at talking about their work,…

I agree that the interview can't be just war stories. There has to be code in there somewhere, like whiteboard sketches of an algorithm the candidate has implemented.

On the other hand, leet code questions definitely don't show that the candidate can actually write maintainable, well-documented code with test suites and easy-to-use APIs.

Re: Tell HN: Stop Accepting Shitty Interviews

#110

Post by danaris »

chillacy wrote: post #56
wildrhythms wrote: post #42

Earlier quoted context omitted.

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…

To be fair the parent commenter's post doesn't claim that this process is even remotely efficient, only that it's reality and they find it easy to game. Also more meta-level commentary, I find the word "should" interesting, as in general I have found that comments on HN which contain this word reflect a level of frustration that X is X instead of Y, because "X should be Y". Someone else may come along and say "X shou…

The problem comes when a majority of us agree that X is not fit for purpose as it is, but we still get people saying "X is X, why are we talking about Y and Z?"
Post reply on HN