- PirateBox 1.0 — turns a wireless router into a filesharing joy. v1.0 has a responsive ui, among other things for use on tablets and phones.
- Dystopia Tracker — keep on top of which scifi dystopic predictions have been realised. I’d like filters for incubators, investors, and BigCos so you can see who is investing in dystopia.
- The Harvester, the Botmaster, and the Spammer (PDF) — research paper on the spam supply chain.
- Technical Interviewing (Moishe Lettvin) — lessons learned from conducting >250 technical interviews at Google. Why do I care? Chances are, your technical interviews suck so you’re hiring poorly.
ENTRIES TAGGED "hiring"
Filesharing Box, Realised Dystopias, Spam Ecosystem Research, and Technical Interviews
Alternatives and suggestions for candidates and companies to avoid tests
In part one we covered types of technical tests—their relative costs, and why organizations need to understand the costs to the candidates if they want to attract the right type of candidates, and at what point in the process to test.
We haven’t covered alternatives yet. Larger organizations have the benefit of HR or recruitment divisions to bear the brunt of the early cost of the recruitment process—they can call candidates individually to check out interpersonal skills and to make the candidates feel wanted. Smaller organizations don’t necessarily have this, but they do have the benefit of being more flexible. If the brunt of the recruitment process falls on developers (or tech leads, CTOs, or other people in the technical organization) then obviously these organizations are trying to keep the time costs down—every hour invested in recruitment is an hour not spent on coding the company’s money-making product. But these techies are also in a much better position to be able to judge a candidate, and don’t always need to rely on one channel (the technical test, for example) to perform this judgment. They have other alternatives.
Dissecting the hows, whys, and why nots of screening candidates
Because so many of us have experienced both sides of the interview table, the London Java Community has a slight obsession with discussing approaches to recruitment. The nice thing about these conversations is you see both points of view—the candidates and the techies who are responsible for hiring.
Our most recent conversation was (again) about the value of technical tests during the interview process. I’m not sure there’s another topic that generates such diverse and yet all “correct” points of view. If there’s one thing I’ve learnt from seeing this conversation again and again, it’s that there is no One True Way to test a candidate’s technical ability. If there was, we’d all be doing it.
Whiteboards and manhole covers won't find you a great programmer
Let’s imagine for a moment that you’re one of the world’s greatest chefs. You are a graduate of the CIA, have run a four-star restaurant, and had your own show on the Food Network. Now you’re interviewing to run the cafeteria at the hottest new startup in Silicon Valley (they’re offering major equity). After chatting for a bit with the CEO, she leads you outside the building. “I want to see how you work,” she says. “Cook me a meal.”
“Ok,” you respond, “where’s the kitchen?”
“Oh, no. I want you to find firewood in the park over there, build a fire ring, start a fire by rubbing some sticks together, then make a spear and hunt down a deer and cook it on the fire.”
I’ve recently had the pleasure of going through the job interview gauntlet with a few companies, and that’s essentially the process that most firms use to evaluate potential employees. They sit you down in a conference room, have someone pose you some kind of programmatic brain teaser, and then expect you to work it out on a white board.
This is so far removed from the realities of what a software engineer actually does today that you might as well be asking the candidate to sketch a portrait of the interviewer. I’m relatively fluent in at least dozen languages, but I don’t try to keep everything in my head at once. If I’m coding in Java, I’m using Eclipse. If I’m working on iOS apps, I’m in Xcode. I constantly hit command-space to autofill method signatures. I hover to get Javadoc. I search the web for code fragments.
Larry Wall says that one of the virtues of a programmer is laziness; do the least work that is needed to get the job done. When you’re hiring a developer, what you want to know is how efficient he is, and how good his code will be. If he can find the solution to a problem in five minutes of searching, it’s better than having to grind for hours trying to solve it without searching. Whiteboards don’t test that.
Adobe immobilized mobile Flash, Eclipse joins the vanity language fad, and one man asks if brainteasers really find good programmers.
Flash isn't dead, but Adobe is checking into hospice options. Eclipse adds another language to the list of ones almost but not exactly like Java. And how do you find good programmers? Probably not with brainteasers.