Live data from Hacker News

The software industry's greatest sin: hiring

neilwithdata.com

451–460 of 590 posts

Re: The software industry's greatest sin: hiring

#451
post #154

We (Ambra Health) a few years ago decided our "typical" multi-hour multi-week interview process was a lot of effort for pretty mixed outcomes. We realized an interview can't really answer the most important questions: how a candidate works, and what's it like to work together. So we added an option to interview by way of a paid trial period (work part-time nights/weekends for a few weeks with the hiring team). Figure…

This is very much the contract to hire route. I honestly think this is a mostly sane route, but it does leave the person to be hired in perhaps an awkward position. I have a family now, working nights and weekends is almost impossible.

Re: The software industry's greatest sin: hiring

#452
post #378

Earlier quoted context omitted.

I'm sure you get good outcomes from this, but I'd be willing to bet you are completely weeding out whole classes of people. For example, most parents or caregivers (single or otherwise) don't necessarily have the time for this. Senior engineers are less likely to want to go through this. I would guess that most of your hires are single young people. And you are already kind of teaching them to work nights and weekend…

Also, lots of companies have clauses against this in their employment contracts, or close enough, that candidates wouldn't risk it. Anti-moonlighting clauses and clauses about IP ownership, specifically.

This one is big and so often ignored. I am breaking my employment contract if I code for money or if I write code that will be used for anything. I have to get written approval for contributing to open source. Do you, as a potential employer, want to start our relationship with me violating employment contracts?

Re: The software industry's greatest sin: hiring

#453
post #429

Earlier quoted context omitted.

> paid trial period Wow, if you say so, but that seems weird to me: every job I've ever had (and everybody else I've ever seen hired at any job I've ever had) it's taken quite a while before I was really able to contribute much productively. Just getting acquainted with the codebase, figuring out the deploy process, and learning all the unwritten rules about the company culture takes a non-negligible amount of time.

Excellent candidates can and do find ways to deliver value in their first week and more in their second. Even if it’s demonstrating the ability to learn how the product it deployed and how the team work, that ability to learn quickly and communicate with the team is valuable.

As someone who's worked in over 20 companies as a technical consultant, I mostly agree. However, some companies are better than others at onboarding new engineers. My rule of thumb is to make a meaningful PR within the first week, and do whatever is necessary to make that happen. That sometimes involves bugging the crap out of people with questions, but I try to make up for it with a fast ramp and prodigious output.

Re: The software industry's greatest sin: hiring

#454

Earlier quoted context omitted.

As an employee of Google who is involved in hiring let me tell you the process is extremely rigorous and we work very hard to make it bias free. I am not an unbiased individual myself but when it comes to hiring, I work extra hard to ensure fairness regardless of other person's characteristics.

And as a former Googler who did hundreds of interviews there, let me tell you you're wrong. It wasn't bias free even years ago, and Google has gone much more hard-core SJW since then. It's still much better than at most companies, and the article we're discussing is so wrong about the way executives are hired. But Google isn't some paragon of freedom from bias, far from it. Ignore yourself. The system surrounding you…

i've only seen 2 at my workplace. There are positive incentives for hitting women recruit goals but also there are no negative consequences for not doing so.

Re: The software industry's greatest sin: hiring

#455
post #154

We (Ambra Health) a few years ago decided our "typical" multi-hour multi-week interview process was a lot of effort for pretty mixed outcomes. We realized an interview can't really answer the most important questions: how a candidate works, and what's it like to work together. So we added an option to interview by way of a paid trial period (work part-time nights/weekends for a few weeks with the hiring team). Figure…

Have you written down some kind of instructions for how you do it? What tasks to select, preparations for both sides etc. Also, do you give them tasks on your actual code base? If yes, you are likely biased towards people already familiar with your tech stack (getting really productive with an unfamiliar tech stack takes more than a week, but short enough to make hiring somebody from a different background still wort…

I've always learned new technologies and stacks as needed before I start the gig, so I can crank straight away.

Re: The software industry's greatest sin: hiring

#456

Earlier quoted context omitted.

It is true that you can succeed well at tech companies without a degree from a top school. Class, race, gender, sexual orientation are not barriers to success. That's the positive thing. The negative thing is that most tech companies heavily favor "top school" candidates and actively recruit for them. They would rather higher someone provably less qualified from a "top school" than someone else. They track and boast…

One of my previous bosses (at a large tech company) moved over to the US and was asked to hire 9-10 people in a quarter. Everyone said it was impossible. She went to LinkedIn, found people with the right skills (strong data and ability to communicate), and had a massive fight with HR because none of the candidates came from "top" schools. She won the argument, and all of the hired candidates did a great job. People (…

US is so much better than India. Indian companies openly write in job description that only people with education in premier institutes apply.

Re: The software industry's greatest sin: hiring

#457
post #178

Earlier quoted context omitted.

Don't focus on the domain, focus on the coding. i.e. don't talk about what they were doing, talk about how they did it. Where there any performance considerations? concurrency? what did they do for testing? was it automated? How the thing deployed? do they maintain it? etc. etc. In doesn't matter that in all of the above I'm talking about the code used to talk to little green men on Mars (which you know nothing about…

How much faith do you really have in these questions? This could be your entire 45 minute interview: Where there any performance considerations: Yes, the spaceship was extremely slow at first. After reverse engineering the launch protocol, we discovered that we could increase speeds by 5x simply by limiting the fuel cell usage. "Oh tell me about your rocket fuel cell usage"- Well, we have this thing called a fuel cel…

> How much faith do you really have in these questions?

It depends entirely on how you direct the converstation.

> After reverse engineering the launch protocol, we discovered that we could increase speeds by 5x simply by limiting the fuel cell usage

Tell me HOW you reverse engineered it. What tools did you use. What source did it wind up as. What problems did you encounter?

>Oh tell me about your rocket fuel cell usage

(Don't ask that question because you don't care about rocket fuel cell usage, you care about if this person is a good coder. Ask them questions about code and their person software process!)

>What did they do for testing: We used Jest. Was it automated: Yes.

Obviously it's on you to tease out more than one word answers.

If you want to have a conversation with somebody and learn if they're capable of something, the onus is on you to direct the conversation and get what you need. If you're willing to accept one word answers, then I'm thinking this "informal chat over a few hours" approach is not for you.

Re: The software industry's greatest sin: hiring

#458
post #154

We (Ambra Health) a few years ago decided our "typical" multi-hour multi-week interview process was a lot of effort for pretty mixed outcomes. We realized an interview can't really answer the most important questions: how a candidate works, and what's it like to work together. So we added an option to interview by way of a paid trial period (work part-time nights/weekends for a few weeks with the hiring team). Figure…

That sounds way better than stressing people out with inane whiteboard questions. It wouldn't work for me since I won't take a gig that doesn't lock down cash flow for at least six months. I do love take home tests that are directly applicable to the stack I'll be working in. Following up with a code review style interview is great, too. This way more closely emulates the actual engineering workflow of pulling a ticket, cranking, then submitting a PR.

Re: The software industry's greatest sin: hiring

#459

Earlier quoted context omitted.

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 minu…

Your recruiter was rating you on your performance on the algorithm question, them cutting you off was actually them trying to help you spend enough time on the question.

Good point. Maybe I'm unusually generous, but when I'm in the interviewer seat, I generally try to steer candidates into territory where they can succeed. I want to give that "hire" recommendation! But I need pull enough signal from the noise to be able to support that recommendation, and ultimately I need to measure that signal using the measuring stick defined by my employer. If I didn't need to conform to that measuring stick, I'd just do interviews that were casual conversations about projects. But I need to ask certain types of questions to measure certain dimensions.

The "tell me a little about an interesting problem" question is usually there to gauge your ability to summarize a cool problem and solution down to to an appropriately sized story. Sometimes when I ask this question, candidates just launch into stream-of-consciousness expositions, talking just-in-time as the details come to their brains. At the 2 minute mark, I start thinking come on, don't do this to yourself. At 5 minutes, I will gently try to hint to the candidate to try to summarize and wrap it up. Some people just try to fill every silence with words and I have to finally firmly yank them back and cut it off. I hate to have to do it, but if the candidate can't time-manage the answer, I have to time-manage the questions.

Re: The software industry's greatest sin: hiring

#460

> Almost no other "white collar" profession I'm aware of will so completely and thoroughly ignore your actual proven ability, historical accomplishments, and holistic qualities, as part of the hiring process. Perhaps that's because programmer is not a white collar profession? Those who don't manage other programmers are naturally at the bottom of the hierarchy, just like a machinist (clearly a blue collar profession,…

"White collar" doesn't normally exclusively mean managerial, it means 'professional' in a kind of poorly-defined, rather obsolete, classist way. A "you know it when you see it" thing. For instance, a doctor is white collar (but probably not a manager). So's an accountant, or an engineer; again, they're mostly not managers.

How about a cordwainer? Many are highly qualified professionals, and I bet they're "blue collar" all the same. They're working with their hands making shoes after all. I think this "white/blue" distinction blinds us somewhat. What really matters is how others (in particular those who have power over us) perceive us.

As for being a profession, relatively few programmers are independent. Most work under a boss, with the same hierarchical constraints as a factory worker. We're not organised as a profession. I dare say we aren't a profession just yet. Our trade is too young for us to have achieved good average competence (doubling our numbers doesn't help, and is an indication that there's no selection pressure yet).

The only thing that makes us "white collar" is that we work in clean environment, without physical exertion.

Post reply on HN