Slashdot Mirror
How To Hire a Hacker
itwbennett writes "If you want to hire a hacker, you need to take a more psychology-based approach to the entire interview process to determine whether he or she has changed their ways enough to be a trustworthy employee, says Mich Kabay in a recent Network World blog post. But this approach is also 'germane for highly skilled staffers, even those that don't come with arrest records or who have done something questionable in their pasts,' says David Strom. For example, in your next interview, ask a question that will suss out how much of a sense of entitlement a candidate has — or how much you or your company has. 'One time when I interviewed with Microsoft in Redmond I couldn't get over this sense of corporate entitlement — it was one of the biggest turn-offs that I had during my interviewing day there,' says Strom. 'I got the feeling that I wasn't going to fit in, no matter how smart I thought (or they thought) I was.'"
Like a lot of big geeks on Slashdot, I take pride in always receiving a job offer after an interview... accept once. Once I interviewed with the EDIF reader group at Cadence, and the manager had exactly one technical question for me: "Do you understand recursion?" "Well... yes I do." "Well, then, you have all the skills that matter. What really counts is that you know how to fit in, and you don't impress me there."
I'm still shaken up over that interview.
Celebrate failure, and then learn from it - Nolan Bushnell
How to Fire a Hacker
(Without getting pwned by her/him or his/her friends)
Because (let's face it), there's a chance you hired one on accident, without realizing it, and that they don't have an arrest record, for one reason or another.
The easy way to hire tech people and keep them happy is have them work on, wait for it... technology. That is, most of them, unless they signed up for help desk basically want to be given a problem, some hardware, some software and then them to fix the problem. Thats it, no "team building", no pointless meetings, in general most tech people are happy simply working. The less social interaction with most people is the best.
Taxation is legalized theft, no more, no less.
I wonder how Terry Childs would have done if the guy who hired him had read this?
Because that is an interesting real world scenario to consider in this context. In fact, it would make for a good litmus test: would your hiring process stop the SF admin problem from occurring?
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
Surely a site dedicated to news for nerds can get the distinction between hacker and cracker right?
Nothing more to say.
The proper thing to do is ask them to do an "interesting" project for very little pay but an excellent and helpful resume chit. I have done that in the rocketry field to good benefit. The jobs they go to are high paying, and the work in the mean time involves a certain amount of fire and smoke. :) Probably an above average tolerance for aberrant behavior too.
Rocketman
That's nice, unless you work in a place that's even mildly diverse, where you have people like Kevin the married Mormon who is into skydiving, Samir the introvert muslim who regularly takes prayer breaks and loves Sunny-D, and Tammi the feminist who enjoys electronic music and builds analog synths in her spare time.
No, I think your amazing team-building system would work best with extroverted dopey white guys aged 20 - 30 and see nothing wrong with TV. Mooks, basically. It assumes a non-diverse team, so by definition it's a weak way to build teams in general.
Posting anonymously, since I have coworkers who read /. too.
The direct corollary to that is that if you start with a mediocre team, one of your first tasks is to help them up the curve a bit. We don't always get to pick the team we work with, but we can have a direct influence on what they become.
One of the problems I struggle with at work is that some teams don't really get this. A few bright, self-directed guys float to the top, but the rest get stuck where they are and they really don't know why they're stuck there. They're so busy trying to get what they're assigned to do done that they don't get a chance to learn better ways of doing things, and no one takes the time (or seems to have the time) to mentor them to raise their abilities. It reminds me of the old saying "Don't work for a sawmill that's so far behind it doesn't have time to sharpen its saw."
One of the practices that I've seen helps is to have semi-frequent code reviews, where everyone gets a chance to see and understand everyone else's code. To be effective, it also needs to be treated as an opportunity to share best practices so that everyone has a chance to learn from everyone else's strengths and observations. It's a chance to employ a positive network effect.
One of the teams I work with never does this, and never seems to get a chance to do it. The result is that everyone gets siloed on their individual piece, doing it as best as they can figure out how to do what they need to do, and never gets a chance to learn from others' strengths. It's very frustrating, since everyone is now operating below his/her potential, and the whole team moves slower (and produces lower quality output) as a result. A few bright stars might rise, but then a large competence gap develops. In fact, the team becomes reliant on these bright stars to be "heroes," since in the end they're the only ones that can pull off "the tricky bits," when really it shouldn't be that way.