The software industry's greatest sin: hiring • Hacker News Board

Re: The software industry's greatest sin: hiring

#141

Post by mattbillenstein » Fri, Apr 10, 2020, 3:29 AM UTC

missosoup wrote: post #53

mattbillenstein wrote: post #26

Earlier quoted context omitted.

You should absolutely see how they code - I've interviewed so many people on the phone who couldn't code their way out of a paper bag, but they could speak to it enough to fool you.

Maybe enough to fool you . It's pretty easy to tell if someone knows a topic or not by just asking increasingly more specific technical questions to follow up on their answers.

Maybe - I mean, you just get signal from actual coding, I think it's pretty hard to discount entirely. How they solve problems, what mistakes they make, how they debug - I think it's just too valuable to not spend some time on.

And I'm not giving them riddles - I give them easily solvable problems that can be done in almost any programming language. And I've given the same problems enough to know what it canonically looks like in a dozen languages.

Re: The software industry's greatest sin: hiring

#142

Post by 3fe9a03ccd14ca5 » Fri, Apr 10, 2020, 3:29 AM UTC

ransom1538 wrote: post #78

My favorite interview was at digg.com. A four hour interview was going great. My dream job. I knew their tech solid. Then the last guy - walked in [ianeure]. He asked: "What is a having statement in sql". I leaped in - rambled on and on how you can filter aggregated sets. His response: "I don't think you know how they work." I sat there confused and concerned. He explained you don't need a group by with a having stat…

Nothing to be upset about here. Sounds like you dodged a bullet last minute.

Re: The software industry's greatest sin: hiring

#143

Post by Apocryphon » Fri, Apr 10, 2020, 3:30 AM UTC

klipt wrote: post #135

mattkrause wrote: post #83

Earlier quoted context omitted.

But once you pass it and are admitted to the bar, you're set (assuming you renew your membership, don't change states, etc).

> you're set If you mean set in terms of money, lawyer pay is strongly bimodal these days, with most lawyers earning the lower amount: https://www.lawcrossing.com/article/900049851/Is-Law-Still-a...

You're set in the sense that you don't have to take the exam again.

Re: The software industry's greatest sin: hiring

#144

Post by tomnj » Fri, Apr 10, 2020, 3:30 AM UTC

josephg wrote: post #134

dahart wrote: post #47

> Developer hiring is broken This seems to be a pretty popular opinion. It totally might be right, but it’s not my own experience, so I have a serious question because maybe I don’t know what’s happening out there with most hiring today - what are the broad-stroke outcomes that demonstrate that hiring isn’t working? Are there statistics that show that hiring has problems? All of the reasons given in the article are c…

I'm a software engineer working at a company in the hiring space. I've done over 400 technical interviews in the last year alone, and ... this is a hot take, and not the view of my employer, but I think developer hiring processes are fine (At least, at most mature companies.) There's a problem at the moment in the market that there's a huge amount of pent up demand for senior developers. The market has responded with…

> huge amount of pent up demand for senior developers

But is leetcode really the way to find them?

Re: The software industry's greatest sin: hiring

#145

Post by dheera » Fri, Apr 10, 2020, 3:32 AM UTC

renewiltord wrote: post #31

You've got to know if the other person can code. Lots of people can talk a mean game and make nothing and few people can spot them. That's the thing, though. If you make a reputation as the kind of guy who can near 100% spot the good engineers, you will make boatloads of money. An employer will pay you more than $30k if you only do great hires. You do 10 of them with your conversation out to lunch and you've made $30…

That's true, but engineers don't code whiteboards or codepens.

If they want to know if I can code, I'm happy to point them to several git repos that I wrote >95% of, and send code samples of non-public code that I wrote.

I can make real tasks happen, like make a robot navigate a room autonomously, but I suck at remembering how to write quicksort or write a parser for some weird interview-specific language or all of the insane number of C++20 features. At most whiteboard interviews at large companies, I was asked to code things I have never done for work and will probably never do for work.

Machine learning interviews frequently asked me to implement NMS or gradient descent. Fine, I can do that, and fumble a bit in the process (and probably get docked points for fumbling), but NO machine learning engineer on the planet needs to do these things because there are excellent libraries that do them for you and it isn't the job of the ML engineer to re-invent them.

Re: The software industry's greatest sin: hiring

#146

Post by yahyaheee » Fri, Apr 10, 2020, 3:33 AM UTC

dvt wrote: post #118

jariel wrote: post #76

Earlier quoted context omitted.

Nobody should be either afraid or unwilling to do 'whiteboarding', rather, it should be an opportunity. It's not perfect, but reasonably structured it's a good thing. Academic credentials are not necessarily conducive to great dev talent ... OSS with lots of stars is a much better measure, but even then, it's not a guarantee of anything. Companies have to be responsible about their due diligence.

I personally suck at whiteboarding, even though I'd say I'm pretty good at actual coding. I'd rather not put myself at a disadvantage, so that's why I avoid whiteboarding interviews.

Yea this is the thing, I’m terrible at white boarding but I have an amazing github that can show what I’ve done. An amazing github presence should far exceed any whiteboarding

Re: The software industry's greatest sin: hiring

#147

Post by 3fe9a03ccd14ca5 » Fri, Apr 10, 2020, 3:33 AM UTC

ping_pong wrote: post #104

mlthoughts2018 wrote: post #42

Earlier quoted context omitted.

It has never ever been true that you can “be a nobody” and get hired on merit alone. Even with dozens of responders to this comment coming to say that’s how they got hired, it’s total round-off error compared to size of tech hiring at large. Your credentials and political connections are what allow your resume through the ten arbitrary filters before you even get to the technical screen, collaborative coding, etc., a…

I met this kid 20 years younger than me at my last company. He had a thick country accent that made him sound like a redneck, and he never went to college, he only graduated from high school. One of the best programmers I've ever met. He couldn't do complex big-O analysis because he never learned it having started to work straight out of high school, but other than that, his code was meticulous, he gave excellent cod…

Every job I’ve met people like this. Charismatic, professional, skilled, and friendly. I try and keep up with how they’re doing when I move on.

I wish more of them were millionaires now. Many of them are still programming (degrees become more important as you move up), which is a shame because they’d probably make fantastic people managers.

Re: The software industry's greatest sin: hiring

#148

Post by vsareto » Fri, Apr 10, 2020, 3:33 AM UTC

sultanofswing wrote: post #81

The software industry's greatest blog post sin: "Hiring in tech is broken" This topic is trite. Furthermore no one seems to be able to offer up actual tangible suggestions as to how to fix this, or some objective 'better way'. Disclaimer I work at a FAANG etc company: Also this has been distinctly "not" my experience at many FAANG type companies. Usually these interviews, even the one's I haven't done well in, have b…

>Furthermore no one seems to be able to offer up actual tangible suggestions as to how to fix this, or some objective 'better way'.

There are other professions with models of credentials that could be adopted to software given some time and adjustment and faith. Then we could shed our current technical interviews in favor of shorter interviews overall. You naturally need more people to handle interview bandwidth as your company grows.

People want to show some credential and not have to deal with technical interviews at every potential opportunity. We've learned enough about technical interviews that we should be able to make this kind of widely-recognized credential. We just don't want to do it. We'd rather keep recruiters employed and force developers to budget large blocks of interviewing time.

Re: The software industry's greatest sin: hiring

#149

Post by sgerenser » Fri, Apr 10, 2020, 3:38 AM UTC

dahart wrote: post #47

> Developer hiring is broken This seems to be a pretty popular opinion. It totally might be right, but it’s not my own experience, so I have a serious question because maybe I don’t know what’s happening out there with most hiring today - what are the broad-stroke outcomes that demonstrate that hiring isn’t working? Are there statistics that show that hiring has problems? All of the reasons given in the article are c…

It varies among the FAANGs, but in my experience Google was the worst with the algorithms above all approach. I actually had one interviewer cut me off after about a minute when I was describing an interesting problem I worked on, saying “yeah ok that’s great let’s get on to the algorithm question.”

I’m sure it varies between interviewers but the lineup I had at google clearly didn’t want to dedicate more than a minute or two to non-algorithm questioning.

Re: The software industry's greatest sin: hiring

#150

Post by Apocryphon » Fri, Apr 10, 2020, 3:39 AM UTC

nine_k wrote: post #98

mlthoughts2018 wrote: post #79

Earlier quoted context omitted.

My experience as a hiring manager disagrees with yours. Large system design interviews are par for the course - everyone knows how to do them and everyone has lots of experience. They don’t tell you really anything about a candidate, to the point that we should stop using them.

In my experience, this has been rather selective. Some people have very little idea about load-balancing, DNS, database scaling (replication, sharding, etc), fault tolerance, graceful degradation, queues, throttling, caching, you name it.

If candidates take a course like this, does that mean they're self-starting go-getters trying to expand their knowledge to become good engineers, or people trying to game the section on the interview- or both?

https://www.educative.io/courses/grokking-the-system-design-...