Live data from Hacker News

The software industry's greatest sin: hiring

neilwithdata.com

111–120 of 590 posts

Re: The software industry's greatest sin: hiring

#111
post #54

This makes so much sense. I've stopped doing in-depth technical interviews for precisely this reason. Instead, I take the developer out for lunch and spend an afternoon discussing our software stack and business with them. It always gives be better results. There is no stress. I don't want to see their code, but I do want to understand how they think and work.

Would you hire a sculpter by taking them to lunch and talking about tools but never seeing their sculpture?

would you hire a sculptor by asking them a random trivia question about the birthday of an Italian architect? FANG would.

Re: The software industry's greatest sin: hiring

#112

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…

I accidentally did a PM interview one time at FAANG and couldn't have done well, but it was fun! Really did enjoy it.

Re: The software industry's greatest sin: hiring

#113

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.

This exactly. Start with general questions and get more specific until they are unable to answer or they exceed the depth of your own knowledge on the topic. You’ll be surprised how often that good candidate will take you out of your depth.

Re: The software industry's greatest sin: hiring

#114

This makes so much sense. I've stopped doing in-depth technical interviews for precisely this reason. Instead, I take the developer out for lunch and spend an afternoon discussing our software stack and business with them. It always gives be better results. There is no stress. I don't want to see their code, but I do want to understand how they think and work.

> spend an afternoon

I've never had a full afternoon with a candidate. Maybe if I did I could avoid technical challenges.

Re: The software industry's greatest sin: hiring

#115

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…

> He explained you don't need a group by in a having statement and that I needed to go back and study sql. I sat there awkwardly [I have been writing sql since I was 14 - I was 25].

He's technically right though. For instance in postgres, you don't need to have a GROUP BY clause when using HAVING https://www.postgresql.org/docs/current/sql-select.html#SQL-...

Re: The software industry's greatest sin: hiring

#116

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.

Turns out that I don’t actually need to. For us, as developer you will almost certainly run into tech that you know very little about but need to work with it anyway. So ability learn quickly and solve problems is more important. So intellectual horsepower, analytical and problem solving skills and most importantly a sense of agency and willingness to do what it takes to ship code out is more important. If the develo…

I think credentials are sorta worthless - I've worked with people who worked at great companies, went to great schools, still very weak at coding and problem solving. I guess ymmv.

Also, you personally refactoring people's code after the fact is not a great way to go about team building - I would try to get more of this into the PR process, teach them what they're not doing rather than do it for them.

Re: The software industry's greatest sin: hiring

#117
I wrote a book on this last year, out of my frustration with dev interviews

https://www.amazon.com/Whiteboard-better-hire-best-developer...

I've interviewed and hired a lot of people over the years, and have been interviewed a fair amount. The way a lot of companies do it didn't make sense to me, so 5+ years ago I decided to figure out a better way to do it.

My basic premise in the book is that in an interview when asking someone to show skill, it should be as close as possible to what the job is. Most interviews are just not anything like a whiteboard interview or algorithm question. I get that can show how someone thinks, how they ask questions, etc. - but to be honest I rather have them actually DO something as they would do if I hire them.

I've had a lot of luck with this way of interviewing. The reality is it can still be a crapshoot - you really don't know what someone is going to be like until you work with them for a while - but this at least gets closer to making a more informed decision ('cause you basically work with someone, in a small way!)

Re: The software industry's greatest sin: hiring

#118
post #76
post #50

Earlier quoted context omitted.

> 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. If only this were true. I've co-authored a (technical) book, edited another, have dozens of OSS contributions, and GitHub projects with hundreds of stars. Everyone still tries to whiteboard interview me. Usually I tell them to screw off, but still. My theory is that (a) people are too…

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.

Re: The software industry's greatest sin: hiring

#119

To the best of my knowledge, my workplace uses a fairly traditional hiring process that's the same for hiring a programmer or a machinist: Resume screen, phone screen, on-site, offer. I have to say we do really darn well, especially given we're located in the Midwest and supposedly the brightest programmers have fled to the hot markets. One thing I like is that we get a range of ages, which is heartwarming given that…

> supposedly the brightest programmers have fled to the hot markets

Just another facade perpetuated by VCs given too much money by the market, and tech companies "faking it till they make it" in regards to actually hiring all the smartest people.

You think they would learn that the actual smartest people won't fall for someone just saying "all the smartest people work here ...", and that they are effectively attracting naive people with that slogan instead.

That being said, the high-salaries of SV/NYC/etc. will attract some of the smartest people ...

Re: The software industry's greatest sin: hiring

#120

This makes so much sense. I've stopped doing in-depth technical interviews for precisely this reason. Instead, I take the developer out for lunch and spend an afternoon discussing our software stack and business with them. It always gives be better results. There is no stress. I don't want to see their code, but I do want to understand how they think and work.

> There is no stress There's always stress for an interviewee, assuming they care about whether they get an offer.

True. I should have phrased that as less stress. My thought is to keeep the environment as friendly and stress free as possible to let the candidate forget for a moment that they are interviewing. It’s a technique I was taught at Cornell while I was doing alumni interviews for MBA candidates.
Post reply on HN