Three for Three (from Randall C)
My boss, Harry, needed to hire some experienced software engineers, so he placed a job ad and did some kind of sort on the fifty or so replies that came in. Later, many of us assumed that he must have done a stair sort (throw them from the top of a stair and pick the ones that traveled farthest). He then said to me "I need to hire two engineers and I've selected three candidates. Would you like to interview them?" Not actually stated in this, but his attitude clearly indicated that he planned to hire two engineers from that pool of three.

I was willing to participate in the selection process so he set up a schedule for three interviews, Tim on Thursday, Charles on Friday, and Terry on Monday. This would be a lightweight responsibility for me and I would talk to the candidates over a free lunch. Well, okay. I was known to terrorize candidates by asking difficult questions and I could usually form an opinion based on a short discussion.

So, lunch with Tim: he acquitted himself fairly well. Not stellar, and he only had about 8 months of experience and was hoping to get out of the unpleasant work environment he was in. That afternoon after the candidate had left, Harry came into my office and asked my thoughts. I said he seemed competent and we should see what the other candidates looked like. Harry said that he didn't have enough experience and he had already sent him a rejection letter. OOOOkay, you couldn't read that in the resume, and then you wasted my time only to do the opposite of what I suggested. One for one.

Lunch with Charles was a disquieting experience. No matter what question I asked (and some were pretty simple, like "what time is it?") I got a response of the form "that reminds me of the time....". I decided this guy might be able to make a living selling used cars. So Harry came by in the afternoon and asked my opinion. Keeping this on a high plane, I told him that Charles was evasive and that he did not have the requisite communication skills to be an engineer in our organization. He had deliberately made it impossible to judge his knowledge and skills and we don't hire people like that. Harry told me he "had a good talk with him, and he'll be fine," and he's being extended an offer. OOOOkay, two for two.

Lunch with Terry was bizarre. Every question I asked, right down to "what's your name?" was met with "I dunno." At least he was honest. Near the end of the lunch, I had an inspiration. I figured he must have changed careers recently and was just way short on experience. Nope, he'd been a programmer since he got out of school for a solid twelve years. During the short car ride back he related an anecdote about a difficult challenge his group had recently dealt with. As he was explaining the situation I could see the answer but thought, "no, couldn't be that simple". After all, they had worked on it for three solid months. Then he gets to the punchline: it was exactly that simple. The amazing thing to me was that his entire group together must have had the brains of a lab rat.

Harry came by as usual that afternoon. "Well, what did you think?"

"Harry, this guy couldn't program his way out of a paper bag."

"Aaah, he couldn't be that bad. Don't you think he could work on the scheduler?"

"No, Harry, he couldn't work on the scheduler."

"What about the language processor?"

"No, Harry, he couldn't work on the language processor."

"Well, do you think he could write test programs?"

And here, I made a serious mistake. I should have immediately said "No" of course, but instead I said "Well..." and before I could say anything more Harry said "Great, I'll hire him." OOOOkay, three for three.

So, how did they work out you ask. Well, Charles was the best programmer in the world. All you had to do was ask him. He was so good that he didn't need to test his patches. Our customer service organization added two positions to repair the damage. Features that were scheduled to be delivered in the fall release made it in winter release... three years later. And the only reason that release went out was they had fired the QA group for repeatedly rejecting Charles' and Terry's high quality work. Talk about firing the messenger!

 

Recursion Threads (from Ben)
As part of the interview process, my company requires applicants to complete a short written test with a few questions. The difficulty varied depending on the position, but the questions were straightforward and only required a simple explanation in plain English. At least, that's what I used to think.

Here's a question from our Senior Java Developer test.

Question 1
(a) What does the following function do?  
(b) How could the function be improved?
(c) Rewrite the function with your suggested improvements.

String funcX (String s) {
  if (s == null || s.length() == 1 || s.length() == 0) {
    return s;
  } else {
    return funcX(s.substring(1)) + s.substring(0, 1);
  }
}

And an answer:

This function (funcX) will create a new recursive thread every 
time it is called. Each thread will be responsible for a 
string manipulation involving substrings. As for improvement,
the name is not very descriptive and should be modified. Also,
comments would be best practices.

This was, sadly, one of the better answers.

 

Wrong Answer (from Jose)
 

It was my second interview and it opened pretty conversationally.

"We're thinking of storing table names and columns in the database," the interview said, "it's an idea floating around."

I replied, "Instead of creating tables and storing the data depending on how it's structured?"

"Yeah!" his eyes lit up, "then we don't have to define structures or any other mess!"

I wondered it it was some sort of test. "How would you do reports? Would it not be awkward?"

"We could do that from the front end."

"Maybe," I said, "but wouldn't it require a lot of code? And it'd be incredibly slow."

"Not if we used hashtables!"

"Okay... what about data integrity, foreign keys, that sort of thing?"

He was getting more defensive, "it'd be all from the front end."

"I suppose, but this would all require an exorbitant amount of code with all sorts of complex SQL queries. It's not that bad to change a database if you—"

"No," he interrupted, "we would use a data access layer to abstract it to normalized data structures."

"You mean... like tables?"

Two days later, my recruiter told me that they declined me as a candidate because I wasn't technical enough. Though I do wonder if they ever implemented their meta-database implementation, I'm glad I'll never know.

 

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