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

651–660 of 679 posts

Re: Coding interviews are stupid (ish)

#651

Post by sanderjd »

josephg wrote: post #639
sanderjd wrote: post #597

Earlier quoted context omitted.

Unsurprisingly we've now reached the perennial "is premature optimization actually premature" of it all :) Would it have been better for the person who originally wrote that just-iterate-the-list implementation to have been thinking about data structures and algorithms that would perform better? Opinions on this vary, but I tend to come down on the side of: Optimize for human productivity (for both the writer and the…

> Optimize for human productivity (for both the writer and the many future readers) first, then profile, then optimize any bottlenecks. I don't agree. The problem with this approach is that there are some optimisations which require changes to how data flows through your system. These sort of refactorings are much more difficult to do after the fact, because they change what is happening at the abstraction / system b…

I did mention that people disagree on this :)

I've moved both ways along the continuum between these perspectives at different times. I don't think there is a single correct answer. I'm at a different place than you on it currently, but who knows where I'll be in a year.

Re: Coding interviews are stupid (ish)

#652

Post by sfn42 »

sanderjd wrote: post #597
sfn42 wrote: post #555

Earlier quoted context omitted.

In my case the processing was happening in our backend. I can't remember exactly why it couldn't be SQL, actually it's possible it could have been sql. But changing it to sql would have been a bigger change and this wasn't really the task I was working on, I just happened across it while doing something else. I have also seen and fixed similar travesties where someone iterates through a huge list making one query per…

Unsurprisingly we've now reached the perennial "is premature optimization actually premature" of it all :) Would it have been better for the person who originally wrote that just-iterate-the-list implementation to have been thinking about data structures and algorithms that would perform better? Opinions on this vary, but I tend to come down on the side of: Optimize for human productivity (for both the writer and the…

Actually I think you're misunderstanding me. I'm not saying you should profile and optimize all the code you write, I'm saying that a basic understanding of algorithms, data structures and complexity analysis allows you to write better code without any extra tools. I didn't profile this report to find out why it took 30+ minutes to run. I just happened across some code, read it, saw that it was essentially two nested loops iterating through two huge (50-80k elements each) lists matching items by name, changed it to use a dictionary instead of the inner loop and that was that.

It's a trivial change, it wouldn't have taken any longer to write this the first time around. There is no excuse for doing this, it's just a dev who doesn't understand what they're doing.

That's my point. Understanding these fundamentals allows you to avoid these types of pitfalls and understand when it's okay to write something inefficient and when it isn't.

Re: Coding interviews are stupid (ish)

#653

Post by sanderjd »

josephg wrote: post #638
sanderjd wrote: post #528

Earlier quoted context omitted.

I agree that I think this is what most experienced people mean when they think of understanding data structures and algorithms. The problem is that this kind of understanding is very rarely what coding interviews check for. They either don't check for this at all - instead just making sure people can write simple code while reasoning through a simple problems under time pressure - or they check for whether people mem…

My recommendation is to have a lot of different stuff in an interview, so you aren't making a final judgement on someone over any individual part of the interview. That means the candidate can stuff up one or more parts of the interview, and you can still get good signal. For example, do all the things you suggest. Get them to write some simple code. Talk to them about an algorithm problem. Also, give them some simpl…

I mean, I agree, but this sounds like it could easily be a 3 hour interview :)

Re: Coding interviews are stupid (ish)

#654

Post by tsukikage »

_akhe wrote: post #581
darkwater wrote: post #557

Earlier quoted context omitted.

> There are many people who spend more effort creating the illusion of competence on paper and on the job, getting harder to detect the higher they go. If you can navigate a software engineering position, purely undetected, by bullshitting it, I would say you can be a very good manager. You can probably handle high level concepts without knowing the implementation details.

This is basically what happened, the industry turned manager-heavy and expelled a lot of talent, replacing lifelong developers with bootcamp devs and other non-tech background people. It's kinda messed up because the lifelong developer types got called nerds growing up, had to learn what they know in the face of bullying and computers being very uncool, only to be basically replaced by those who made fun of them when…

> Smart, talented people just aren't valued anymore - it's more about prestige and authority now.

At the core of any corporation that isn't in the process of rapidly dying, between all the middle management and socialising and meetings with pretty graphs and interoffice politics, there needs to be someone that does some actual work.

This is where the nerd fits in a large corporation. That person is irreplaceable, and the layers around them recognise this (or else the company implodes). The may posture, but if you push, they will jump through hoops for you. Flex your muscles. You have more power than you think.

Re: Coding interviews are stupid (ish)

#655

Post by tsukikage »

lr4444lr wrote: post #539
andai wrote: post #518

Earlier quoted context omitted.

>even then it sometimes fails How can a code interview fail? Hidden earpiece?

People spending inordinate amounts of time memorizing solutions to common problems. This is admittedly partly the fault of HR not ensuring that interviewers have a good pool of problems to choose from and twists to put on things, but it's a constant cat and mouse game with various websites aggregating interview questions from companies.

It's pretty easy to spot when the candidate goes from canned answer to actually having to think. "Thank you, that looks good; now I need it to also do this extra thing" - keep tweaking the question until they have to think.

Re: Coding interviews are stupid (ish)

#656

Post by josephg »

sanderjd wrote: post #651
josephg wrote: post #639

Earlier quoted context omitted.

> Optimize for human productivity (for both the writer and the many future readers) first, then profile, then optimize any bottlenecks. I don't agree. The problem with this approach is that there are some optimisations which require changes to how data flows through your system. These sort of refactorings are much more difficult to do after the fact, because they change what is happening at the abstraction / system b…

I did mention that people disagree on this :) I've moved both ways along the continuum between these perspectives at different times. I don't think there is a single correct answer. I'm at a different place than you on it currently, but who knows where I'll be in a year.

Totally fair :) I have the same relationship with static typing. Right now I couldn't imagine doing serious work in a dynamically typed language, but who knows what I'll think in a year too. From where I'm standing now, it could be ghastly.

Re: Coding interviews are stupid (ish)

#657

Post by s_dev »

dilyevsky wrote: post #585
s_dev wrote: post #484

Earlier quoted context omitted.

>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. What about the lad who develops homebrew who got rejected from Google because he wasn't able to invert a binary tree on the spot? Many Googlers use his software internally and externally. If the purpose of the interview is to make sure he can code why did…

You should really read your own link - the part where he admits he made that whole story up. Im gonna guess failing some basic coding is not what tanked him. He still thinks they owe him the job though because he’s kinda famous and did a popular project in a language that Google doesn’t use, so that’s cute. I also dont see how this one anecdote (even if it was true) invalidates anything I said above. You’re gonna hav…

>You should really read your own link - the part where he admits he made that whole story up.

Where does it say that?

Re: Coding interviews are stupid (ish)

#658

Post by _akhe »

valicord wrote: post #647
_akhe wrote: post #590

Earlier quoted context omitted.

[flagged]

Holy personal attack, Batman! Did he kick your puppy or something?

Nah just everything wrong with the industry in a single post :) That being: A Discord mod who barely knows HTML/CSS in a management role slingin code tests.

Re: Coding interviews are stupid (ish)

#659

Post by mandeepj »

M4v3R wrote: post #505
jillesvangurp wrote: post #500

My attitude towards code interviews is to politely decline them and encourage people best of luck hiring a junior developer; because that's obviously what they are looking for. I'm closing in on 50, so not that junior anymore. If anyone has any doubts about my coding abilities after reading my CV, browsing my Github repos, and talking to me, then it's not going to work and we can both save ourselves some time. I've s…

I totally understand your point of view, but looking at it from the other side it’s not as simple. We had candidates with 10+ years of experience in their resume, talking to them it seemed they know what they’re doing, they showed some of the code they’ve supposedly written. Then they got hired and it turned out they can’t code - their PRs are below junior level, constant bugs, communication is abysmal, they overshoo…

Just by introducing coding interview, how would you know they will not overshoot estimations by 3-4x? It's not one person's job, normally estimates are done by the entire team

Re: Coding interviews are stupid (ish)

#660

Post by OJFord »

around_here wrote: post #567
pavel_lishin wrote: post #551

Earlier quoted context omitted.

> Sounds like you'd more valuably/realistically get that from the discussion of a previous project though? How it works, or something interesting they had to figure out, etc.? You may be underestimating people's ability to bullshit their way through this sort of discussion. It's harder to bullshit your way past a blank file in a code editor. I'd wager that something like FizzBuzz will eliminate 90% of the chaff. Yes,…

FizzBuzz is an incredible filter for devs. Any kind of async JavaScript that needs to do something with the data after it fetches it has also been a winner. Lately the biggest weeding tool has been asking candidates to fetch some JSON from a bucket, then visualize that data. I'd say that maybe half the people manage to fetch the data in 30 minutes, and of that, maybe 10% get the data fetched within 10. The other 20 m…

But are you filtering for realistic performance, or for performance under time & observer pressure?

I did a .. bit more complex than fizzbuzz but similar toy problem sort of thing recently, and it's nothing I can't do, it passed the visible test cases (HackerRank if you're familiar, I haven't used it before but I assume it's generally similar) etc. but it was clumsy and far from representative of what I'd actually write on the job I think. Even if I still only spent an hour on it, just not having that pressure. Plus I suppose I would likely have seen the problem before in planning, and realistically it would be something within the context I was familiar with from working on it every day, not the toy problem. (This wasn't it, but imagine something like calculating the possible states of a chess board after each player makes another move. Bit simpler though.)

Post reply on HN