Am I too rough on them?
We ask all kinds of questions during interviews, of course. There are the soft "people" questions. We sometimes answer org chart questions (lots of boxes and lines on the whiteboard). There are high level architecture discussions (lots of boxes and lines on the whiteboard). And there are programming questions (lots of boxes and lines ... oh, you get the idea).
When talking to candidates, I personally want to know if my future peer is in touch with his inner computer scientist. Detailed API knowledge is not important (although if you only know enough Hibernate to be dangerous ... you are dangerous), only programming aptitude. So I'm hoping for the candidate to show off his inner geek: algorithms, data structures, big O notation and most importantly the ability to code. This is undergraduate CS stuff that a programmer should have in his head at all times. The tricky part is how to test this. Usually, it's in the form of a "simple" programming exercise.
I will tell you an programming exercise that I have stopped using: reverse a linked list. It's on Joel Spolsky's list of programming exercises for interviews. Unfortunately, it has been years since I interviewed anyone who can answer that question. I realize that it's not as easy to work out code on the whiteboard, and people can be nervous. I personally have crashed and burned under interview pressure, so I sympathize. I can understand if someone occasionally has a bad interview, but not if everyone I meet blow up over this. This isn't the hardest question out there. It's not a brain teaser nor a trick question. An exercise like this needs some familiarity with the data structure in question, and sometimes there is some discussion of algorithms associated with the data structure. The resulting discussion would ideally show off the candidate's ability to comprehend and address the problem as a programmer.
What is distressing is when somebody comes in with an impressive resume who otherwise had a good round of interviews. It's painful to see them struggle when my expectations are high. Even without that linked list exercise, many candidates do not seem prepared to get their hands dirty. Very few do well with programming exercises. Is there a better way to demonstrate programming aptitude?
Maybe it's not a good time
It's not 2001. At the height of the dot com bubble, we're told, lots of people entered the software industry who can't code their way through wet tissue. But after a decade, the fakers should have faded out of the no-longer-lucrative industry. We're supposed to be in a down economy in the US, so there should be a lot of good people out there. So why are recruiters trying to recruit people who are still working? It looks like the software industry never got the memo about the bad economy. Check out the Indeed job trends for Java. If this is what it looks like in a bad economy, I hate to think what it would be like to recruit under full employment:
It looks like this is still a fine time to be a Java developer. Wasn't Java supposed to be dead?
How about you?
Are you a Boston-area software engineer with serious Java kung fu? Interested in working for a software startup in the health care industry? Shoot me an email. Maybe you can show me a thing or two about how a good software engineer will interview.
In addition to the standard Java interview questions, I give a take-home test (similar to the one from cyrusinnovations) and talk through issues if I decide to bring them in.
ReplyDeleteIt's very, very difficult to find good Java developers. I look for Java devs with experience in higher-level languages; generally an indicator of how well they'll program Java. People that have only programmed in Java or equivalent languages are myopic.
I dont understand your problem. You said you want "algorithms, data structures, big O notation", but also its ok if he doesnt care to know api's. I know a lot of people who dont know Java and I still programmers. The key is to make sure they dont know things they are using(since only ancient knowledge is sexy). asked them about regex and if they know what it is you should see it as a red flag. you dont need to know what regex is, its just an api.
ReplyDeleteI wish I lived in Boston...But I'm in the other side of the Atlantic and currently off business due to my Army duty... hope to find for the Javaholic you are looking for! :)
ReplyDeleteYour problem is hardly unique. We also know that the number of CS students have dropped and keep dropping, while at the same time, all CS job openings are increasing and will keep increasing.
ReplyDeleteWe will have a widening gap between the need and supply and you will have slimmer and slimmer pickings. If you want someone good, you have to get a head hunter, your company has to be top notch, and you have to pay a lot of money to attract talent.
The situation is bad now, but it will get much worse.
Perhaps a problem is your going back and testing against undergrad CS knowledge whereas as a Java developer you can spend years implementing software and scarecly have to draw on that manner of knowledge.
ReplyDeleteJava has a rich substrate to program on in terms of collection classes, libraries, and frameworks. It's not that often one has to drop down to write a new collection class where there might be a chance to exercise fundamental CS knowledge.
The point being is the undergrad CS stuff languishes.
Back in the day when we code in C and then C++, with a fair amount of assembly interspersed, there were more situations where one would draw on undergrad CS knowledge to code data structures from the ground up. One project I did for a company was a replacement memory manager for C++ on the original Mac OS (which had handles to memory that could be compacted). In the Java world, no one writes that manner of software.
php programmer also hard .i mean oop php programmer
ReplyDeleteThe typical Java enterprise stack is mind-numbingly dull. I'm not trying to be insulting here, but perhaps you're seeing the results of that.
ReplyDeleteMaybe recruit from outside of that comfort zone and provide training (or at least time) to bring the smart guy you get down to the level you need.
sounds like you have a problem of _attracting_ experienced Java developers. Maybe your too focused on algorithms and big-O notation to realize that you lack the good corporate kung-fu. If you're looking for someone special, you had better put something special out there - equity, very above average compensation, seriously interesting work.
ReplyDeleteIts hard to find good programmers in _any_ language, not just Java. What Java has going against it, is more often than not, it involves _numerous_ frameworks. Its hard finding someone who is a Guru in each of those technologies. You may find a Hibernate guy who is a "god" in his own right, but can't do a damn thing with JSF, etc...
ReplyDeleteDo you think that you could for instance use a some kind of trial period to find out whether a person can really fill in your expectations or not? Programming questions on a interview are not my personal favorite, because there usually is no time for tricky questions, and the basic ones do not give any information about the competence of an applicant.
ReplyDeleteOn the other hand, I will rather recommend a person, who I feel would fit in with the rest of the team. The technical knowledge of the applicant can be put to test on a trial period, if we end up hiring him/her.
RethinkDB had similar problems: http://www.rethinkdb.com/blog/2010/06/will-the-real-programmers-please-stand-up/ . Actually, this post made quite a lot of buzz (http://news.ycombinator.com/item?id=1471988).
ReplyDeleteIn the same spirit of the suggestions above, and on the RethinkDB discussion, my suggestion is: look for good developers, regardless of language/framework skills. These will be able to pick up such easily, and will probably be easier to find.
How much are you paying? Expecting talent for 45,000/year?
ReplyDeleteThe economy isn't bad enough that good people won't find better jobs.
My advice is to stop stressing people out. A 15 minute talk with a technical person and a line manager is enough to get a good idea about any guy. Also to be able to discover any significant flaws in his claimed skills and his CV. You can never be secured enough, but you are always able to fire the guy after a few weeks.
ReplyDelete-Martin-
It's all about the money.
ReplyDeleteGood Java devs know they can make a lot. So you better be offering a lot.
Just today I had to implement custom tree in java in which each node has 6 children and each node is 3D cube. And for the desert I had to write function that recursively goes trough the tree and renders the cubes in 3D space.
ReplyDeleteNot all college knowledge is a waste of time. Some basics that you learned always come handy from time to time. :)
Joel also suggests to treat programmers like rock stars. If you are not the type of employer who would/could treat programmers like rock stars then please don't complain. You wont find an exceptional programmer for mediocre wages
ReplyDeleteThanks for the comments.
ReplyDeleteI'm surprised at the number of comments that seem to assume we don't pay enough. Come on, 45K? Good grief. I'm talking about candidates who come in for their first interviews. We hadn't even gotten to the salary negotiation stage yet. It's quite a different story if we get all thrilled by a candidate who later refuses our offer, but that does not happen at the first interview.
I know a trial period tells you a lot, but when you do a trial hire, you're practically hiring that person anyway. You pay the costs of money and developer time getting a trial candidate up to speed. This is not something you can do with a lot of candidates, so you still have to interview and select carefully.
Even though these jobs are technically at will, practically speaking it's hard to fire someone who is not an ax murderer. Firing anyone can be tough on workplace morale, because that person can be a genuinely likable, good person, even if otherwise incompetent. Also you risk getting hit by a wrongful termination lawsuit. A small company cannot afford such costs and disruptions, which is why it's generally better to miss a good candidate than to hire a bad one.
Because is difficult to find a developer.
ReplyDeleteYou wrote:
ReplyDelete"But after a decade, the fakers should have faded out of the no-longer-lucrative industry."
As long as the demand is still relatively high, so will the amount of people who are just barely scraping by. (yes, that rhymed.. :/ )
I had to explain to a (junior) developer (and recent CS graduate) how to solve a NullPointerProblem. Thankfully it was still his trial period..
As far as I'm concerned, your post is right on target: my college (CS) curriculum covered everything you write about (and much more..) and when I went back to the website recently, the major requirements were still just as rigourous. I graduated in 2003 from a US state university, by the way.
What you pay is what you get.
ReplyDeleteIn over 10 years of professional programming I have never been asked to code a reverse linked list. As a Java developer it's simply rarely ever needed. The answer is simple...Start asking more relevant questions.
ReplyDeleteI don't remember asking candidates to code. What I do ask everyone of them is to explain in detail how they solved any difficult technical problem at a previous job. It doesn't even matter if the solution was good or bad, all it matters to me is that they devised the solution and that they explain it to me *in detail*. If they can't explain it consistently and answer questions about the solution, I take it as a very bad sign. Those candidates than can, usually perform well when we hire them.
ReplyDeleteYou could also look for people working on OSS projects on their resume and take a look at the code the did work on. Doing work on a OSS project has never closed a door on me.
ReplyDeletegreat!!!
ReplyDeleteJust found this, but I was struggling with this exact problem about the same time you were. I wrote up a list of questions, and one of them was "Tell me about the 'synchronized' and 'volatile' keywords." I almost took this off my question list as being "too easy", but I was amazed at how many people had never heard of "synchronized", and only one candidate knew about "volatile." I wasn't looking for a diatribe about how JSR-133 changed the memory model in Java 1.5 and changed the semantics of "volatile" and "fina" or anything, but I at least expected people to know that synchronized provided a mutual exclusion mechanism.
ReplyDeleteSpoken like someone with no CS training and no idea how to interview engineers.
ReplyDeleteYou have a lot to learn. No wonder you have a hard time finding developers.
The java developer for particular specialization are rare and in java you can not go for particular functions or features as it is vast language.
ReplyDelete