Live data from Hacker News

The Hiring Post

sockpuppet.org

41–50 of 266 posts

Re: The Hiring Post

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

It's funny, because to change it, you have to admit that the way you were doing it before is not effective. I've come across many people who admit that they are bad at being interviewed, but very few people I meet have admitted to being bad at interviewing others. It's incongruous with the results, because these are the same people that have hired folks that we all agree are not exhibiting the level and characteristics that they are supposedly screening for.

Good job coming up with something different. I hope it's really working out as well as you say.

Re: The Hiring Post

#42
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 no experience in that particular area (say, search algorithms) but are google-proficient, such that if you give them a day or two will talk your ear off about them.

In a work situation, the two are really equivalent. After a day, 2) is indistinguishable from 1).

But when interviewing?

Re: The Hiring 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 say that I was shocked is an understatement. It's bloody obvious that such blatant cheating would surface within the first week after hiring and yet they cheated :-| In the end we had to switch to the in-person interviews only and implement few other things to discourage cheating.

In other words - YMMV, what works for others may misfire miserably for you.

Re: The Hiring Post

#44
Overall a really good article. I feel however that if I'm interviewing for a job, I've already lost. It probably means that I haven't been 1) working my network and nurturing those important professional connections, 2) contributing in meaningful ways to Open Source projects (in order to generate interest) or 3) impressing people with real-world solutions. I've never enjoyed a job that I had to seek out or interview for, your mileage may vary however.

Re: The Hiring Post

#45
post #37
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".

This is a good post, Thomas. From this I think I could make an efficient test for the kind of person who'd make a good performance engineer. Developing a more general work-sample for developers is a harder problem, but still feels doable. This may not be an issue for you yet, but what about plagiarism? And can you expand on your hints about how you changed your pipeline at the front of the process? You don't intervie…

Every serious application, regardless of their resume, got a 30-45 minute phone call. You post hiring posts all over the place and you get a lot of unserious submissions, but an easy way to screen them out is to respond with a question, like, "Thanks for writing! We'd be happy to talk to you. Can we ask what has you interested in doing software security?" The answer doesn't matter, as long as there is an answer.

I did a lot of calls where I knew a couple minutes in that we were unlikely to hire the person, but (a) I got surprised by outcomes enough not to shirk on those calls, and (b) those calls are a very small price to pay for finding buried talent.

Re: The Hiring Post

#46
post #14

Earlier quoted context omitted.

I just interviewed with Google and they use Google Docs.

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

Re: The Hiring Post

#47
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

#48
post #39

As a vote of confidence, this article moved me from "I would never ever interview at Matasano" to "I don't want a full-time job at a security firm, but if I did, I would probably start looking here."

Thanks! I hope that carries over to the new firm we started, too. :P

Woah! Don't be afraid to plug your new firm in the blogpost :-) I doubt I'm the only one to mistakenly ascribe your new hiring policy to your old company.

Re: The Hiring Post

#49
post #41
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".

It's funny, because to change it, you have to admit that the way you were doing it before is not effective. I've come across many people who admit that they are bad at being interviewed, but very few people I meet have admitted to being bad at interviewing others. It's incongruous with the results, because these are the same people that have hired folks that we all agree are not exhibiting the level and characteristi…

I was horrible at interviews. I was a sport interviewer. I had favorite tricky questions. "Design the fastest possible traceroute" was one for a long time. "Describe the most important feature of TCP NO WRONG, IT'S CONGESTION CONTROL NITWIT". I trust my own interviewing ability least of all, which is why I sink so much time into avoiding them.

Re: The Hiring Post

#50
post #39

Earlier quoted context omitted.

Thanks! I hope that carries over to the new firm we started, too. :P

Woah! Don't be afraid to plug your new firm in the blogpost :-) I doubt I'm the only one to mistakenly ascribe your new hiring policy to your old company.

No, you're not mistaken! That's how Matasano has hired for something like 2.5 years. I left the company to do hiring-related things, after feeling like I'd more or less disposed of the challenge completely at Matasano/NCC.

There's a pretty big plug coming next week, though not from me. What we're doing meshes well with the worldview in my post, but it isn't a productization of it. This is just what I really think about hiring.

Post reply on HN