Live data from Hacker News

The software industry's greatest sin: hiring

neilwithdata.com

221–230 of 590 posts

Re: The software industry's greatest sin: hiring

#221
post #137

Earlier quoted context omitted.

> and that I needed to go back and study sql I once had an interviewer with two (TWO!) PhDs. He made sure that I knew he had two (TWO!) PhDs by handing me his business card as we sat down and casually remarking that he had two PhDs (see, right there, two of 'em, yupperoo). This behavior ("he's kind of jerk, and he has two PhDs") had been accurately foretold by the prior interviewer (that session had gone great). The…

No sane non-narcissistic person will ever fathom doing 2 PhDs. You do a PhD to learn how to think and research things. The only reason you would imagine doing a second one (assuming you're not someone who completely misunderstood what a PhD means), is so you can boast about it.

What utter rubbish. I know several people with two PhDs - for example one guy who went from theoretical physics to economics - and they are all humble and brilliant.

If I didn't have a family to support and a mortgage to pay, I'd consider doing a second PhD, given how much I enjoyed my first.

Re: The software industry's greatest sin: hiring

#222

Earlier quoted context omitted.

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…

> And a few angry senior engineers out there saying "Why do I have to keep writing fizzbuzz? Its like I have to prove over and over again that I can program at all!". You didn't address this part of the problem. This friction is one of the reasons the job market is so distorted.

Oh sorry I wasn't clear. The reason is that successfully completing a simple programming exercise puts you in the top 15% or so of resumes that get sent in for most programming roles.

When you apply for a company, they have to assume you aren't very good, because most people who apply aren't very good. (Because people with strong skills get snapped up, and people with weak skills spam their resume everywhere they can.). Figuring out who's worth spending time interviewing is a hard problem in itself. And there's no silver bullet here - people lie about their work experience all the time. There are so many user accounts on github with copies or forks of random people's code, with basically no changes. I suspect they exist support lies on resumes.

I don't think it distorts the market, but it is annoying. A recruiter I talked to a few years ago said she thinks its crazy we don't use an agency model for programmers like actors do. The idea there is that good programmers pay a small percentage of their salary to a manager, who's job is to find you the best roles that suit your skills and negotiate pay on your behalf and so on. She tried to set up a business doing just that but she couldn't get enough clients to make it work. Good programmers balked at the idea of paying a few % of our salary to someone in an ongoing way, to look after our career. Having to prove your skills in each and every interview, and form those social connections on your own? Thats a choice we make.

Re: The software industry's greatest sin: hiring

#223
I interviewed for an agency in my city. The first three interviews went well. Then the interviewer vanished for a week or so. I thought things were done after following up a few times with no response. Then I heard from them again a month later, the position was infilled and they wanted me to come in and meet the team.

So I did, they made fun of my suit, they grilled me and then acted like I was unsure of the job roles... however I’d gone over them many times in the listing, prepared, and had three successful interviews. The person I originally interviewed was there, I have him an odd look, he gave me an “I’m sorry” shrug. And I left, perplexed. I was polite and professional the entire time.

Then they called again, now the CEO wants to meet me face to face. So I did, the other person who was his partner didn’t show up until 40 minutes later. I was having a great time with the CEO and asked him a lot about how he built the company, what the future looked like, and what Em he enjoyed most about the culture. I was getting into my work and history when the second individual showed up. He arrived, interrupted the story unintroduced, made fun of my suit, looked at his watch, and gave me an annoying look.

I started from the beginning as requested, I got a sentence in and he nudged the CEO and said “were late”. And that was that.

While they were walking away he made fun of my suit again.

Re: The software industry's greatest sin: hiring

#224

Earlier quoted context omitted.

It’s largely still that way - you need to know someone to get the referral to get the whiteboard interview (after two phone screens). That said it’s at least a partially objective skill check and I don’t know a better way.

Counterexample: I got an interview at Google a few months ago, with no referral and one phone screen.

Yeah it's not impossible, but it's not easy.

Did you go to MIT, Stanford, Berkeley, CMU, Harvard, a different highly selective University?

Were you previously working at another highly selective/famous company?

If so it's pretty easy to get the interview, if not it's pretty hard without a referral.

Re: The software industry's greatest sin: hiring

#225
post #54

Earlier quoted context omitted.

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.

I don't get what is wrong with expecting a candidate to have carefully read an algorithms book at some point in their lives. Most software engineering jobs expect a degree in CS, that implies 3-4 years of study. You should be able to remember important information related to CS.

Re: The software industry's greatest sin: hiring

#226

People who hire developers wouldn't be as focused on the candidates' experience with the technology in the job ad if developers were typically more open for new tech that would be learnt at the job. Try to teach a 40+ Perl developer a new language if you want to see what I mean... When you compare IT with other industries like the author did, this is what makes hiring so different. Other industries are fine with hiri…

I’m almost 40. I can learn new programming languages just fine, thank you. And new languages/tech generally aren’t too hard to pick up once you’ve learned a few, for the most part.

They do a lot of the same things, just the incantations are different.

I do have more non-coding hobbies now and other responsibilities sucking up more time than when I was young, so I don’t have as much time to learn them on my own, but I still can and do learn them, especially if needed at work.

Re: The software industry's greatest sin: hiring

#227
Anecdotal evidence:

Several times in my life I've had the strange luck of being told the internal workings of a decision after I was rejected for a job. Usually somebody from the interviewers liked me but couldn't convince the others, and subsequently decides to find me on LinkedIn and send me a direct message.

The messages have been eerily similar and are usually like this:

"Hey Dimi, I want you to know that I think you would be a perfect senior dev for our team. But the other guys said you were awkward part of the time, you didn't feel like you'll fit with the rest of us, and one of them heavily emphasised that you hesitated before answering one question very specific for our work... and when I pressed them to elaborate further they just angrily told me that I don't get it.

I wish you luck in your future searches but you should know that if it were up to me you'd be working with us now."

You can lose your balance for a minute while being evaluated live by several people? You can hesitate before answering a trick question about a niche project? Imagine that.

It's really bittersweet to get these internal insights and can make you want to pull your hair out -- but it did give me the perspective that most of the people charged with hiring go by a gut feeling and personal sympathy.

Re: The software industry's greatest sin: hiring

#228

Earlier quoted context omitted.

Unfortunately, I don’t think there’s much data around hiring outcomes because companies really don’t have a reason to share that information. For a lot of people, it comes down to personal experiences. I’ve definitely interviewed with companies where I was put in really unnatural situations that I struggled to shine in. For example, I bombed an interview in which I had to do a live coding challenge where I had to tal…

Not sure where you interviewed maybe it's not relevant, but a lot of jobs you will not always be in a position to do the work 100% isolated and by yourself and sometimes there will be other people in the room.

And most of them will be not actively evaluating your skill constantly.

Re: The software industry's greatest sin: hiring

#229
post #98

Earlier quoted context omitted.

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-...

I thought about this myself as I went through this exact course. For context I had been exposed to and even implemented some of the concepts (like db sharding) at work but much of it was still new to me.

An ideal interview should reflect the actual work you'll do during the job. And I think system design interviews accomplish that job pretty well (certainly much better than coding interviews). Will you ever have to design and build a system like you during the interview? Likely not - a startup, while does require building a lot things for scratch, rarely requires the scalability and intricacy outlined in these interviews. While large companies will have the components broken up by team, so you'll often be silo'd into just one part.

That said, knowing how your systems work at a high-level is much more useful than knowing something like shortest-path algorithms. Even if you are silo'd, understanding upstream/downstream interactions can be crucial.

Re: The software industry's greatest sin: hiring

#230
I think it depends on the company. In a small company it's vital that developers understand user needs and want to provide a great user experience. Bigger companies can, but not always will - see Google, have dedicated people to think about the product the user experience and how the product should catter to a particular user base. Those people can translate the requirements for developers.

I am not saying that developers should be autistic and completely ignore anything that is not code related but it can be done. Google failed but others succeeded, see Adobe or Ubisoft.

I certainly like to code and like technical intricacies but I always looked to code from an entrepreneur pov: always trying to work on something which will be useful for someone and ask myself what feature is going to be useful, to how many people and in what way. I did my share of "inverting binary trees" but that was when I was a student and needed to learn. I always tryed though to use such a technique to solve a real issue.

Maybe CS programs at universities should start teaching not only CS and programming courses but also concepts about thinking products, understanding user needs, assessing user needs.

Architects are trained not only on visual and technical aspects of planning buildings but also on understanding user needs and making the building useful for a particular customer. It's useless if a house looks good, uses clever technical solutions but no one is wanting to live in it.

Post reply on HN