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

91–100 of 266 posts

Re: The Hiring Post

#91

Post by MichaelGG »

avalaunch wrote: 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 compensat…

It sounds like the candidate gets to do this at their own pace, from home. If so, a good dev shouldn't have trouble learning enough Ruby/Rails to figure this out.

Re: The Hiring Post

#92

Post by tptacek »

chloridite wrote: post #84
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".

How often is it that a candidate shows positive on work-sample tests but then shows negative after a face-to-face interview? Should you explain negative outcomes to the rest of the company or to the candidate?

I can think of a couple times when work-sample overrode face-to-face. I'm sure face-to-face overrode work-sample at least once (we had a scoring system, and the threshold for getting a face-to-face interview was not "perfect score"; you could be "on the bubble" and get an interview), but to my knowledge it never overrode a very good work-sample score.

Re: The Hiring Post

#93

Post by dripton »

tptacek wrote: post #9
sdevlin wrote: post #8

Earlier quoted context omitted.

I once had a phone interview wherein I was required to write some code and then read it to the interviewer (character by character!) over the phone. I asked him whether it would make more sense for us to use etherpad (this was maybe five years ago), but he said no.

Have you ever had a productive phone screen? I think they might all be evil.

Yes, I recently had two productive phone screens, as a candidate.

The first one taught me a bit about the company and team, and gave me a good impression of the interviewer (the hiring manager), which then led to me doing a work sample. (Without the phone screen I don't know if I would have sunk several hours into the work sample.) I ended up getting an offer but not taking it.

The second one also gave me a good impression of the company, team, and interviewer (a senior engineer) and led to me doing an full day of interviews. Which led to me accepting an offer. The one used Collabedit in addition to the phone.

I know they're not perfect, but it's much cheaper to talk on the phone for an hour than to fly someone in for face-to-face interviews. Given way more resumes than resources for in-person interviews, I'd rather narrow the field using phone screens than narrow the field based solely on what's in the resumes.

I saw the part in your article about work samples, and I agree that they're great, but they are significant work for the candidate. So I think it makes sense to do have some kind of phone call first, to see if there's enough mutual interest to make it worth the candidate's time.

Re: The Hiring Post

#94

Post by yeukhon »

I posted this before but someone decided to downvote, whatever, I think this is my version of hiring!

1) start with basic textbook questions like what is authenticity and authentication or XSS

2) catch what the interviewee said and build questions (e.g. I said something about private key so interviewer asked me about pro and cons of asymmetric and symmetric encryption). Oh yeah - know your shit because they are going to catch you! It's okay to say "I don't know." Being straightforward earns respect. My interviewers didn't penalize me much (well I just graduated from college...).

3) the next couple interviews again starts with introduction, then deep dive into what the team does, what the team is building at a high level, then proceed to ask me my interest. Here i would talk about my ideal projects, show them high level how I would go about implementing my idea, challenges I face (and also why I have to build one; are there any existing solution and are they not adequate). Take caution of your words - know the things you say aloud.

Somewhere in those 4-6 interviews, add a programming sessions if you haven't done so (for me I skip that and went to onsite because of internal referral).

I didn't get an offer probably because I didn't quite know what I really want to build. My idea was too generic and probably too "child play." It was a really intense and yet fun interview. This interview process allows interviewer and interviewee to see if they are a match or not quickly and pleasantly. I always look back at this interview and believe that the rejection is just and great for me and for the team.

Re: The Hiring Post

#95

Post by tptacek »

dripton wrote: post #93
tptacek wrote: post #9

Earlier quoted context omitted.

Have you ever had a productive phone screen? I think they might all be evil.

Yes, I recently had two productive phone screens, as a candidate. The first one taught me a bit about the company and team, and gave me a good impression of the interviewer (the hiring manager), which then led to me doing a work sample. (Without the phone screen I don't know if I would have sunk several hours into the work sample.) I ended up getting an offer but not taking it. The second one also gave me a good impr…

There's a semantic gap getting in the way between us. Phone calls with candidates: very good. See "Warm up candidates" in the post we're commenting on for my thoughts about that.

A phone screen is a call whose purpose is to select out candidates. It's a call whose outcome can be "stop talking to this developer". They're very common, and I think uniformly evil.

Re: The Hiring Post

#96

Post by MichaelGG »

dropit_sphere wrote: post #42
baddox wrote: post #12

> The majority of people who can code can’t do it well in an interview. Major citation needed. I don't have any real data either way, but I find this extremely hard to believe.

I don't at all . Yeah, sure, I can buzz your fizz with my eyes closed in brainfuck. But that's just measuring language facility. The real tests are more topical, and more complex: is there a way to make this code run faster? There are two types of good candidates that will get that question: 1) the kind who have run into the problem before and know the answer stone cold, and tell you instantly 2) the kind that have n…

What about kind 3, the ones that can derive the solution from scratch, in their heads? I thought that was the point of most of those questions. Like "given two linked lists, what's the fastest way to determine if they share any nodes (not values, but actual nodes)"? MS gave me that one in a phone screen and I'd never written a linked list before. But if you actually know what a linked list is, this should be simple for you to derive relatively quickly (not Googling for a day).

If a candidate needs a day to learn up about something trivial they should be able to derive in minutes, then that kind of thing might compound and end up producing a huge difference in actual productivity ("all other things being equal").

Re: The Hiring Post

#97

Post by [deleted] »

baddox wrote: post #12

> The majority of people who can code can’t do it well in an interview. Major citation needed. I don't have any real data either way, but I find this extremely hard to believe.

[deleted]

Re: The Hiring Post

#100

Post by Iftheshoefits »

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 to demean and diminish human beings.

It's just a toxic environment.

Post reply on HN