Live data from Hacker News

The Hiring Post

sockpuppet.org

71–80 of 266 posts

Re: The Hiring Post

#71
post #43

We went through the phase when we gave candidates a problem and let them work on it remotely. It was in an embedded C shop that did a lot of kernel work. Basically, we'd give a short programming task (say, to write an intrusive AVL tree container in C) and 24 hours. Guess what? HALF of candidates cheated. Meaning that when the got called for an in-person interview, they stumbled to explain how "their" code worked. To…

I'm not sure the conclusion here is that remote tests are bad. It's also possible that your screening methods didn't do a good enough job. (As a disclaimer, I'm a terrible interviewer, but...) I believe that by the time a candidate gets into a room with me, that my team and I should have a good idea about whether this person will work out or not. If I make them take time out of their day, and I take time out of my day, and then 10 minutes into it I realize they don't know what they're talking about, I see that as my screw-up. I shouldn't have let them get this far. You know what I mean?

Right now at my job, we don't do a good enough job of this. I get candidates that walk through the door that can't code more than "Hello World!" without screwing up. I'm not happy about that.

This post, I think, enumerates a large number of things that you can do to determine worthiness before they even walk through the door -- the remote test is only a small part of it. If all you're doing is a remote test, then maybe you need to do more, yes?

Re: The Hiring Post

#72
post #27

Author. I can talk in a pretty good amount of detail about how exactly our process worked, if anyone has any questions. And, to head off a concern a reviewer gave me: from 1997-2005, I was a full-time software developer; I shipped shrink-wrap boxed software on Windows and Unix in the 1990s, then appliances deployed at tier 1 ISPs. I'm a "software person" more than a "security person".

Just wanted to let you know that I really enjoyed reading your article and will probably crib shamelessly from it in the future☺

I will second the value of a work sample. It's so simple that it feels incredible that we didn't do them in the past. What my team __hasn't_ is issue the exact same work-sample problem; you make a compelling argument for doing that, so I think that we'll implement it.

Re: The Hiring Post

#73
There are a lot of 'hiring is broken' posts and this is a decent one, but I don't think I'm alone in feeling that none of them convincingly identify the problem, let alone solve it.[1] So I'll do that here.

Hiring isn't broken because people use the wrong interview questions. It's broken because firms are engaging in a zero-sum battle for talent. But if what you're doing is worth a damn, it should be worth a damn when ordinary people do it. If what distinguishes your company is that you've managed to hire smarter people, maybe your company isn't so great.[2][3]

The proper hiring criterion is pretty simple: do the people who will be working with the candidate like her? In Blink, Gladwell presented good evidence that formal interview process isn't any more objective than this. And when you think about it, what would "objective" even mean?

There's also an issue with the labor market -- in particular, the difficulty of firing. You're much better off hiring liberally and firing candidates that don't work out. If all firms did this, the labor market would be more efficient and firing wouldn't be so bad.

Apple is a good example. Their profit per employee is second only to Netflix among large tech companies, and this includes a significant fraction of retail personnel. Apple's profit per engineer is probably higher than Netflix's, and that's remarkable considering they're over twenty times bigger.

Does Apple achieve this with some optimized interview format? Higher salaries? Onsite massage? No, they do it with better products (and a command and control governance model...).

It means that the software industry isn't nearly as innovative as it thinks it is. This is actually so obvious it's the subject of popular jokes ('like airbnb for pet food' etc). It's also obvious when you consider the ratio of effort spent building tools to products. All the latest frameworks but... Where are the apps? Where are the apps that are even half as feature-rich as a typical Windows application from the '90s? Google Plus still can't keep which things I've +1'd straight.

[1] It reminds me of the situation with essays claiming to explain why privacy is important even if you 'have nothing to hide'. See https://gist.github.com/clumma/414f0c9a8fedf9ba9db5

[2] https://twitter.com/clumma/status/139082596587012096

[3] Or worse, that you've managed to deprive your competition of smart people. Google has done this -- hired people without having work for them to do, on the reasoning that something might come up and at least they won't be working for the competition.

Re: The Hiring Post

#74
post #70

Earlier quoted context omitted.

How do you avoid wasting time on candidates that are a poor fit? When we advertise for an open position we get a ton of unqualified candidates. In your post you say, "At my last firm, we had the “first-call” system. Every serious applicant got, on average, 30-45 minutes of director-level time on the phone before any screening began." You seem to continue on from that point. What happens before first-call?

To me, recruiting is two problems: outreach and qualification. You're asking about outreach. How we did outreach is a whole 'nother blog post, and one I'm bound to write soon. What surprised me about recruiting was how much more important qualification is than outreach. Without good qualification, it almost doesn't matter how good your outreach is, because you're filtering for the same highly visible easily accessibl…

Maybe I wasn't clear with my question. Say the company indicates it is hiring and gets 100 interested people. How do you filter them down to serious applicants without looking at resumes? I would argue that isn't so much outreach as it is qualification, as the people are already interested.

Maybe my premise of 100 candidates is incorrect based on how you did outreach?

Re: The Hiring Post

#75
post #66
post #62

Work-sample questions is not free from its own evils. They are expensive to device. At big companies, significant portion of candidates dump out their interview questions on Internet so that's a big challenge. Second, work-sample type of questions are also expensive to answer for candidates so you can probably just ask one question as part of whole interview and that's about it. So any conclusion is drawn from sample…

We had three work-sample exercises at Matasano. All told, they took candidates mid-single-digit hours to finish (many geeked out, or golfed on them; we did our best to keep this from happening --- you can read about this on our hiring page: http://www.matasano.com/careers This sounds onerous, but it is less onerous than the normal dev hiring process, which involves an onsite interview that eats the whole day. We did…

s/our/their

Re: The Hiring Post

#76
post #21

Earlier quoted context omitted.

I know how to turn someone who can't code into someone who can. If you can do that reliably, you should be making zillions of dollars. My experience is the opposite: if someone is very impressive in an interview but a zero on the team, they're an intractable management problem. In any case: there is a difference between being cripplingly antisocial and being able to deftly handle an interview. The social skills requi…

> If you can do that reliably, you should be making zillions of dollars. I disagree to a degree; I've met many people who were simply fantastic with figuring out problems but didn't know much software development and they ended up being awesome software developers. It's certainly doable and I don't think it's so difficult that someone who can do it should be making an obscene amount of money but they are not cheap ei…

I think you're more wrong than right, and it's selection bias that gives you confidence here.

There are people from all sorts of backgrounds that can become very good developers, but their common feature seems to be that they were already the sort of person who could become a good developer, not any methodology used to train them.

For example, I'm confident most talented physics Ph.Ds[1] can make decent developers of numerical code, but that says more about them than it does about my skill at training.

Given a random person, hell given a random person who is already decent developer in a different domain, my confidence in their ever becoming very good at that domain is much lower.

[1] the problem then being, that pool maybe smaller than the one you are trying to populate....

Re: The Hiring Post

#78
I really hope companies read and learn from this. It is absolutely maddening how bad hiring currently is. As someone who has been on both sides of the hiring process it's just frustrating. If you are being interviewed you are basically put in front of a firing squad. If you are interviewing you are the one pulling the trigger. Maddening. I'm taking this and showing it to the ceo of the company I work for currently.

Now, tptacek:

What can I do to make this better? How can I contribute?

Re: The Hiring Post

#79
I have had my share of bad interview questions too. The worst part is when the interviewer starts working on their laptop, like they are so bored of this question they can't think about it any longer. Yet it is now a part of my life for 45 minutes.

At the end of every trivia question I'm tempted to ask: so is this typical of what I will be doing here? Will I be implementing rand(7) given rand(5) once a week?

I've also had a bad experience with code challenges. These are given before the first phone interview. I'm happy to do a challenge taking I've realized that code challenges require no investment on the company's part, so I don't want to do one that requires significant investment on my part.

Re: The Hiring Post

#80
The same kind of process works for pure dev jobs. So, you’re a Rails shop? Take a Rails application you’ve actually built and deployed. Carve out some functional areas from the application: remove the search feature, or the customer order updater. Bundle up the app with all its assets, so that a single “vagrant up” gives a candidate an app that runs. Have them add back the feature you removed.

How would you compensate for candidates that are great developers but are new to Rails, or whatever specific language/framework your company uses?

Post reply on HN