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

In defense of coding interviews

biggestfish.substack.com

Post reply on HN
Print view View original

51–60 of 391 posts

Re: In defense of coding interviews

#51

Post by ta988 »

fiddlerwoaroof wrote: post #12
adam_arthur wrote: post #9

Earlier quoted context omitted.

Most growth companies have an endless bucket of work. Somebody who produces 2x at same quality of work is worth 2x the other person, fairly objectively. It's common to find people who produce up to 10x the average. Anyone in a startup or growth oriented company is smart to optimize for these people. The most proficient and fast coders often write higher quality code too, in my experience. People who over index on com…

I think the ideal is to have both in some proportion: like 10% slow coders dedicated to maintaining the structure of the application. And 90% people who can churn out features quickly

I agree but I would say: The ratio varies depending on the kind of product and especially on where you want to be on the spectrum of speed, security, safety, time to client...

Re: In defense of coding interviews

#52

Post by ta988 »

jussij wrote: post #39
adam_arthur wrote: post #2

The best coding interviews for 90% of tech jobs are ones that are heavy on coding and light on theory. Very few jobs are particularly well served by somebody with strong theoretical foundations, while most are well served by somebody who can pump out high quality code quickly. Yet most companies interview as if they are inventing novel storage/processing mechanisms. Theory is important to understand which tools to le…

> I've had plenty of people crush the theory portion of the interview and be poor performers on the job (slow coding, low volume output) I think the reason for that observation relates to why these interview tests are generally a waste of time. Based on the tests that I've seen, they are 'recall lots of useless information' tests. That means it's actually possible to study for these interview tests (if you have the d…

Anything that anyone can find in a couple of seconds on a search engine is probably not worth an interview question. And that's valid for the interviewer as well don't ask something that you could find by looking at the resume.

Re: In defense of coding interviews

#53

Post by ThrowawayR2 »

zach_garwood wrote: post #35
ma2rten wrote: post #20

Earlier quoted context omitted.

But many senior candidates actually can’t code anymore. Also, typically the point of these questions is to see if the candidate can solve a novel problem not if they can use a hash table.

Ya know, I've heard this repeatedly over the past 15 years, but I've never actually encountered this mythical "senior programmer who can't code." Never worked with one. Never interviewed one. Never met one at a meetup. I think it's just a boogeyman used to frighten hiring managers.

I have. Supposedly an experienced fellow but put out code that would embarrass an intern (and a bad intern at that).

Re: In defense of coding interviews

#54

Post by ta988 »

andreygrehov wrote: post #36

I used to hate leetcode-style coding interviews, but now I don't. The reason for this is a comment from a Google engineer. That comment changed my mind. In that comment they explained the motivation behind asking these type of questions and it all finally clicked for me. Corporations are not testing your knowledge of algorithms per se. While that knowledge is obviously important, what's more important is how dedicate…

They are testing also how docile you are. If you are ready to do useless tasks and go through hundreds of pages of the X-corp way of life then you have a chance to stay long and prosper.

Re: In defense of coding interviews

#55

Post by ta988 »

jackblemming wrote: post #41
andreygrehov wrote: post #36

I used to hate leetcode-style coding interviews, but now I don't. The reason for this is a comment from a Google engineer. That comment changed my mind. In that comment they explained the motivation behind asking these type of questions and it all finally clicked for me. Corporations are not testing your knowledge of algorithms per se. While that knowledge is obviously important, what's more important is how dedicate…

Maybe I’d prefer to not dance like a monkey for employment.

Some people are ready to trade dancing for a lot of money and a resume that will open them the doors of where you really want to be.

Re: In defense of coding interviews

#56

Post by d--b »

The dirty secret is that it’s never about the coding skills.

It’s about the person’s behavior, the way he/she interacts with you. It’s about the person’s culture, tabs vs space, and that kind of things. And it’s mostly about whether you like the person or not.

And I think it’s fine. You mainly need to be sure that the person knows what a for loop is, other than that, most people are ok at programming. What really matters is that you can work with that person.

Unfortunately interviewers who don’t realize this will unconsciously tweak the interview to make it harder for people they don’t like and easier for people they do like. And then they have an “objective” reason to not hire the person: “oh my god, he didn’t know merge sort”.

I give all kinds of random questions. And many times I recommend hiring people who bombed it, and many times I recommended bailing on ones who nailed it (overconfidence, poor communication, etc).

Re: In defense of coding interviews

#57

Post by scarface74 »

I don’t know how to feel about coding interviews. I never had a serious coding interview in my 24 year job history between 7 companies from 1996-2020. They were all your standard “dark matter” [1] development enterprise dev jobs.

Then I did a slight pivot to get into BigTech via cloud app dev consulting - “application modernization” [2] - still with no coding interview although I still do the same type of enterprise/cloud app dev I did in the latter part of my career in the “real world” - and a shit ton of yaml.

Even in 2020, if I couldn’t have gotten a job at either Azure or AWS, I probably would have done what it takes and practiced to increase my income by an easy six figures or more.

Coding interviews are a “gravity problem”. You can not like either. But they still exist.

That being said, if I were starting out today and could break the can’t get a job don’t have experience cycle by “grinding leetcode” for few months and and end up in the top 10% of income earners in the US right out of college, I would have definitely done it and I encourage my younger relatives graduating in CS to do it.

However, if you’re just hiring for your standard yet another senior CRUD developer and paying as such ($90K-$160K) - don’t expect me to do the monkey dance.

I think algorithm style coding interviews are the great equalizer. Even though I at 48 probably couldn’t pass one without some serious practice.

[1] https://www.hanselman.com/blog/dark-matter-developers-the-un...

[2] yes it’s a full time position with the same compensation structure.

Re: In defense of coding interviews

#58

Post by leeoniya »

vorpalhex wrote: post #27

"Can coding interviews work in an ideal world" which is what the article seems to discuss: sure, probably, this seems like a reasonable approach to what that ideal world might look like: a really carefully chosen question and attempting to understand the process the candidate is using to comprehend their skill. "Do coding interviews work in the actual world in which we live in?" No, fundamentally not. Almost nobody i…

> or asking obnoxious questions ("Why did you use a foreach and not a for loop?")

you should be able to explain why you wrote something the way you did; that's not an absurd ask.

perf characteristics of different iteration styles are often significant to the task at hand.

Re: In defense of coding interviews

#59

Post by wespiser_2018 »

Justsignedup wrote: post #19

I usually give a data structure coding interview: Here's some data models, and here's how you can reference eachother by properties. Cool. Let's do 3 levels of nested loops to extract the relationships and map them. That's like 99% of what they'll be doing. The signals I'd look for are "do they start the entire thing by looking at structures or not", etc. But unfortunately this breaks down when you're interviewing 10…

That's an interesting observation: if you are hiring someone whose role is largely high level decision making, like a principal engineer, that skillset is orthogonal to anything you could get them to show you on a keyboard. Almost by definition: the role is simply more than what a single person can do at the keyboard in X amount of time, so testing for that would be an incomplete test.

Re: In defense of coding interviews

#60

Post by qz_kb »

andreygrehov wrote: post #36

I used to hate leetcode-style coding interviews, but now I don't. The reason for this is a comment from a Google engineer. That comment changed my mind. In that comment they explained the motivation behind asking these type of questions and it all finally clicked for me. Corporations are not testing your knowledge of algorithms per se. While that knowledge is obviously important, what's more important is how dedicate…

How dedicated you are to do a task with no intrinsic value besides getting hired at companies with leetcode-style interviews. I don't think google is better off when everyone they hire has wasted hundreds of hours on a fundamentally useless skill rather than having used that time to learn different skills or just enjoy time with family and minimize the chance they burn out on the job at a later date.

There's other ways to tease out if someone is "dedicated to reaching a goal" like actually asking them questions about their life, daily routine, accomplishments etc. I think these are much better signals than "this person can implement many sorting algorithms and solve towers of hanoi or the egg drop puzzle without a google search to refresh their memory" with an N=1 sample size used to gauge how reliably they can do that. How many people if asked to do this on a job rather than an interview a year later would then go and implement it from memory without double checking they didn't forget some edge case on stackoverflow?

I know grinding leetcode is fundamentally useless because you will immediately start losing your ability to interview once you get hired. If you don't change jobs within a year you'll need to start studying all that crap again for the next interview.

Post reply on HN