Goofy stuff happens when your company announces a funding round. We've gotten walk-in solicitors who try to sell us networking equipment, pitches for I-can't-quite-see-the-scam-but-I'm-sure-it's-there-somewhere stock exchange programs, and phone calls from slick Oracle salesmen who have their get-past-the-secretary sneak perfected so well that they could probably make better livings as industrial spies.
But most frequently, there are resumès that land in my inbox. Yes Milo is hiring, and a lot of people contact me directly instead of the "jobs" address, which I can sympathize with because I've always had this feeling that "jobs@" e-mail addresses are black holes where career dreams get sent to die.
Our general workflow for hiring engineers is to send the person our "engineering challenge" programming question and see how they do on it. If that looks good, they come in for interviews. I don't like doing interviews because I've always got enough stuff to do, but sometimes it's a good break. Necessary evil, I guess. Like Katy Perry. Have you heard a live performance? Ph33r.
Anyhow, when I interview a candidate, I'm trying to determine how valuable the candidate is, not just how smart he or she is. Because I love English semantics:
A smart candidate will do well on the engineering challenge problem.
A productive candidate will be able to explain past projects in detail.
A valuable candidate is smart and productive, but also has useful knowledge gained from experience.
To tell if a candidate is valuable, you need to piss them off. (By the way, does it make you feel icky that they can be used with a singular antecedent? This derelict language is put together with duct tape and baling wire, I swear.) A valuable candidate will likely have been personally offended by some sequence of bullshit thrown from a programming language, tool, library, or problem in past work. This is the kind of bullshit-train I'm talking about.
Need to parse XML with Python → SGMLlib feels like a kids toy → Implement it with BeautifulSoup → Fuck me, Soup is too slow → Re-implement with LXML → LXML works great for months → LXML segfaults the Python interpreter when used in a threaded environment under heavy load →
Any developer who has been around enough to accumulate valuable experience will have his personal collection of stories that have mad him rage. I have been burned by bugs in programming language implementations, bugs I call "coding slurs". I have gotten the shaft more times than I can count from pathological character set issues that make me want to run for Congress on the platform of requiring licenses before people are allowed to use computers. If you really want to find the value in a job candidate - find out what pisses him off.But most frequently, there are resumès that land in my inbox. Yes Milo is hiring, and a lot of people contact me directly instead of the "jobs" address, which I can sympathize with because I've always had this feeling that "jobs@" e-mail addresses are black holes where career dreams get sent to die.
Our general workflow for hiring engineers is to send the person our "engineering challenge" programming question and see how they do on it. If that looks good, they come in for interviews. I don't like doing interviews because I've always got enough stuff to do, but sometimes it's a good break. Necessary evil, I guess. Like Katy Perry. Have you heard a live performance? Ph33r.
Anyhow, when I interview a candidate, I'm trying to determine how valuable the candidate is, not just how smart he or she is. Because I love English semantics:
A smart candidate will do well on the engineering challenge problem.
A productive candidate will be able to explain past projects in detail.
A valuable candidate is smart and productive, but also has useful knowledge gained from experience.
To tell if a candidate is valuable, you need to piss them off. (By the way, does it make you feel icky that they can be used with a singular antecedent? This derelict language is put together with duct tape and baling wire, I swear.) A valuable candidate will likely have been personally offended by some sequence of bullshit thrown from a programming language, tool, library, or problem in past work. This is the kind of bullshit-train I'm talking about.
Need to parse XML with Python → SGMLlib feels like a kids toy → Implement it with BeautifulSoup → Fuck me, Soup is too slow → Re-implement with LXML → LXML works great for months → LXML segfaults the Python interpreter when used in a threaded environment under heavy load →
The easiest way I have found of doing this is to ask a candidate "what don't you like about your favorite programming language?" You can grade their experience with the response. For example:
What don't you like about Java?
Out-of-college answer: "Java is too verbose"
Battle-hardened developer answer: "Object storage is aligned on a 64-bit boundary, at least in Sun's JVM, so if you need to allocate a lot of small storage, you really need to know JVM internals so you don't run out of memory."
What don't you like about Python?
Answer from a candidate who will write frameworks for solving problems instead of getting shit done: "Dynamic typing means you need to rely more on your tests and less on the interpreter to make sure your code is correct"
Answer from Gunnery Sergeant Hartman, your senior drill instructor: "Independent object cycles where one of the objects has a __del__ method don't get garbage collected."
People think I hate programming. Nope. What I hate is fording endless rivers of horseshit that are in the way of seemingly simple tasks. And I hate it even more when I have to explain to a non-programmer what I am doing, "building LXML against a different version of libiconv because I think it might be the source of a crash".
"But all I asked you to do was parse some documents."
Good times.