Nothing screams “easy money” like headhunting. Twenty-five to thirty percent of your recruit’s first annual salary? Twenty dollars off the top of each hour worked by your contractor? With that kind of bling, who wouldn’tsign up as a headhunter?

Of course, recruiting good people is no trivial task (that’s probably why it costs so damn much), but that certainly doesn’t stop a whole lot of wannabes from trying. Like the fine folks behind this email that Chris M recently received …

(ed: Saved as an image to preserve original formatting )

Chris was considering applying, but wasn’t sure he had a decent enough knowledge of Transit SQL. Perhaps this opportunity would have been a better fit for the candidate that called Nick O about an opening…

Nick: Good afternoon, this is Nick.
Candidate: : Hello, I saw that you posted an ad for a computer programmer, can you tell me any details about it?
Nick: Sure, we’re a small technology company that primarily develops Java applications. We have some C++ applications are are stating to get in to .NET.
Candidate: Oh neat! How should I go about applying?
Nick: Real easy: just send on over your resume. I’m curious, what languages are you familiar with?
Candidate: Oh, um, just English.

As it turned out, the Candidate’s experience didn’t go much beyond English. Needless to say, Nick didn’t end up scheduling an interview.

At Lee Burch’s company, they send candidates a simple set of technical questions to see how well they respond outside of a high-pressure interview setting. Following is the worst response he’s ever seen. What inspired me to share it with you was the candidate’s arrogance while failing so miserably…

The Preface:
I don’t know the answers to these specific programming questions off-hand… Thus, I'm going to answer all these questions by briefly highlighting my approach and thought process for each question, without actually going through the inconsequential exercise of providing the programmatic answer

Question One: Representing a Tree in a Relational Database
… in order to answer this question… I would do a quick Google search on the phrase “represent tree structure in relational database”. I would then read through and filter out the search results to determine which are relevant and trustworthy to the problem at hand. These would be two promising leads I’d look at:

Of course, besides hitting Google, I would consult with my developers/DBA, colleagues, and internal knowledge databases to see if there’s a more specific best-practice solution.

Question Two: Query That Joins Two Tables Develop a Query
Again, my background is not in database design or DBA, but I know basic SQL queries. This would be a trivial answer once I consult the SQL reference books. I believe I would use a combination of SELECT … FROM … WHERE COUNT … and SELECT … FROM … WHERE COUNT …. ORDER BY

Question Three: Creating a Hashkey for a HashSet
I haven’t used the specific HashSet Java class before… and now that I see its JavaDoc, I’m confused by this question. It doesn’t make a lot of sense. I’m not sure when or why you would ever have this problem as written – what situation would necessitate locating the original object via the contains() method without using the original object?

download full questions/response



Shameless recruiting plug: my company (Inedo, LLC) is hiring again! If you're a Cleveland-based .NET/Microsoft Developer, take a look.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!