28 July 2005

Dude, it's called Java Job Interview

I pity the owner or stakeholders of companies who hires god-like asshats in their Software Engineering section. Those uber-coder-turned-CTO or whatever who doesn't know how to pick their own in just 3 hours or less. These high-IQ individuals tend to overlook EQs, which effectively push them downwards to the intellectual echelon.

For technical jobs especially Java-related ones, any type of on-the-spot exam barely proves anything. Whether it's online or written and be subjected to batteries of technical interviews if the candidates happen to pass their so-high-standard tests. I observed that these kind of tests are simply more of intimidation contests rather than getting the right person for the job. These techniques are top time-wasters and outdated, it was formulated by men with fragile egos to protect. They will say these are standard company procedures, WELL, FUCK YOU! Some of it was written by morons who has nothing better to do, and definitely wasting company resources by missing the right people who are truly capable.

I can always get a good guy, not necessarily great ones but capable, in just a three-hour or less semi-technical-behavioural one-on-one interaction. Ok, I will not call it an interview because when I do conduct such things I make sure I don't make the candidate feel he/she is somewhere in Guantanamo. The secret to this selection process is PREPARATION. Every candidates has a unique sets of questions prepared for them based on what they claim to know in their CVs. So making standardized interview questions is a big NO-NO! Preparation will always pay off. My interview sequence always goes this way:


  • Introduction of myself and what am I to the organization I represent

  • Asking the candidate how to address him/her.

  • Then the "can opener" questions



What are the "can opener" questions? These are some of the example questions that I usually starts with, let's say the candidate has extensively wrote about Spring in his CV:


  • "So what do you do in your current job?"


  • At this point, the candidate will express vaguely about what he/she does. And take note, almost everyone in this position will almost, always be honest.

  • "So you've mentioned in your CV that you have used Spring, What's good about it?"


  • Please listen carefully on this part and stop being a zealot for a while, if you tend not to like what the candidate will going to say. This is where your own EQ will be tested. Do not confront the candidate. Give brownie points on keywords like IoC, DI, etc. etc.

  • "What's your most difficult problem in using Spring?"


  • Case-to-case basis, you will know that the candidate is better than you when you hear something new and makes sense.

  • "When do you prefer not to use IoC?"


  • Again, listen and you will get some points for yourself here as well. But stupidity will show it's obvious head. You will find out how easy it is.

  • "Tell me about your experience in working on a team"


  • Never ask "Have you worked on a team?". Because that is answerable by yes/no and you will find yourself in a deadlock, you'll have a hard time getting the information you need to evaluate the candidate.

  • "Tell me about your most difficult teammate"


  • Scrutinize the candidate's behaviour. The way he solves problems, he may have solved it in a technical or smart(insidious) way.

  • "Tell me about your most challenging design problems"


  • Here, buzzwords like Singleton, encapsulation etc. will fly out anywhere and if the candidate really knows what he/she's talking about, smile. This part you will hear with enthusiastic elaboration how the candidate tackled the problems using a pattern and how they mixed patterns to come up with a solution or sets of solutions.
    How one tool sucks from the other, that x database is better than y database for a particular task. OR you'll see an empty stare and a hum here and a hum there.




At this part, while you're still browsing halfway of the candidate's CV. You know if he/she's a go or no go. And can immediately write your recommendations. Potentially save your company some money etc. etc.

I have mastered this skill during my days on the Dark Side. You can formulate your own questions too. But the real key is preparation.

14 comments:

Anonymous said...

Intimidation contest is a really apt description. I was recently at an interview where I was given a technical test, then the 'board of interviewers' came in, put the test to one side (without looking at it), and proceeded to ask me most of the same questions (and more difficult ones) verbally. In a truly bizarre and confrontational manner. Actually it was a bit like good cop - bad cop.

Having given about 30 interviews myself over the past few years, I can identify the 2 questions they asked which actually told them what they really needed to know (since I didn't get that job, I now know exactly the sort of person they were looking for) -- so basically it was 2 1/2 hours of time wasted for me. Those questions could have been asked first -- along with some basic personality indicators to show whether or not I would mesh with the team -- eliminating the hours of technical testing until they were sure I was the right sort of mentality for the job.

JRB

Paul Mclachlan said...

I put a laptop in front of the candidate and ask them to code up "Hello World".

You can tell a lot by how quickly they get stumped by PATH, CLASSPATH, where the JDK is on the machine & simple compile errors.

I find it a bit amazing that some people interviewing for a software engineering job refuse to even attempt this test. How can I rely on such a person to be able to debug on a QA machine that doesn't have (insert fav. IDE here)?

Tom Klaasen said...

Paul: that's exactly what you would be testing - can he debug on a QA machine? A skill that can be mastered in half a day, but that doesn't tell you anything about the software engineering skills of the candidate.

Diong said...

Very interesting discussions... I always thought given a technical test on an interview on the spot I will always fail... in my opinion the best qualification would be the kind of discussion on experience in "real" software development... whether the software you previously created made the lives of the user any better or saved the clients tons of money. it should not be technical at all... what about those "creative" types who could definitely get the job done.

Anonymous said...

For me, asking hard techincal questions at a job interview is less about testing skills but more about testing

1) Does the candidate give up or refuse to try something
2) Does the candidate work well under pressure
3) Does the candidate demonstrate clear thinking
4) How does the candidate react when mistakes are pointed out

I tend to ask stuff that is far to hard for anybody to get in an hour long interview. It is more about their methods and reactions. And my ability to feel comfortable with that person.

Anonymous said...

You, sir, are a terrible interviewer.

Anonymous said...

I too agree with above anonymous. you SIR, seem to be a sucker. Look for aliens blood not human's

Anonymous said...

Once in an interview, I was given two separate tests (one C++, the other java), and was told to pick 5 questions from each to answer. I told them that I really hadn't worked with C++, but they said "That's OK, just go ahead and answer the questions anyway." Luckily, there were a few questions on there that I could answer correctly (having studied C++ some in the past).

Anyway, what got me was the questions on the java test. It was like some guy who thought he was God's gift to java wrote them. It was like he said "What kind of questions over obscure java topics can I ask that will stump them?" I was thinking the whole time, what kind of info are they going to learn about me with these idiotic questions? And what's worse, right after I had started the tests, the four interviewers came in and sat down in front of me to watch me take these stupid tests.

Later when I was done, one of the interviewers said with a smirk on his face, "The last guy who we interviewed claimed to be a great java developer, but he didn't get ANY of the questions correct." And I was thinking, yeah, I can see why. These questions are stupid. If he would have memorized some of the rarely used parts of the JDK, he might have gotten a few of them correct.

Anonymous said...

I once took a test--I'm an old coder!--and it was when I was in University for a Co-Op education program job (drop out for a semester and a summer and work as a software engineer for 8 months, before going back and finishing one's degree).

Anyway, the test was this densely packed, cryptic Fortran code (I told you I'm an old fogie!)--it was pretty nigh incomprehensible-- and the interviewer, an engineer himself, looked kind of apologetic as he handed it to me. So I stared at it a bit and all of sudden it occurred to me what the code was doing, mostly because I'd recently done a similar algorithm on a project at school.

So I say, well it's (I can't really remember it now, I think it was some kind of day,month,year or bubble sort or some algorithm like that, cleverly diguised) what I thought. The interviewer says, Yeah, tell me more, so then I notice some additional aspect, because I'd 'gotten' it, and basically told him what the code was.

Okay, so that's a long story, but the reason I'm posting here is because they then proceeded (in a subsequent interview with the manager of the group) to tell me that I was ONLY candidate that had EVER figured out the code. What kind of job did I want?

The manager was a real jerk, from back in the old days when the boss was boss and everything he said went. I was happy they offered me the job, but I turned them down because the manager was such a jerk.

They then badgered the Co-Op program director at my Univ. to ask me why I wasn't going to work for them (they were a big engineering firm, like Bechtel type--but not Bechtel--who was doing some really cool real-time process software to monitor power plants, etc.)... Then, they kept calling me. In fact, that manager tried to get me to take a job with them at least 3-4 more times over the rest of my univ. career!

What a bunch of idiots! Just because I 'happened' to solve their stupid cryptic puzzle, they thought I was gonna win a Nobel prize or something.

Anyway, just wanted to relay an example of 'passing' the test and how stupid that can be, too! It really tells you very little.

Cheers,
Brad

Anonymous said...

Great story Brad! There's still billions of lines of fortran and cobol around...

gesticulatively resources said...

I was looking for a place to submit my economics article and stumbled across your blog. I enjoy reading blogs with my coffe in the morning before work. its fun to see whats up with people around the world.

Anyway, I did find a free blog and article submission site here Site Submit/Article Submission

Anyway, I enjoyed your blog. Have a nice day : )

AngryModerate said...

I have hired about 30 engineers and product marketing professionals over my career (and interviewed in the hundreds), and I have had great success whenever I used a techincal (coding) test - so much so that people I knew from a subsidiary company began asking me to interview their candidates in addition to my own. As Anonymous said, it's not really about whether or not the candidate gets the right answer (though it helps, I admit). It's really all about *how* the candidate goes about solving the problem.

Most candidates dislike doing a test during an interview - I don't blame them. But it is extremely useful to see how they react to a situation they dislike, because if you hire them, you will sometimes have to ask them to do things they don't want to do. Do they react with grace or with hostility? Are they confident enough in their own skills to ask questions where needed? If they don't get the right answer, can they communicate what their blocking issues are? How much help do they need to get to the correct result?

I had some strict guidelines, and ran the test the same way every time. I always tried to reassure the candidate about the test. I left them alone to do the test, so they didn't have added pressure of me watching them. I always came in once to offer assistance, and stayed if they wanted it (if they were struggling, asking for help was *always* regarded positively).

To me, there is no question that this is a very successful way of interviewing provided it is done properly. I don't doubt that the people who did poorly would disagree, but those I hired were generally positive about the experience, and many later used the test (with training from me) when they were in the position of having to hire people themselves.

The bottom line in interviewing is not to learn what specific technical skills a person has - those can be taught - but to learn what their habits, tendencies, and talents are. A test is probably the best way to simulate a real-life work situation and to bring out a person's natural tendencies as you can get.

AngryModerate said...

I have hired about 30 engineers and product marketing professionals over my career (and interviewed in the hundreds), and I have had great success whenever I used a techincal (coding) test - so much so that people I knew from a subsidiary company began asking me to interview their candidates in addition to my own. As Anonymous said, it's not really about whether or not the candidate gets the right answer (though it helps, I admit). It's really all about *how* the candidate goes about solving the problem.

Most candidates dislike doing a test during an interview - I don't blame them. But it is extremely useful to see how they react to a situation they dislike, because if you hire them, you will sometimes have to ask them to do things they don't want to do. Do they react with grace or with hostility? Are they confident enough in their own skills to ask questions where needed? If they don't get the right answer, can they communicate what their blocking issues are? How much help do they need to get to the correct result?

I had some strict guidelines, and ran the test the same way every time. I always tried to reassure the candidate about the test. I left them alone to do the test, so they didn't have added pressure of me watching them. I always came in once to offer assistance, and stayed if they wanted it (if they were struggling, asking for help was *always* regarded positively).

To me, there is no question that this is a very successful way of interviewing provided it is done properly. I don't doubt that the people who did poorly would disagree, but those I hired were generally positive about the experience, and many later used the test (with training from me) when they were in the position of having to hire people themselves.

The bottom line in interviewing is not to learn what specific technical skills a person has - those can be taught - but to learn what their habits, tendencies, and talents are. A test is probably the best way to simulate a real-life work situation and to bring out a person's natural tendencies as you can get.

Jared said...

AngryModerator,

This is one of the most insightful comments posted for this blog. It did occur to my mind "what if I am compelled to do something that I am not supposed to do or don't want to do? Will I react gracefully or with hostility?". Thanks for the post.