Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Hiring Post

sockpuppet.org

Post reply on HN
Print view View original

211–220 of 266 posts

Re: The Hiring Post

#211

Post by elptacek »

eru wrote: post #178
elptacek wrote: post #130

Earlier quoted context omitted.

When I was at Matasano, there was always enough inbound work (sometimes more than enough) to keep the consultants utilized. So yes, a company with a full pipeline will lose money on every qualified hire it doesn't make. Perhaps this is not the case for other industries, but for infosec consulting, there seems to be more work than there are qualified workers. Matasano ran under its own steam and did not take funding.…

Did the salaries of the bargain candidates creep up as their value was realized?

I do not know. I suppose even if I did, it's one of those things nobody is supposed to discuss. I overheard talk here and there about raises, but since it didn't pertain to me, I ignored it.

Re: The Hiring Post

#212

Post by elptacek »

korethr wrote: post #110

Reading this, I am filled with both hope and dread. The hope that as more companies figure this out, there will be more and more companies with interesting, challenging and rewarding work as opposed to companies that are only a paycheck, and as soul-sucking one at that. The dread is that I would never make the grade at the former kind of company.

Every time I sit down to solve a problem with code, I feel dread. Every time I even think about strapping on my skates, I feel so much dread that my stomach hurts.

I think that dread cannot be decoupled from hope. And that this is especially true for folks with higher developmental potentials.

Re: The Hiring Post

#213

Post by vonmoltke »

dougabug wrote: post #206
beefman wrote: post #117

Earlier quoted context omitted.

I agree. But why are they so choosy, and why do they complain about a lack of qualified candidates when their rejection rates are so high? I think it's the zero-sum game I mentioned. Firms are trying to outhire each other, like talent is some magic wand that can replace compelling products. There's a lot of snake oil in the industry, like SEO (now called "data science"), meant to substitute for things like vision, le…

I don't know if it's exactly a zero-sum game, but the rate at which talent is created doesn't seem to be amazingly high given that there are over 7 billion people on Earth. Certainly the talent pool seems to be a small fraction of the population. Top universities, which for the most part feed the tech industry, face a similar problem at an earlier stage in the pipeline. It's been noted that less prestigious universit…

I think part of the problem is that hiring bars are unrealistically high. Pulling numbers out of my ass for illustration, it's like companies that control 10% of the software engineering jobs all only want to hire the top 5% of software engineers. They can't all get their way, so the top 5%[1] bounces between these companies whilst the companies whine about "talent shortages".

[1] Should be noted that it isn't the entire group, since some will choose to work for organizations outside this group because the work is more interesting or fulfilling.

Re: The Hiring Post

#214

Post by krakensden »

bootload wrote: post #201
eru wrote: post #131

Earlier quoted context omitted.

Google still does interviews. They try to do them better --- eg separating the hire / no hire decision maker from the face to face interviewer. But I'd like to see them try out more work samples. I'm going through interviewer training at Google at the moment. (There's a few courses they like you to take before letting you loose on candidates.)

thx for replying @eru, I don't envy the task evaluating candidates. By work samples do you mean real code you've created to solve problems? “bring the same level of rigor to people-decisions that we do to engineering decisions.” [0] The weakness at google is understanding people. So I can understand the allure of HRA (HR Analytics) but feel google is missing something not intuitively understanding people and behaviou…

Let's be honest- the 'rigor' that people bring to engineering decisions is oversold.

Re: The Hiring Post

#215

Post by fsniper »

calcsam wrote: post #5
steakejjs wrote: post #4

Great post. I hate interviewing. I think a lot about it since I'm the type of person who performs horribly in an interview call when some person I've never met is asking me trivia questions on speaker phone... One thing I wonder. Why are people being interviewed for technical positions in a google doc or whatever fake coding environment? Servers are cheap. If you have to go the way of the technical phone interview, d…

We use HackerRank, which has an in-browser IDE that can runs pretty much every language, has highlighting, etc. I can't believe anyone would use Google Docs. Even if you don't care about your interviewees' experience, huge waste of dev time.

I just got an interview with HackerRank and it sucked. It has some absurd code completion and a browser is not a good place to code in.

I tried to copy/paste in/out from vim and it was a disastrous process. Nearly I could not use my previously implemented bst implementation. (Which I was told to).

I screwed the test - of course it was not HackerRank's problem - and retried in vim after time ended. I could code it in a fraction of the time that I could in that ide. Time limits never work for the candidate.

Re: The Hiring Post

#216

Post by mtviewdave »

Iftheshoefits wrote: post #100
beefman wrote: 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 whe…

I think hiring is broken for a different reason: workers, whether in software or any other industry, are viewed as less-than-equal ("second-class citizens"). Except in rare cases the entire hiring process in software especially, from start to finish, just about everywhere I've ever interviewed, seems to me designed to find reasons to reject candidates, and as a side-effect is (perhaps unintentionally) also designed t…

>just about everywhere I've ever interviewed, seems to me designed to find reasons to reject candidates

I'm sure that's intentional. Joel Spolsky wrote an influential guide to interviewing in 2000 that lays out this philosophy; the latest version (updated in 2006) is here:

http://www.joelonsoftware.com/articles/GuerrillaInterviewing...

The gist of a large part of the article is that interviewers should have a preference to saying "no hire", because bad hires are toxic and hard to get rid of.

But then he writes this:

----

Of course, it’s important to seek out good candidates. But once you’re actually interviewing someone, pretend that you’ve got 900 more people lined up outside the door. Don’t lower your standards no matter how hard it seems to find those great candidates.

----

Which is terrible advice if your standards are, in fact, unreasonable.

Re: The Hiring Post

#217

Post by calinet6 »

Micaiah_Chang wrote: post #107
tptacek wrote: 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".

Have you ever read The Checklist Manifesto [0]? I may be reading too much into this post, but the lessons you learned from this interview process have frighteningly close parallels to the lessons in the books. I doubt the book had any influence on your interview process, seeing as it was published after the interviews were formalized, but the book seems like it might have new lessons. For example, a good portion of d…

Extremely true. This is about systematizing the right things about interviewing, and making them solid. Checklist Manifesto is all about that, a great simple way to create systems that work.

At a high level, this is all about Deming ( http://en.wikipedia.org/wiki/W._Edwards_Deming ) and TQM concepts -- if you want to achieve a high-quality output, measure the things that matter, and understand the variation present in the system. Once you have a stable system with good data achieved by good methods, you may then begin improving it. Attempting to improve a complex system without knowledge results in unpredictable changes—we call that tampering. Simple but beautiful.

So, in essence, this is an extremely natural and correct application of quality management principles to the hiring process. Stellar.

Re: The Hiring Post

#218

Post by calinet6 »

Micaiah_Chang wrote: post #107
tptacek wrote: 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".

Have you ever read The Checklist Manifesto [0]? I may be reading too much into this post, but the lessons you learned from this interview process have frighteningly close parallels to the lessons in the books. I doubt the book had any influence on your interview process, seeing as it was published after the interviews were formalized, but the book seems like it might have new lessons. For example, a good portion of d…

Extremely true. This is about systematizing the right things about interviewing, and making them solid. Checklist Manifesto is all about that, a great simple way to create systems that work.

At a high level, this is all about Deming ( http://en.wikipedia.org/wiki/W._Edwards_Deming ) and TQM concepts -- if you want to achieve a high-quality output, measure the things that matter, and understand the variation present in the system. Once you have a stable system with good data achieved by good methods, you may then begin improving it. Attempting to improve a complex system without knowledge results in unpredictable changes—we call that tampering. Simple but beautiful.

So, in essence, this is an extremely natural and correct application of quality management principles to the hiring process. Stellar.

Re: The Hiring Post

#219

Post by log_n »

Offler wrote: post #186
fsk wrote: post #157

Earlier quoted context omitted.

As a candidate, I've soured on work-sample tests. Too many times, I've done the assignment, and not even gotten an interview (and I know I submitted a correct answer). As someone who already has a job, committing a large number of hours for the chance of an interview seems like a waste of time. If every employer demands a 5-10 hour work sample test before they even talk to you, that really isn't a scalable solution f…

They can be enjoyable tests. I have learnt new things while doing some.

Yeah, those are the ideal. A lot of us are already learning different things during our down-time. An enterprising company could take that drive to learn new things to find potentially good employees by 'tricking' them into learning something new from them.

Re: The Hiring Post

#220

Post by Kaedon »

tptacek wrote: 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".

Very interesting, thanks for sharing! It made me think about how we could improve our process.

Couple questions for you. How do you go about choosing which metrics go into a grade when designing the work sample test? Should the process of grading it be completely automated, so as to eliminate bias? What's the ideal length of time for a work sample test, in your experience?

Post reply on HN