I do this mostly as I don't get enough time to interview someone - 1 hour is not nearly enough time to get to know a person's technical and soft skills. Also my focus tends to be on the technical questions since these questions allow for a good "Apples-to-Apples" comparison which leaves less room for mistakes.
Over these years I've created a 16-page spreadsheet of questions including basic Java, JDBC, JMS, EJB, Struts, SQL, HTML/Javascript, XML, Open Source etc.
So here are my favorite questions to ask - I have plenty more, but these ones I've found really useful - often for surprising and unexpected reasons. Sometimes the answers aren't as important as the attitude taken in responding.
The "obvious" side - Technical Q&A
Q 1: When does the JVM do Garbage Collection?
This is kind of a trick question as the answer is really "it depends".
REALLY WHAT I'M ASKING: Do you really understand the language you use almost every hour of every day? Do you know what's important and what's not?
NOTE: The non-verbal response to this is almost as important - it catches people by surprise quite a bit - but for two different reasons. One response style is for those who don't know the answer. The other is for people who know the answer but are wondering why I'm asking.
Q 2: What's the difference between an interface and an abstract class?
REALLY WHAT I'M ASKING: How good are your oral explanatory skills? This is a somewhat complex topic under interview pressure.
NOTE: Amazing how many times this trips up so-called Java experts.
Q3: Name the different types of JDBC drivers?
REALLY WHAT I'M ASKING: Do you understand the tools you use everyday especially when it comes to performance
NOTE: Those who've really been involved in, or care about, performance tuning really understand their JDBC driver inside-and-out and will know a Type 1 from a Type 4.
Q4: How do I find out how many rows there are in a ResultSet?
REALLY WHAT I'M ASKING: Everyone's done this or should have, but what's the best way?
Frankly sometimes there are no short-cuts.
NOTE: Often really good Java developers are hoping I'll have a short-cut / high-performance answer to this. Unfortunately there is none (that I know of). However the "interest" they display is a good sign because it means they care about doing things better / faster.
Q5: Does Java use pass-by-value or pass-by-reference semantics?
REALLY WHAT I'M ASKING: Again, do you really understand the language you use almost every hour of every day?
NOTE: Amazing how many people get this wrong - even people who claim to have passed SCJP or even those working at Sun for years!
Q6: What does "NULL" mean in SQL?
REALLY WHAT I'M ASKING: How is data (or the lack thereof) represented? Do you really understand relational databases?
NOTE: It's amazing how many people very familiar with databases and/or are Comp Sci graduates who don't really know this.
The not-so-obvious side
What happens when you don't know the answer? Do you bluff or just admit it? Are you interested to learn and grow? Do you get angry and say "Why would anyone want to know what?". I've seen all kinds of interesting responses here.
I'm also looking for elements of developer-to-developer 'rapport' - interviewer and interviewee probably faced the same issues at different times in different jobs and that shared experience can help build some initial camaraderie.
Also important are the questions the interviewee asks
- What's your Source-code Control system & your IDE / Tool-set
- What are the Team dynamics (individual silos vs. more "group-oriented" work)
- What's the Release schedule look like?
- Hours worked each week?
- Company's financial state and outlook?
All these are good signs.
What I don't ask
It may surprise some folks but unlike some technical interviewers I don't ask the quasi-legendary puzzle questions. One of the reasons for that is that I find I don't do that well on those questions myself without lots of practice. But more importantly I don't find the exercise indicates much about a developer's skills per se. They're all too reminiscent of the SATs and GRE exams which don't really indicate other key aspects of a person's personality e.g. persistence, motivation, inquisitive nature etc.
Probably the biggest point of all . . . .
Most of what a developer does everyday is not abstract problem solving (I can hear a collective "WHAT!?!?!?") - but think about it - you really spend a lot of time figuring out how to implement the solution to an abstract problem? There are always people around who can help you find the (abstract) solution but few people who will implement it for you!
For example - let's take a requirements for a high-performance message-based system - which listens to stock price changes and updates a database. I might already know the solution will need multiple threads, a thread pool, a JMS provider etc. but . . .
Should I write my own pool or is there a good package I can re-use (JDK 5.0 has some awesome utilities for this)? Also . . .
- Should the pool grow to meet demand (probably)? By how much?
- What if the pool can't grow enough to meet demand?
- Do I need a "reaper" thread?
- What's the best way to stop a thread when it's been idle too long? What is "too long"?
- How do I ensure as little locking of common resources as possible but allow for shared caches?
- How should a thread handle an exception? Checked or Unchecked?
- Should each thread have it's own dedicated queue?
- Should they be listening to a global topic instead?
- How do I prevent deadlocking on the database?
- Does my JDBC driver support connection and statement pooling?
- How do I unit test each Thread?
- How do I test for possible race conditions?
- At what point are there simply too many threads and it hurts performance.
- What if JMS crashes? Should messages be persistent? How do you ensure each message is processed only once?
That's a lot of questions and the answers to these questions are rarely abstract - that is they are not algorithms independent of the implementation. The solutions depend very much on whether you are using C, C++, Java or C# and hitting Oracle, Sybase or MS Sql Server, using MQSeries, Tibco or Sonic MQ? These are nitty-gritty implementation issues which depend more on your experience and willingness to investigate than on abstract problem solving. Even the JDBC and JMS APIs don't obviate the need for understanding the underlying database / messaging platforms.
Above-all, I think the most under-rated (and under-interviewed) attribute of a developer is persistence rather than problem-solving. Will you stay plugging away at a problem, trying different angles, working with different people until you can solve it? Will you write a good set of unit tests before declaring victory? Will you trawl through Google to find an answer when your JDBC driver doesn't behave as expected?
So for me, often the Java/J2EE questions I ask (e.g. nitty gritty details of JDBC drivers) are really about finding out how deep / far you have gone to solve common issues (e.g. error handling, resource cleanup, performance tweaking etc.).
Final Note
I've been quite disappointed lately about how some people shamelessly pad their resume. Now I'm not talking about cases where a person says s/he has used JDBC and doesn't know it inside-and-out. I'm talking about people who, for example,
i) Claim they are "expert" in MQSeries but don't know the difference between a Channel and a Queue!
ii) People who claim 5 years of JDBC but then can't tell me the different types of Statement objects!
I'm talking blatant exaggeration.
Finally then there are the needles in the haystack. The people who just have the "gift" - they're gonna kick ass and probably teach you as much as you can teach them.
When you find that person, all that effort is worth it.
BTW I'm sure interviewees have similar bad stories about bad, disrespectful or dishonest interviewers - I know I have - and I would love to hear them or other good / favorite interview questions!
Compare and Contrast
Just recently I read Joel Spolsky's updated Guerrilla Guide to Interviewing (version 3.0)
and although I respect Joel quite a bit I was quite surprised that there were a few specific details I disagree with him on.
For example he says "If even two of the six interviewers thinks that a person is not worth hiring, don't hire them . . . I would probably allow any senior person to reject a candidate but would not reject someone just because one junior person didn't like them."
Frankly I disagree here - if you hire this person and one of your developers gave the person a "No Hire" you may have gained one employee but "lost" another. I've had managers hire developers over my "No Hire" recommendation and I found it very frustrating - especially so when the person turned into an unmitigated disaster.
Perhaps Joel would think of me as a "Quiz Show Interviewer" - the things I'm after might seem like trivia but I feel they are very important - understanding how to release resources, how JDBC works, how to use threads etc.
In particular I 100% disagree with the idea that "software teams want to hire people with aptitude, not a particular skill set.". Huh? Frankly I have a particular job that requires a certain skill set and really don't have much time to teach a person that skill set. True, they definitely need an aptitude to learn - but people with strong skill sets have strong skill sets for the most part BECAUSE they have the aptitude to learn. I'm not jumping from Java to C# or Ruby any time soon so I need people with good/great Java skills!
It takes years to learn good exception handling, resource releasing etc. in Java and I don't have time for someone to learn that (as a Senior Developer) on my or the company's dime.
I agree with him, though, that you should look for people who show passion, can explain things well and exhibit leadership potential.
In the end we're both after the same thing we just have different ideas (personal conceits) about how to get there. I'm still learning how best to interview and after writing this and reading Joel's article I definitely have some things to think about.
44 comments:
A very interesting point about implementors versus problem solvers and I agree, most people are probably thinking "WHAT?!" when they read that. But I think you've hit on an important point, especially when you're looking at hiring a "senior" person. I suppose it depends on the size of your team, but I'd expect that most software teams do not want/need the "pure abstract problem solver". Those people tend to come up with abstract solutions that involve lots of UML and then expect to hand their "solution" off to a programmer to implement. Those solutions seldom live, unchanged, throughout the implementation and testing process. Plans always change and you need the kind of person that adapts, rolls with the punches, and sticks with the problem until an appropriate, working solution is implemented.
In addition to making sure the design and problem-solving skills are present, I think I'll start paying more attention to the candidates ability to see that design through to deployment when I'm interviewing.
I recently found a very interesting website:
http://alreadylinked.com/
There you can purchase ad space for your Blog etc.
I recently found a very interesting website:
http://alreadylinked.com/
There you can purchase ad space for your Blog etc.
nice questions! where/what are the answers tho - don't leave me hanging! ;)
Question on the number of rows in a result set question... Couldn't you just add a COUNT column in the select clause?
I like the idea of adding a count to the SQL. But don't you think this is something the ResultSet API should provide by itself? I'll have to check into the new Rowsets of JDBC 3.0 to see if they provide some easier support.
-Frank
What, no answers?
I think questions like these are egotisical on the part of the interviewer (with the exception of abstract vs intetface one). I do the tech screening for our company and I never ask questions like these. I ask questions that are relevant to them being productive developers. Knowing when garbage collection has ZERO relevance on someone being good at producng business applications. If I has hiring someone to write a JVM they beter damn well know different strategies for garbage collection, but unless that is the case, its just a chance for the developer to massage his ego.
But when it comes down to it, you are only hurting yourself. You are probablly missing out on alot of good potential candidates. No one wants to work for someone who is motivated to make them look stupid.
I ask questions like:
WHat is an inner join?
What is the most recent version of the JRE?
What is the difference between a home and remote interface?
Name a circumstance when you have used recursion.
What are the advantages of ORM?
In response to Jase - "What no answers?". The answers are all out there on the internet :-)
To anonymous who said
"Knowing when garbage collection has ZERO relevance on someone being good at producng business applications"
Well *EXACTLY* - that's the point - Garbage collection is an important concept for Java but not necessarily for development. The question is really - do you know what's important and also what's not. In this case *WHEN* Garbage Collection does not matter much. But often I find people trying to bluff their way through this - not a good sign.
And also "No one wants to work for someone who is motivated to make them look stupid". I certainly never want to do make anyone look stupid so during my interviews I don't tell people if the answer is right or wrong unless they ask.
That said, those who are motivated (to learn and be the best) are often very confident, know their answers are right and don't even ask to be told if they are right.
They want to work for people who are like them too!
As for missing out on candidates, I've been quite fortunate to be able to fill every position with very talented and motivated people who write great code!
But my question to you is "Do you really want to hire someone who doesn't know how to count the number of rows in a ResultSet or that 'null' is not an actual Value in SQL or that JDBC drivers matter to performance?"
That's your choice but I certainly would find it disconcerting.
Please also remember I'm mostly hiring "Senior" Java developers - those with 5+ years experience - if they don't know those answers after 5+ years - ouch!
It sounds to me like what you really want to know is how much the developer knows about java/database interactions.
And if the job description says "must have deep knowledge of the intricacies of java database development", then yes, I think those are great questions.
In my company, however, Sr. Java Developer means "someone who can solve arbitrary problems in Java". Using your questions would not get me a good Senior Developer. It would not necessarily, for example, get me someone who could easily pick up Struts, or know when to use EJB, and when not to, or how to write a really solid automated test suite. And for the stuff that we do, the ability to autonomously solve problems that have nothing to do with the database is very important.
To JB,
Indeed it makes sense to tune the interview towards those skills needed for the job. However, that said, I personally would find it disconcerting to have a job where I didn't do any data access - simply since there are so many jobs out there that require it.
Not knowing JDBC & SQL is a risky move career-wise IMHO.
Again these are only a few of the questions I use - I have plenty others on Struts and EJB - but the questions I listed I find are particularly revealing.
BTW, I'm interested in learning more about your company that has you solving "arbitrary" problems. Sounds like fun! :-)
Best,
-Frank
>>>But often I find people trying to bluff their way through this - not a good sign.
An interview is a nerve racking experience. If someone is a genuinely good developer and then they are asked an esoteric question I think its reasonable they would be flustered.
>>>And also "No one wants to work for someone who is motivated to make them look stupid". I certainly never want to do make anyone look stupid so during my interviews...
Then don't ask them ego-gratifying questions that are designed to stump most developers.
Ask question that are relevant to the actual tasks they will be performing.
In response to Anonymous who said "don't ask them ego-gratifying questions that are designed to stump most developers"
Firstly the questions are not designed to stump anyone, they are designed to help me understand how much the interviewee knows or doesn't know.
But secondly and most importantly: I don't want to hire "most" developers, or the average or just-above-average, I want to hire the best.
These questions, as experience has shown me, do help me do that. They aren't the whole picture by any means but they are very useful.
Best,
-Frank
I’d not work with coworker/manager who asks such questions on interview. But I have to admit, this interview in general is not bad. The author at least tries to do some analysis on his questions and possible answers. But level of the professionals he’d find this way would be average. If you need top talent you should ask different things and watch different since. You better let him talk. Ask what he did, how he did it. Ask him about problems he solved, how he deal with them. Problems with technologies, people, etc… If he’ll talk long time about many things with enthusiasm – this is a good sign. If he has nothing to say really, who cares about his certificates? Of course you could direct him to things which are more important to your project. After the interview you shouldn’t think how he fit to the position you have but what value he could add to your team. Some times you are looking for a back-end developer but could find a brilliant front-end specialist, for example. How you would find this out if you’ll ask just database questions. The goal is the IT SWAT team, not a bunch of geeks who know deference between Type 1 and Type 4 but nothing more. Such knowledge is secondary. First is ability to come up with elegant solutions, see patterns, out-of-box thinking, etc…
I'm sure if Byran knew the answers he would post it himself ;)
Just kidding, but on the whole good questions and definitely a 5+ years experience Java developer must know this.
I have only 2 years of experience and I know most of them. This is one journey that will not complete.
In response to anonymous who said "Some times you are looking for a back-end developer but could find a brilliant front-end specialist, for example.".
That's a great point if you are looking for, or can afford to hire, more than one person at a time.
Unfortunately, many of us in Corporate America only have open "Reqs" (Requisition) for a certain role / position. It also depends where you are in your building of the team - if you're just starting out, you definitely should be opportunistic in your hiring.
If you've got a more complete team already then you've probably got less scope (and money) to "just hire the best regardless of where they'll fit".
But yes I would do (and have done that) if and when I have had the leeway.
Again my own interview process is a matter of personal choice but more importantly years of trial-and-error. But as of the past 2-3 years my current process has worked out really very well.
No-one is more surprised than me that several of these questions are quite good predictors of a good productive fit.
In the earlier years I agreed with many of the commentators here - but I got burned by people who could talk a good game (how they solved problems etc.) but couldn't write code worth a damn. Now I ask pointed code-heavy questions and some have a problem-solving side to them.
Others on my team do a more problem-solving focus.
Taken all together it builds a pretty good picture.
Best,
-Frank
A few things. To the person who said: "You are probablly missing out on alot of good potential candidates. No one wants to work for someone who is motivated to make them look stupid."I don't want you working on my team, that's for sure. I want all of my co-workers to admit when they don't know something. I want them to be eager to learn and to freely ask me if I know it. I don't want them to feel superior to me if I have to ask them how to do something. Admitting that you don't know something is not an admission of stupidity.
Secondly, in a technical interview, I try to find out what the person knows. This involves finding out what they don't know. So I expect that I will ask some questions that are hard. Like the post said, if a person doesn't admit to not knowing something and clearly fakes it, I don't want to work with that person because I don't see them collaborating well.
Frank:
The general problem of "how many rows are in a resultset" is something that's hard to deal with in a general fashion. For the database to tell JDBC, the database must know the answer. There's certainly no guarantee that the database has come up with all of the rows at the point when it starts returning results.
How would the JDBC API add the count itself? Really 2 choices: get all of the results and count them. It could be an option, but would definitely have to be opt-in (rather than happening by default) because that could really suck performance-wise. Or, adding to what you said, it could modify the query to include a count. I don't even want to think about going there. So you've got 1 performance-killing option. Do you have any better ideas?
On the JDBC count-the-rows issue. Yeah I agree that *ANY* solution built into the API is probably going to be expensive and should be "opt-in".
But they've already got support for disconnected ResultSets so why not support it there? To make a ResultSet disconnected they've pretty much got to scroll through all the data to get it into memory right?
Anyway it's a wish and one of those good questions that makes people think!
-Frank
In my Java programmer interviews, I generally leave time (15 mins) for an actual programming task -- one I usually use is "write me a program that can take a String and return another String with the characters reversed".
I give the prospect choice of operating systems, choice of editor/IDE and off they go.
The primary reasons for this exercise are:
1) Obviously, if they cannot produce something that compiles - (> 25% fail this -- seriously!) we are done and I needn't waste any more time with the interview.
2) I have not really given them enough information. As is ALWAYS the case in team software development, you have to ask followup questions to nail down the functional specification of what is being asked of you. If the prospect just sits down and starts typing... you start to worry.
3) You observe them at work, doing what you eventually expect them to be doing. What did they choose for O/S (Windows or Unix), and development tools (Notepad, vi, emacs, Eclipse,...).
Are they touch-typists or hunt+peckers?
How is their posture at the workstation?
These may seem like nit-picky things, but a slouchy programmer using 2 fingers is going to have health problems in this profession eventually.
4) When pressed, I ask for a static method that takes a string and returns a string called "reverse".
I've yet to have a candidate write:
public static String reverse(String in) {
return new java.lang.StringBuffer(in).reverse().toString();
}
Thus demonstrating understanding of the requirements **and** the value of code reuse.
If I ever had a candidate also ask whether I wanted unittests to prove it worked correctly....
On the JDBC row-count thing - if you need to know beforehand how many rows there will be, use a RowSet. It is quite impolite to ask the database engine to tell you how many rows there will be up-front because it might end up having to run the query twice, with locking, to give you an accurate answer.
I was the primary developer of the Sybase JDBC driver (jConnect), and early on we recognized that there were lots of request for this feature. We made a slight deviation from the JDBC standard for Statement.execute() result processing.
When Statement.getMoreResults() returns true - you then cal Statement.getResultSet(). If you fetch it to the end (ResultSet.next() returns false), you can call Statement.getUpdateCount() and it will return the number of rows from the just-closed ResultSet.
Man... those people that asked for answers are the people I wouldn't want to hire.
This article is designed to leave the person with an understanding of the skillsets he's looking for. One of thsoe skillsets is the inquisitiveness to FIND THE SOLUTION ON YOUR OWN.
Nuff said.
A fascinating topic!
Many of us have been on both sides of the interview table. I don't think that there is an airtight or foolproof method, but on the whole I like the approach taken here.
As both a staff engineer helping screen candiates as well as a hiring manager I have found that the way people respond to questions is often very revealing.
Accordingly I lean toward very basic questions. If someone can't answer a very hard or obscure question, especially in the unnatural setting of an interview, that doesn't tell me as much as if someone can't correctly answer a fundamental question. And I am more interested in how they express technical ideas than how well they take tests.
As an engineer I have been through many tough technical grillings, and not always with consistent results. But interestingly, sometimes job offers followed when I thought I did poorly, and didn't when I knew I did well, and the actual work once hired didn't always correlate with the interview, and almost always changed over time.
It's important to keep the technical part of the interview in context. Yes, you want skills and apptitude, but in the end, you don't hire a resume or a skillset, you hire a person. Be sure to evaluate the big picture of fit and suitability, which requires being honest about your organization as well as evaluating the candidate.
Finally, I agree with the author that hiring someone over objections of existing staff is very risky (if the existing staff is not him/herself an obvious problem). It absolutely kills morale, and almost always leads to on the job conflict, which always hurts the organization.
Anyone ever read "Joel On Software"? In that book, Joel explains his version of interviewing, as he did it at Microsoft. Honestly, in today's Java world, will zillions of APIs, App servers, and frameworks, I believe asking someone java questions is not too effective. Plus the fact that with google, dozens of books, etc, anyone can pretty much find any answer within seconds.
Here is my version of a java interview, based on Joel on Software:
1) Introduce yourself, explain what the company does and what the job entails. Explain the team, environment, etc. Explain why the company is a great place to work. Explain what the interview will entail. (The introduction)
2) Review the resume, and ask about one project the person liked. Ask them to go in-depth about that project. If the person really did the project, they will know the issues inside out. Question them on why they chose a framework, methodology, etc. Scan the resume for keywords. If you are concerned about something you see on the resume, ask a few questions to explain about the technology they used and why. (validation of the resume)
3) Ask them to write a short piece of code, right on the spot. Hand them a pen and a piece of paper. Something simple, like the reverse string example given, or saving URL contents to a file. Review the code with them, if something is wrong, ask them why. Strong programmers use good variable names, etc. (basic coding)
4) Think of a situation in your experience where you had to design a module or small system. Ask them to design the system (architecturally, maybe with some details on APIs, etc). Ask for which frameworks, APIs, etc they would use, and why. (system design and ability to solve problems)
5) Ask them a far reaching question, something that may have no answer, just to see their thought process. Or, probe them on a current hot topic to see their interest in new technologies.(how they think and are they passionate)
This method has been very effective for me. Just asking OO and Java coding questions is not a good way to judge someone. You may get someone who knows java, and can't solve problems to save their life. For all you know, they studied right before the interview.
Interesting. I've never interviewed someone, but I think I would also ask about design pattern knowledge. My personal experience is that this is as important as good knowledge of the programming language.
I interview a whole lot of Java candidates too, and I think your questions, your lines of thinking, and your conceit match the conceit of your blog title. You're cutting out an awful lot of good people if you really follow and believe all this.
I suggest you spend a little more time absorbing some literature on the differences in personality types.
Not everyone has a photographic memory but some are fast workers who get the job done, some are creative and break through norms to a new and better solution to a difficult problem, and some have more in all productive skills but are very difficult to work with.
I feel stupid stating the obvious like this. But fortunately I'm not the only one raising a red flag at this obnoxious post.
One more thought: perhaps Joel and you differ partly based on your organizational realm. I don't know a lot about you, since your profile is bare, but would it be accurate to assume you're mostly in the medium to large corporate realm?
To Marcus,
To each his own - as I've said previously, I've found this approach much more productive *FOR ME*. I'm not prescribing it for anyone - although they might find it useful after some experimentation and tweaking to suit their situation.
And as I've said before I'm fine cutting out a lot of people as I'm after only the best (in my opinion and in terms of how I define best).
It's funny you mention personality types as it's a well-known fact that in the Myers-Briggs Personality Type Indicator (MBTI) scheme - good programmers can be often be found in the INTP/INTJ space.
I=Introverted
N=iNtuitive
T=Thinking
J=Judging P=Perceiving
See
this link and
this link
I'll let you make of that what you will.
What you said about "break-through" thinkers and creative thinkers is interesting. They tend *NOT* to be in the INT* space.
Also there's no point hiring a highly creative developer who doesn't know JAXB from JDBC. It doesn't matter one single iota if you can come up with an elegant/creative solution or not if you can't implement it.
Sorry if you find the post obnoxious - but no-one forced you to read it!
On a side-note: It may surprise some to know that I used to think like *MANY* of the people who disagree with me. When I was younger and less experienced I didn't have all the API answers and was always wondering "Why can't they see my potential? I can learn!". But now I'm on the other side of the table I see the issue much differently especially after quite a number of hires over the past few years - good and bad.
The last 3 people my team hired over the past 12 months have been amazingly productive in a short space of tiem. I think it's no coincidence that each of them *aced* the test.
-Frank
Good answer, Frank. I stand by my thoughts on the topic, but wish I wasn't so rude, despite my rudeness, it's a valuable and interesting post even if I feel it doesn't take into account some factors as much as I'd prefer to. (My comment on blog posts is always too emotive, bah. ;D)
Hi!
I will start by stating that your interview type is driven not by the fact that you are looking for senior people, but rather by the principle that: "But now I'm on the other side of the table I see the issue much differently especially after quite a number of hires over the past few years - good and bad."
I am not saying that sometimes asking "smarty" questions isn't worth it. But, I really give a damn about the companies that are driving the whole interview this way. Are you trying to prove you know the answers? Oke, I hope you have them :-). Do I need to know them? Hmmmm... some of them maybe, all of them definitely not. I am a (good) professional who knows my limits... and I am not afraid of saying this. Are you? Also, I can bet that some of the people you considered unqualified for the job, can ask you in turn for each of your "smart" question, a question you don't have any idea how to answer. Does it help? Definitely not.
It looks like a lot of recruiters are missing the point of an interview: it is definitely not meant to prove who is smarter. The interviewer must figure out the profile of the candidate based on his experience, and it is his duty to see if this profile will be able to help the Co in the future. A lot of questions in wrong interviews are: "do you know how to solve this problem we killed ourselves to solve?". The correct question is: "if you would face such a problem, what would be your approach?". Do you see the difference? I hope you do :-).
best regards from a not-so-young-other-side-of-the-table guy, doing its job differently,
./alex
--
.w( the_mindstorm )p.
Hi Alex,
You, like others, seem to think I am on some kind of ego-trip trying to prove I am smarter than the interviewee.
That simply isn't true. But it appears that as many times as I try to explain "why" I interview this way I keep getting these comments. I guess people don't take what I say at face value.
Also as I said in my original blog entry (which most people have either not really read or not understood) "Sometimes the answers aren't as important as the attitude taken in responding". I guess many folks still miss that important line.
Then again perhaps it's cultural or experiential differences- many people will see the interviewer as some cruel interrogator - a power hungry villian of sorts.
But funnily enough many of the best/strongest interviewees *DO* grill me almost as hard in return. They know they have their pick of jobs and only want to work with the best for a good salary, benefits and security. And I respect that grilling because I expect to be held to a high standard also.
So I keep getting these comments, and I keep trying to explain that all I am trying to do is find and hire the best programmers I can.
There is no ulterior motive, alternate agenda or axe to grind except that I know if I hire the best my work life will be a little easier, a good bit more fun (great developers often have great senses of humor) and VERY much more informed (the best developers teach me a great deal)
And I re-read my entry and am confused how people can so completely mis-read it . . . . .
and then it's at times like these I remember a great quote that I find helps prevent me from being too judgmental and also helps when others pick up a completely different message than I hoped to convey. And it is this . . .
"We see the world not as it is but as we are" - Anais Nin
Best,
-Frank
Hi Frank!
I must confess that I have carefully read you original post, and all the comments you made afterwards. And I am quite sure I haven't ignored the part: "Sometimes the answers aren't as important as the attitude taken in responding".
But, I have to disagree a bit, by asking which one do you prefere: a punch in the kidney or a normal tap on your back (to get your attention). And I think we both know the answer. The same happens with the questions: I don't want to interviewee to feel it is punched; I want to make him feel confortable and let him focus on the question itself. There are other types of questions (mostly on HR side) that have to deal with punchy-vs-tap situations :-).
To give an example: I am working on Java land almost since its inseption, but I bet my reaction when asked: "WHEN is garbage collection triggered?" would pretty much be: "Ha? what do you mean by when? Do you mean it like in: can I manually trigger it? Or as in can I customize it? Or what?" You see, I am getting defensive, instead of trying to address your real question: "have you ever needed to play with gc? why? why not? what would you do if you would need to?". I am not saying that the question is wrong per-se, but its formulation sounds agressive to me.
I agree that "agressive" interviewing is an interesting approach, but at that point you must answer on your side: "what I am offering to the guy for this type of challenge?".
BR,
./alex
--
.w( the_mindstorm )p.
Interesting and usefult blog. I am the author of Java/J2EE Job Interview Companion at http://www.lulu.com/java-success
would like to know your view on it and also would be interested in reviewing my next edition.
Hi. Thanks for the insights. Cheers and visit us at Helping You SafeList
I think this site is worth a try
before going in for java interviews
http://www.java-interview.com
Very fun questions. I have found in my experience there are three types of programmers plus a few common typs of non-programmers who apply for programmer jobs.
1) Non-programmers. Keyword stuffers. Probably fresh from some 3rd world country or even a US college but never have really written any code.
2) Hackers. No degree. Haven't read 10 books on software development. Can crank out code but cannot work with a team and nobody wants to maintain their code. Prima donnas usually.
3) Average programmers. Come to work 9-5 and can write some code.
4) Superstars. Can write a proxy server in a day or two. When other programmers see their code they are impressed. These are about 1-5% of the population of programmer you run into on a project. Each one can produce about 10 times what the Average produces and about 5 times what the hacker produces. Unlike the hacker, their code has a way of living forever because it becomes a hallmark in the organization. These are the real prima donnas.
The problem with the current interviewers and headhunter companies is few to none have CompSci degrees so they think knowing how to setup Struts is more important than knowing network and disk latency; hence we have a generation of mediocre apps which really drive system architects crazy in trying to get out decent performance.
Best,
Tim
http://www.serviza.com/
"You, like others, seem to think I am on some kind of ego-trip trying to prove I am smarter than the interviewee."
I don't understand people that flame you, on your own blog, for having an original point of view.
I am not a fan of the "puzzle" interview question, because from experience, I generally get these wrong. I know that I am a good developer. The only time I think about those types of puzzles are when I read articles by Microsoft Me-Toos proclaiming that this is the answer.
I have my choice of companies, just like you have your choice of hires. If someone asks me a puzzle question and I fail it, big deal, I move on.
I also agree with you that it *IS* ok to want someone with "all the API answers." What is wrong with wanting to hire someone who can wire up a solution in one or two days, as opposed to one or two weeks?
The comments are great. I wouldn't hire most of you. :-)
The thing about tests is that they don't tell you anything if someone can answer them all. You should be asking some real brain-benders so you can see someone struggle and, possibly, get things totally wrong. If they ace the test, all you know is that they know everything you asked. If you throw in a question about something they're less likely to get, say, follow a question about compiler construction with a question about EJB or graphics, you'll learn a lot more about how they prioritize their attention, which, ultimately, will tell you what kind of person/developer they are.
I have been through my fair share of Java technical interviews and I am usually offered the job at the end. However I see interviews as a two way event, it's also my chance to interview the company that I may potentially end up working for. So during the technical test I also ask the interviewer some technical questions of my own just to see how knowledgeable they are. As you can imagine this is often a surprise to them! This a very useful technique which helps me discover what the technical ability of the people I will be working with is like, which for me is essential in deciding between different jobs.
This seems to be a new site for java interview questions and the answers professional..
Hi,
Thanks for these interview questions. I would also like to share my favorite interview questions asked during Java interview , beuty of these questions are there cross question
and getting deep into concept.
deadlock in java
Why String is immutable in Java
Difference between HashMap and HashTable? Can we make hashmap synchronized
ow to check if a thread holds lock on a particular object in Java
How HashMap works in Java
How get() method of HashMap works in JAVA
How classpath works in Java
TIBCO Interview Questions.
Thanks
Javin
FIX Protocol tutorial
I have read couple of good article about conducting interviews and it seems they all favor for technical properties. I agree technical skill is important but at the same point soft skill, behavioral skill, attitude and personal human quality are more important because you can fill the gap in technical knowledge but believe me you can't change the other qualities I have listed and plus point is person can't fake those qualities.
Thanks
Core Java Interview question
plz. post all the interview questions you have,with answer if possible.
I want to share one question which will help you in Java Programmer's Interview.
Question: What is a user-defined exception?
Ans: Apart from the exceptions already defined in Java package libraries, user can define his own exception classes by extending Exception class.
Post a Comment