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

Coding interviews are stupid (ish)

darrenkopp.com

Post reply on HN
Print view View original

241–250 of 679 posts

Re: Coding interviews are stupid (ish)

#241

Post by [deleted] »

speeder wrote: post #51
citizen_friend wrote: post #20

Earlier quoted context omitted.

- licensing ensures only a minimum level of quality - people with licenses still do interviews, often just as grueling - licensed careers with high performers (lawyers, doctors, ib, etc) have other forms of filtering which are much more painful, like years of low pay internships Studying for a few weeks to solve fun puzzles to make 400k sounds like a deal to me.

What kind of job pay 400k? Even when I worked as C++ guru at BMW and was hired as very senior my before taxes compensation was 40k (year).

[deleted]

Re: Coding interviews are stupid (ish)

#242

Post by okwhateverdude »

onetimeuse92304 wrote: post #63

Honestly, as somebody who is hiring senior devs I can't imagine not doing a coding interview. Unfortunately, it is very hard to judge somebody's coding ability in discussion alone. You can sort of get the idea whether they have or don't have experience and whether they have luck being asked about topics they know (although you can help your luck just knowing a lot of stuff). I have seen a lot of candidates who were q…

>Unfortunately, it is very hard to judge somebody's coding ability in discussion alone. You can sort of get the idea whether they have or don't have experience and whether they have luck being asked about topics they know (although you can help your luck just knowing a lot of stuff).

I disagree with your stated difficulty in judging coding ability by discussion alone. A skilled interviewer is easily able to ascertain breadth and depth of the candidate's experience provided the interviewer is also an expert and curious. And part of being a skilled interviewer is using all of the information at hand in their CV.

>The task is usually ambiguous a bit and this is explicitly stated so that the candidate is actually expected to get stuck, don't know things and have to talk to me to get the problem solved. You would be surprised how many candidates do not listen or can't follow simple advice even when I am almost giving them the solution on a platter.

Would instantly pass on working with you based on this alone. The intentional ambiguity is deceitful. The expected dependence and expected deference is so patronizing and manipulative. I don't need to have an ego measuring contest in an interview. You win, you're the smart, awesome guy. Go enjoy all that success, bro.

I've had too many interviews like this where the dudes on the other side of the table have internalized their superiority at proctoring their simple tasks. These dudes think they are the great gatekeepers of... something. Like, the candidate just wants to cut code so they can pay rent and eat. They don't really care, nor should they, about your product, or your customers. It's an exchange of labor for a pittance of the value produced. And the dudes on the other side of the table are gate keeping it.

Re: Coding interviews are stupid (ish)

#243

Post by lesuorac »

Eh, if you hate coding interviews such much you can try something else like welding.

Oh wait, welders have to prove they can weld before they get hired? [1]

---

The general issue with coding interviews is most companies don't validate that the interview is actually correlated with job performance. Of course a process where the blind leads the blind is going to have issues.

[1]: https://www.reddit.com/r/Welding/comments/26ppfb/what_to_exp...

Re: Coding interviews are stupid (ish)

#244

Post by nineplay »

dilyevsky wrote: post #139

Classic mistake of overthinking it and failing to realize what interviewer really wants - which is to make sure the candidate can actually write code, like at all. The question itself doesn't really matter as much as it's just a pretext. I actually asked a variation of this question for many years at Google and it was clear within first 5 mins who has been writing code day-to-day and who's been mostly "brining key st…

The problem is that the candidate has been assured that they will be asked 'leet' code questions where solving the problem isn't enough, they will also be asked about O notation and how the code can be optimized and whether to use memoization or recursion. This is what the books will tell you, this is what YouTube will tell you, this is what 'helpful' recruiters will tell you.

And IME this is what most interviewers have been taught. They've got a list of sample questions, they've been told that if they give the knapsack problem and the interviewee doesn't immediately call out 'dynamic programming' than the interviewee is a pass.

If you only want to see working code than you are the exception rather than the rule.

Re: Coding interviews are stupid (ish)

#245

Post by [deleted] »

humansareok1 wrote: post #200
munificent wrote: post #167

Earlier quoted context omitted.

> Do Surgeons need to perform mock surgeries before they are hired? They must have a degree from an accredited institution before they can begin practicing, and part of earning the degree is operating on cadavers, so, yes. > Do Accountants need to complete a test audit? In order to be a Certified Public Account in the US, you must pass the Uniform Certified Public Accountant Examination, which has a section on auditi…

>They must have a degree from an accredited institution before they can begin practicing, and part of earning the degree is operating on cadavers, so, yes. You know what I meant. You have merely created a series of strawmen. They don't need to perform a trial surgery every time they interview for a new job. The same goes for all my examples so nice try.

[deleted]

Re: Coding interviews are stupid (ish)

#246

Post by theideaofcoffee »

gardenhedge wrote: post #237
kstenerud wrote: post #221

My approach to interviews over the past decade has been as follows: 1. My preparation for an interview involves researching the company, not technical matters. I don't brush up on coding interview questions. I've never done leetcode. 2. If I find the interview questions to be ridiculously off-topic (such as silly algorithm questions), I end the interview. You're not the kind of company I want to work with. 3. If I fi…

How do you end the interview? To me it seems like that might be awkward.

I'm not op, but I have had to do this a few times because of the same reasons. You pause, take a breath and kindly say "thank you for the opportunity, but at this time I don't think this is the right fit" and leave it at that. No need to embellish, or add extraneous detail or think you're being awkward because they will do the same thing if they don't want to go further in the process with you. It's just business, treat it as such.

Re: Coding interviews are stupid (ish)

#247

Post by 331c8c71 »

arp242 wrote: post #152
onetimeuse92304 wrote: post #63

Honestly, as somebody who is hiring senior devs I can't imagine not doing a coding interview. Unfortunately, it is very hard to judge somebody's coding ability in discussion alone. You can sort of get the idea whether they have or don't have experience and whether they have luck being asked about topics they know (although you can help your luck just knowing a lot of stuff). I have seen a lot of candidates who were q…

I can't really code myself out of a paper bag either with a stranger watching and questioning me while I'm doing it. I just get so nervous and can barely think straight (in general I get rather nervous being watched). One time they asked me to do a function I literally exactly have on my public GitHub as part of a project (remove duplicate entries from an array without sorting; it's just a few lines and pretty straig…

Not realizing that the interviewee might be underperforming due to stress is quite telling about the interviewer's emotional maturity.

Re: Coding interviews are stupid (ish)

#248

Post by simoncion »

chessnerd42 wrote: post #232
331c8c71 wrote: post #218

Earlier quoted context omitted.

And vocalizing this inner dialogue comes naturally to you I suppose.

If you can't explain your thoughts out loud then you're going to have a difficult time working anywhere.

For me, it's not at all "I'm incapable of explaining this to you given a few minutes to collect my thoughts." and very much "You either get Coding Mode, or you get Conversation Mode, but not only do you never get both at the same time, I need time to context switch from one to the other.".

The second paragraph in this comment is very, very, very close to how my brain operates: https://news.ycombinator.com/item?id=40290732>.

And I've been programming professionally for quite a long while now, so this quirk of mine doesn't seem to have made it difficult for me to work at programming shops.

Re: Coding interviews are stupid (ish)

#249

Post by tantalor »

darrenkopp wrote: post #234
tantalor wrote: post #206

Earlier quoted context omitted.

How is that "in an unordered fashion"? It sounds pretty ordered to me!

The data itself is ordered (which is why the task is to print them in order), but the order you receive the values is can happen in any order (ie the processing was split into multiple threads and each thread is posting back the results from the work).

Ah then that's the classic "merge k sorted streams" question. It's a good question and easy to solve in a coding interview. Good candidate should be able to solve in about 30 minutes. My favorite solution goes something like "put values in a heap and then read them back out" because you only need to read 1 value from each stream at a time.

Re: Coding interviews are stupid (ish)

#250

Post by kevincox »

nineplay wrote: post #244
dilyevsky wrote: post #139

Classic mistake of overthinking it and failing to realize what interviewer really wants - which is to make sure the candidate can actually write code, like at all. The question itself doesn't really matter as much as it's just a pretext. I actually asked a variation of this question for many years at Google and it was clear within first 5 mins who has been writing code day-to-day and who's been mostly "brining key st…

The problem is that the candidate has been assured that they will be asked 'leet' code questions where solving the problem isn't enough, they will also be asked about O notation and how the code can be optimized and whether to use memoization or recursion. This is what the books will tell you, this is what YouTube will tell you, this is what 'helpful' recruiters will tell you. And IME this is what most interviewers h…

I will ask all of those questions. But I don't expect perfect answers. You should at least know what big O is. I would really like it if you can tell an O(n^2) algorithm from a linear one. (That is often really important in real-world code). I would like you to consider different ways you can optimize the code.

I don't expect you to quickly crank out a novel optimal algorithm. But I like to see that you can think about how to solve problems programmatically. I would like to see you can identify differences in different algorithms and what tradeoffs there are. Considering different approaches that may be faster also shows that you didn't just memorize an algorithm from somewhere but that too took time to actual understand the problem and build a mental model in your head.

I have given people great reviews when they couldn't come up with a working algorthim because the clearly knew how to think like a programmer and considered all of the important things.

Post reply on HN