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.