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

51–60 of 266 posts

Re: The Hiring Post

#51

Post by loumf »

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 use Google doc because I don't care if the syntax is perfect. Those IDEs do and when someone is nervous, they make simple mistakes and can't see them right away. It spirals from there.

I ask people to do the best they can to get the syntax right, and I will ask for corrections if it's way off.

Re: The Hiring Post

#52

Post by meowface »

eps wrote: 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…

Yeah, that's the only real problem with remote work sample tests.

Thankfully, with application security, you can mitigate most kinds of cheating by presenting a custom-written black box and require a candidate to attack it in some way. Unless previous candidates are leaking or sharing info, there's not that much you can do to cheat on that, especially if you have some reasonable time limit (< 5 hours).

Re: The Hiring Post

#53

Post by rdtsc »

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 good post. Thank you for sharing it. I've been interviewing applicants quite a bit lately, so have been thinking about these issues.

Two questions for you.

What is your experience hiring fresh college grads? Is the process different? Since one of goals of the process seems to not arbitrarily adjust it for every candidate, but rather stay consistent, do you think it makes sense to adjust it for someone who just graduated. They might have been learning computer science type stuff, data structures, did a few group projects and have certainly been practicing the typical interview puzzles, fizbuzz and O(n) times of the all data structures.

How do you account (or do you account at all) for culture fit. That is a fuzzy and slightly dangerous area. Is there a score in that regard? There are some people who are brilliant but they do not work well in a team, or rather would not well in one particular team. This is course full of danger as "culture" fit often becomes an opaque discriminator for racial, sexual and other stereotypes. "He's just not a good culture fit" is such an overload euphemisms that I feel kind of sleazy just saying.

Re: The Hiring Post

#54

Post by patio11 »

BinaryIdiot wrote: post #40
tptacek wrote: 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 Thomas is saying that, if the process is repeatable, then the person who possesses a black box which ingests smart person on the left end and outputs a programmer can rent that box to industry and charge, well, billions of dollars for its use. (Fermi estimate; cost of college education to credential the number of engineers AppAmaGooBookSoft will hire this year was on the order of 10^5 * 10^4 = a billion dollars.)

Re: The Hiring Post

#56

Post by knite »

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

Thomas,

Great article. The prelude to the interview with books given to candidates is especially interesting. I'd love to see that reading list, and would further like to suggest posting it on your careers page. I would imagine that anyone who goes to the trouble of working through your suggested materials would be providing a very strong signal of quality and investment.

Re: The Hiring Post

#57

Post by tptacek »

rdtsc wrote: post #53
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 good post. Thank you for sharing it. I've been interviewing applicants quite a bit lately, so have been thinking about these issues. Two questions for you. What is your experience hiring fresh college grads? Is the process different? Since one of goals of the process seems to not arbitrarily adjust it for every candidate, but rather stay consistent, do you think it makes sense to adjust it for someone who just g…

Everyone has exactly the same process, with the exception of interns. Interns have an abbreviated interview (shorthand: we switch from assessing aptitude to assessing enthusiasm), and any time one came back looking for a full time job, they got fast-tracked. I'm not saying that was the best policy (it did keep us from collecting some extra data), but by the end of an internship you had a really good idea that you wanted to work with someone.

The lede I buried in this post is that we hired more-or-less resume-blind. I had final call on every hire and went through some effort not to look at resumes. On our first-calls, I'd ask some questions that would give me background hints about candidates, but that was primarily to tune my spiel (I didn't want to explain blind SQL injection to someone who'd spent 3 years as a pentester already, for instance).

If I had it to do over again at Matasano, I'd have done it formally resume-blind. Only Dina would have had access to resumes, and interviewers would be forbidden to ask resume questions. The process would have worked better if resumes were firewalled out completely.

There was no culture fit score; in fact, if you gave subjective feedback ("passion", "confidence", "work ethic") your feedback was likely to be discounted. We were proud of the culture diversity we managed to scrounge out of our candidate pool; to have team members with kids who needed to keep strict hours, and team members who'd roll in at 11 and still be there at 8 working on a pet problem. We had drinkers and non drinkers, college students and people with 15+ years of dev experience.

You could get booted from the process for being overtly an asshole (I, for instance, might not get hired), but that happened very rarely and with crystalline clarity.

Re: The Hiring Post

#58

Post by tptacek »

knite wrote: post #56
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".

Thomas, Great article. The prelude to the interview with books given to candidates is especially interesting. I'd love to see that reading list, and would further like to suggest posting it on your careers page. I would imagine that anyone who goes to the trouble of working through your suggested materials would be providing a very strong signal of quality and investment.

Here's a version of it: http://amzn.to/cthr46

Re: The Hiring Post

#59

Post by [deleted] »

eps wrote: 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…

[deleted]

Re: The Hiring Post

#60

Post by cableshaft »

msoad wrote: post #46
cableshaft wrote: post #31

Earlier quoted context omitted.

Can confirm. They used Google Docs with me as well. I didn't find it to be all that bad, actually. Their back-to-back whiteboard interviews later on were much more nerve-wracking.

Did you get the job? I have the interview next week. :S

No, they passed, but invited me to apply again in a year and a half. That was a couple years ago, and their recruiters have started emailing again, so I guess I didn't do too terrible.

When they told me they passed they also told me that "some people get passed the first time and then study for the next 18 months and do amazing the next time!" and I just don't have the time for that. I already worked myself half to death in my twenties for two startups, I'm not going to study for a test as a second job for a year just to get a job at Google, although I still think it'd be fun and clearly challenging.

I recommend studying your ass off for algorithms (specifically figuring out what algorithm would be best for different real world problems, especially in regards to various Google products, including those you've never really used before) and practicing writing code on a whiteboard before you go. I studied for a solid week and a half beforehand, and it wasn't enough. I was prepared, just not prepared for what they asked me.

That's a common issue I have with these interviews, is that computer science is such a vast field that it's impossible to have everything in your head ready to shoot off in any interview, but interviewers somehow think that if you missed a question or two you're somehow not qualified to work for them, despite having years of direct experience at companies beforehand and being able to Google and refresh literally any topic you might encounter at your job in less than a minute.

Google seemed better than most at that, though. I still found the experience to be valuable and interesting.

Post reply on HN