Showing messages 1 through 57 of 57.

• Pre-interviews
  2004-05-11 10:17:19 johnm
  
  

  How many rounds are you going through before getting to an in-person interview? I.e., how many e.g., email and phone interviews do have you had before being asked in?

  Were they from HR people or a technical team manager/leader or a technical team member?

  Were they quick and dirty filters to reject stalkers or something a bit deeper?

  How many times have you been contacted by scamming body shops that didn't actually have a real job but were just pumping you for information and contacts?

• Pre-interviews
  2004-05-11 17:26:34 tackline
  
  Through my career I have had a number of phone interview, but they don't seem to have a common theme.
  
  The first hadn't decided if they wanted a Java or a C++ programmer. The second got me a face-to-face interview, but the job turned out to be straight C. The third was just a former agent employed by a software company. The forth was short, turning me down because of something clearly stated on my CV. Only the fifth actually asked non-trivial technical questions.

• Crappy interviews abound
  2004-05-06 03:06:40 vlenin
  
  I've been looking for a new job for the last few weeks and have been to several interviews.
  3 of the 8 or 9 interviews I've been to I have considered to be good interviews. The rest have been horrible.
  One place I interviewed at refused to tell me what the details of the job were. All they would tell me was that they needed someone with J2EE, WebSphere and Struts experience who was willing to work lots of overtime.
  For the most part the questions I've been asked have been stupid. What's the point of asking me something that I could look up in a book in 3 minutes? Does that really indicate how good or bad a programmer I am?
  I now ask technical questions of my own. I have yet to have an interviewer answer all of my questions (and I only ask about 4 or 5), correctly. The questions I ask are fundamental questions about Java or J2EE right out of the specs. I think it's only fair for me to ask technical questions if they are going to. Afterall, I'm making an investment in their company by joining it, just as they are making an investment in me by hiring me.
• Crappy interviews abound
  2004-05-08 20:35:45 rickcarson
  
  Sidenote: I'm not surprised you're doing lots of interviews and not getting anywhere with this kind of adversarial attitude. Change your attitude dude, they're (A) trying to help you get a job and (B) they liked the look of you (on paper) enough to get you in to do the interview.
  Don't just flip them off or get into some kind of alpha geek pissing contest. All that shows is that you're an a$$hole. Face to face interviews are all about 'can I picture this guy working in team X - or is he going to be a disruptive prima-donna type???'. Which is why you get asked 'dumb' questions like 'are you a team player' (which is *not* actually a yes/no question, its more a test of reflexes :-)
  
  ------
  
  

  
  What's the point of asking me something that I could look up in a book in 3 minutes?
  

  
  
  Well, first up, it shouldn't take 3 minutes, unless you've got a real slow internet connection :-) Learn to love (and use):
  http://java.sun.com/j2se/1.4.2/docs/api/
  
  Secondly, if you are taking 3 minutes everytime you have to do something really basic, you're not going to be very productive.
  
  ------
  
  The reason that interviewers ask these questions is that there are so many people out there who *don't* know the answers to the basic stuff, yet are calling themselves Java programmers.
  
  On the assumption that you are being interviewed by a non technical hr type of person, better questions would be things like 'what sort of commitment does your company have to the Java technology'. Ask questions about their investment in the technology and their level of commitment. Ask questions about the other things you might be expected to do or know.
• Crappy interviews abound
  2004-05-10 14:44:01 vlenin
  
  It depends on what you mean by "getting anywhere". I've gotten a few job offers but haven't pursued them for a variety of reasons.
  
  I don't "flip them off or get into some kind of alpha geek pissing contest". At every interview I am polite and nice. I don't tell them how badly it reflects on them or their company when they are late and leave me waiting for 20 minutes.
  
  Most people make decisions based on emotion. The whole point is to get the person who is interviewing you to like you. That is your best bet for getting the job.
  
  Asking me what the difference between a SAX and a DOM parser isn't a particularily useful question as far as I'm concerned.
  
  Thanks for pointing out where the online javadocs for j2se 1.4.2 are. I never would have found them without you.
• Crappy interviews abound
  2004-05-07 01:36:49 jwenting
  
  Remember that most recruitment interviews are not done by technical staff but by managers and/or HR people.
  
  Those people in general have no knowledge about the tecnical subject matter they're talking about (though they often hide their ignorance well, they've probably been trained to).
  
  The technical questions they ask you are read from a piece of paper (or memorised), the answers similarly are either compared with a prepared list or handed to some technical person for grading.
  
  The few occasions I've been interviewed by real technical people the experience has usually been that the questions change into a (more or less open) exchange of ideas and philosophies rather than a rigid question and answer game.
• Crappy interviews abound
  2004-05-12 05:26:47 paulja
  
  "The few occasions I've been interviewed by real technical people the experience has usually been that the questions change into a (more or less open) exchange of ideas and philosophies rather than a rigid question and answer game."
  
  When this happens, I usually find that I will be offered the job.
• Crappy interviews abound
  2004-05-07 02:02:26 vlenin
  
  As I stated below I never ask HR or business people technical questions. Most of the places I have interviewed at there has been a technical person involved in the interview process.
  I am always seeking that exchange of ideas that you mention, but it seems to happen less and less these days.
• Crappy interviews abound
  2004-05-06 16:16:37 gvix
  
  Hello,
  
  

  3 of the 8 or 9 interviews I've been to I have considered to be good interviews. The rest have been horrible.

  
  
  Could you explain why you thought those interviews were good? Compare them to the tips I have given. Do the tips stand up against your practical experience?
  
  

  What's the point of asking me something that I could look up in a book in 3 minutes?

  
  
  That is exactly the point I make in my tip 6.
  
  

  I now ask technical questions of my own.

  
  
  Interesting! Turning the process on its head. How has been the response?
  
  Regards,
  Vikram
• Crappy interviews abound
  2004-05-07 03:03:12 vlenin
  
  "Could you explain why you thought those interviews were good?"
  
  The interviews that I've been to that I consider good are the ones where the potential employer made at least some effort to make me feel comfortable, (would you like to hang your coat up?, would you like some water or coffee?, etc.). It's also nice when the people interviewing you tell you their names and what they do at the company.
  As well, I much prefer a discussion about technology and programming as oppossed to questions like "What's the difference between a SAX parser and a DOM parser?".
  A question like "What do you like about EJBs?", followed by "What do you dislike about EJBs?" I consider much more productive. As well, the interviewer should answer questions like these him/herself. That way we are exchanging ideas which is a much better way to learn about other people.
  As far as I'm concerned it is unacceptable for a non-technical person to ask technical questions. Consider the following situation:
  I was asked by a non-technical interviewer, "Why should one not use file i/o from within an EJB?". I answered that it was a security risk as file systems are less secure than a JNDI look up. This isn't a bad answer. But the piece of paper in front of her said that due to the distributed nature of EJBs using a resource specified on a file system is blah blah blah, you know the rest. Now we were both correct, but she didn't want to accept my answer because it wasn't on the piece of paper in front of her. Is the company really being responsible in their interviewing in this situation?
  I expect the people interviewing me to be professional and intelligent. Writing comments down and passing them to another interviewer during the interview is unacceptable, as is interviewers whispering to eachother while I am answering a question.
  They might as well be talking on a cell phone.
  My time is valuable and if you are going to waste it during an interview then chances are I'm not going to work for your company.
  
  The tips you gave in your article Vikram I agree with completely, with the exception of your point about theoretical questions. I don't mind a little theory in the interview, as long as it's a discussion about theoretical points.
  
  I have asked technical questions in two interviews. One went very well, and I actually got the job but didn't take it because it was just too far from where I live and I was interested in spending 3 hours a day on the road back and forth from work.
  In the other one, they just sat there like I had punched them in the stomach and couldn't really answer anything that I asked. At one point I started discussing different development methodologies and what I saw as the strenghts and weakness of them. When I asked them about what methodology they used they just muttered that they had a "homegrown" technique that borrowed from several others. This of course ment that they had no methodology and just made things up as they went along.
  
  I don't really see it as turning the process on its head. I am not the greatest Java programmer in the world, but I'm not that bad either. I am a hard worker and a good employee. I've never been fired from a job and every place that I've left has always wanted me to stay. I have excellent references from every job I've ever had. Under the correct circumstances I can be a very valuable part of your team. So what I want to know, is why do I want to work at your company?
• Crappy interviews abound
  2004-05-06 08:50:31 duanegran
  
  At a glance what you say makes sense, but only if you know that your interviewer is a technical lead on the project. If you start asking the PHB technical questions he is going to think you are a smart ass. Be reasonable. He or she isn't asking you hardball business questions, so don't toss back hardball technical questions.
  
  That said, your idea has some merit and I think applicants should ask intelligent questions. This means mostly learning about the business, which includes understanding how they make money (not always an obvious thing) and how your work will affect the bottom line.
• Crappy interviews abound
  2004-05-06 12:12:34 vlenin
  
  I agree with you 100%.
  I would never ask a non-technical person technical questions. That's just common sense.
  Outside of specific technical questions I also ask about what development methodology the company uses, what sort of tools are used, how I would fit into the department I am being hired into, what best practises are used, what the structure of the development department is, etc. I've been burned too many times, joining companies that just had no structure or any idea what they were doing.
  I will go the distance for a company. I'm happy to give all I have, to work late nights and weekends if that's what's needed to get the job done. But I'm sick and tired of companies not living up to their responsibilities. Programmers need an evnvironment that they can succeed in and at this point that's all I'm really asking for.

• Java Certification
  2004-05-04 19:15:31 rickcarson
  
  I used to write the questions for Java interviews for most of the places I worked.
  
  Even basic questions, most people only scored 20% tops.
  
  So I'd slant more towards general questions, sometimes with lead up questions.
  
  Eg: "How would you read data from a file", leads up to "...so... what is a stream anyway?".
  
  The highest scorer we had was a C++ programmer who'd never used Java before - but he knew OO.
  
  Doesn't say much about the people calling themselves Java programmers. (And by implication, it speaks volumes about the agencies and people doing the hiring... but... I digress)
  
  ------
  
  Ultimately, I now only have one real question:
  "Are you Java Certified, and if not, why not?"
  
  I'd take a Java Certified person over any non certified person any day of the week. Even if the non certified person was *claiming* a lot more experience than the certified person.
• Java Certification
  2004-05-07 17:14:08 johnm
  
  

  I'd take a Java Certified person over any non certified person any day of the week. Even if the non certified person was *claiming* a lot more experience than the certified person.

  That's frightening. What make's you think that a certification has any correlation with ability to program in the real world?

  Perhaps, if you're hiring a bunch of very inexperienced people then one of them being certified might show that they are out there learning (but it's much more likely that they are trying to play the HR keyword filtering game). If in that case, it's much better to learn about what they have been working on in their own, free time.

• Java Certification
  2004-05-08 20:51:16 rickcarson
  
  Have to disagree with you there. I don't want to know that someone is building a file sharing client in their spare time.
  
  (On the other hand, if I wanted to give someone a test of their design skills, I might hand them a whiteboard marker and whiteboard and say - here, design me a file sharing application. Then to test their programming skills maybe sit with them for an hour to see them coding in the flesh)
  
  I give spare time projects a much lower ranking than say real world job experience. People who talk about their spare time projects are usually just trying to pad their resume or cover for a lack of real experience.
  
  Anyone who claims to be a Java programmer buts blows off the exams as a waste of time and money has an unprofessional attitude. I know lots of people who haven't gotten round to getting the certification yet, but I'll give them partial credit if they at least show some interest in it.
  
  Are you a Java programming professional or a wannabe? Well then, step up to the *minimum* professional standard.
  
  In addition to that, people who show an interest in the exam show that they are still interested in learning things, whereas people who say they don't need it because they 'know it all' already demonstrate a closed mind. Given two choices of new hires, I'd much rather work with someone who was teachable.
• Java Certification
  2004-05-09 13:05:19 johnm
  
  

  I don't want to know that someone is building a file sharing client in their spare time.

  Given two choices of new hires, I'd much rather work with someone who was teachable.

  I find these two statements to be contradictory. Someone working on their own projects on their own time is a huge indicator of them having passion about what they spend their life on. Now, if someone came in and said that one of the things they've done to motivate themselves to learn more of the details about a technology by using the certification process, that says something. Somebody going through the motions to get a piece of paper says something quite different (and just looking for an entry on a resume to distinguish those two cases is, of course, impossible).

  Again, let me ask what evidence exists to show that *any* common certification has any correlation with any useful capability such as "professionalism", "knowledge", "skills", etc?

• IQ "Certification"?
  2004-05-11 14:08:32 johnm
  
  

  Check out Dale Asberry's blog onIQ is a Relatively Meaningless Number Consumed by Egotistical Narcissists.

• Java Certification
  2004-05-07 00:33:13 bblfish
  
  These Certifications sadly can be very useful. (And you can learn a lot doing them).

  The problem with so many head hunters is that they are completely keyword based, and have absolutely no conception of the difficulty of the skills involved. When I was looking for a job in London there was a junior role I was interested in because I thought it might help me get into banking. It was to convert VB programs into Java. I had 6 years of Java experience at the time and 1 year of VB. The agent on the other side asked me if I had VBA, and I paused wondering what VBA was. I said I was not sure. And that was the end of it. (VBA is just VB for MS Word, duh!) I found this attitude over and over again in England. Did it matter that I had worked for the largest search engine, and written the babelfish at AltaVista with over 1 million hits a day? Not a jot. I knew ATG version 4.5, but did I know version 5.0?

  My impression of the US was very different. When I went to the first Java One conference in San Francisco I had written a little java applet that received a prize on Gamelan. I had been looking for a job in the UK at the time for over six months, but could not explain what I had done to any of the head hunters because none of them at the time had an internet connection. In California they all had.

  From this experience it is my feeling that most head hunters in Europe at least actually do a disservice to their customers. They filter out the good candidates!

  So having a Java certification in that context really is important. It is very easy for those head hunters to understand. And also it helps focus the conversation during the interview on the substantive matters, such as your interests, higher level questions, rather than these interviews concerning the intricacies of method access of static inner classes.

  The other solution I am trying out now, is to work on Open Source projects. Then I can simply go in an interview point the person to my contributions on the CVS tree of whatever I have been working on and discuss that, if they want to see my work.

  This makes me think. Since SUN is laying off a lot of employees, one thing they could perhaps do is for those that have worked on projects that have open source components, is to mention the names of those that contributed to aspects of the code. That would help those find a job, and keep SUN in their hearts.

• Java Certification
  2004-05-07 01:45:54 jwenting
  
  Your experience is quite typical.
  
  Recruitment procedures in Europe are far more frequently handled purely by the HR department and even if the technical department who will employ the new person gets to be involved they rarely have the last word.
  
  One friend of mine was interviewed several times by the IT department of a large airline who wanted him badly. But without the consent of HR they were not allowed to hire him.
  HR demanded an assessment center where he was put through the exact same program as were flight attendants and telephone operators with the conclusion being he was unsuited to work in IT or to have customer contact (he worked in IT for 20 years and in public radio for 10 years before that successfully).
  That damning conclusion was more important than the glowing recommendations from everyone he'd talked to in the IT department where he'd shown he had all the skills (both technical and social) required to excel in the function.
  
  I've also seen the numerous requirements that list very specific versions of products.
  Usually again that's not because the IT people want it that way, but because HR demands it.
  It's the same again as when in 2000 there were jobs advertised for Windows 2000 Server administrators with 10 years experience on Windows 2000 (which had been released only months before).
  I've myself encountered rejections for not meeting impossible qualifications (like 10 years experience with JSP/Servlets in 2001).
• Java Certification
  2004-05-07 00:56:22 bblfish
  
  That makes me think: perhaps SUN should develop a headhunter certification, so that companies can distinguish between headhunters doing them a service and those doing them a disservice. It would make sure that the head hunters understood the concepts from Java to enterprise Java to Unix and more...
• Java Certification of head hunters
  2004-05-07 17:59:48 johnm
  
  

  LOL! Thanks!

• Java Certification
  2004-05-06 14:33:17 tackline
  
  I really can't agree with you about Java certification. SCJP/SCJD only tells you that someone isn't a total moron. Absence of evidence isn't evidence of absence. If you want to sort the good from the vaguely-know-what's-going-on, Sun's certification wont help you. If you filter CVs on the basis of the certification you'll filter out most of the good programmers.
  
  I'm not so much as an SCJP, although I think it might be a laugh to get a SCJBCD without having so much as written a single EJB. A few years back I did a long Java 2 computer-based test, despite not having used anything in 1.2 except for 1.1 compatible Swing, I apparently did better than anyone company had ever tested, including all of their developers. The trouble with SCJP-style tests is that they only test simplistic knowledge. It wont indicate whether the testee can program. Of course, most people hiring Java programmers can't program anyway, so can't tell the difference.
  
  Why don't I have an SCJP? It bureaucratic to obtain and costs money for something that is worthless.
• Java Certification
  2004-05-08 06:57:47 smike
  
  Java Certification is important. I have interviewed quite experienced developers, that doesnt know basic Java programming things. For example, one guy told me that it's illegal to have return statament in try block !!!
  
  Best choice are certified and experienced persons!
• Java Certification
  2004-05-08 21:11:51 rickcarson
  
  I was looking through the code another developer wrote the other week and saw a return statement in a finally block.
  
  My first reaction was "that's illegal!"
  My second reaction was "that shouldn't even compile!"
  
  My third reaction was to wonder what the heck that does, so I fired up my little test program for checking bizarre boundaries of the language, and tried it out.
  
  My fourth reaction was "that *should* be illegal!"
  
  My fifth reaction was to check the company coding standards - fortunately they'd explicitly said you shouldn't do it.
  
  My sixth reaction was to fire off an email where I did my nut at the team concerned.
  
  ----------
  
  That, and having a look at recertifying for a more recent J2SE version, has made me realise that I actually use a really small subset of the language. I like:
  * interfaces
  * inheritance
  * exceptions
  * listeners
  * stupid constructor tricks
  Really solid, basic stuff with lots of code reuse. Real KISS stuff (except for SCTs). But using those same things I can solve some really tricky problems very quickly, and respond to changing requirements quickly as well.
  
  Some people like to make things complicated. You see people complaining about casting things they're pulling out of Hashtables - and you look at their code and its spaghetti - and you ask them '... so ... why are you using a Hashtable?' And you find out its because some CS professor said they were teh fast0r... and then you dig deeper and find out they're doing something really bad, like spending their whole time building factory classes and recoding everything to static methods - because the same CS Prof said that 'new is really slow'.
  
  Once they know and trust the language, they'll tend to do that less. And Java certification is a good way to achieve that.
  
  oh... and don't rule out a good larting!!! ;-)
• Certification vs. Having a Clue
  2004-05-08 08:23:03 johnm
  
  

  What's your evidence that there's a correlation between being certified and being an excellent programmer?

  I've found literally no positive correlation between certified programmers and any of skill, experience, or wisdom. In fact, I've found a slightly negative correlation in that most people getting certified are doing it for primarily non-performance reasons such as getting past keyword searches and hiring agents that don't know any better. I have found a strong correlation between people who tout that they are certified as if that made them experts as being a clear sign that they aren't. [This latter case is like the people who go out and buy the various books talking about the puzzle/brain-teaser tests that companies like Microsoft like to bombard candidates with so that they can cram for their interviews.]

• Certification vs. Having a Clue
  2004-05-08 20:21:17 rickcarson
  
  In my experience this is not true.
  
  There *is* in fact a very strong correlation between good programmers and certification *in Java*.
  
  Sure, in the MS world, things are different, because their exams are so weak, and are more 'political correctness' tests.
  
  But... just in case you haven't noticed by now...
  
  Java != MS
  
  The java exams require a very strong grasp of the fundamentals.
  
  Every person that I knew was at least a 'pretty good' programmer (ie candidates for 10:1 ratio), who I encouraged to get certified had this series of reactions:
  
  Stage #1: Certification is pointless - just look at the MS rubbish!
  
  Stage #2: Pfft... I'll show you... I'm going to ace this online mock exam
  
  Stage #3: OMG this is so hard...
  
  Stage #4: 20%!!!! WTF???? 20 freaking percent!!!!
  
  Stage #5: I will study hard, I will crush this exam before me, I will drive it before me, I will burn its villages and hear the lamentations of its women!!
  
  ... several months go by ...
  
  Stage #6: Hah! I'm certified baby! ph34r m3!!! I am the 1337 J4\/4 h4xx0r now!!!
  
  ... several weeks go by ...
  
  Stage #7: Hmmm... you know... I don't get as many errors when I go to compile as I used to... and I'm much more productive... and I'm better at debugging.
  
  Stage #8: Y'all should get certified! It's good for you, mm'kay??
  
  -------------------
  
  Java certification is *not* going to turn you into some kind of super programmer.
  
  But it absolutely *will* make you a better Java programmer than you are now.
• Certification vs. Having a Clue
  2004-05-10 00:00:59 ojw
  
  I'm a programmer with a few years of OO C++ behind me, a little java and am in stage 5 at the moment. :-)
  
  Ok, maybe I've never used "strictfp" before, but maybe I really do want to write portable floating point algorithms. Perhaps it is useful to know what happens when you take all the breaks out of a switch.
  
  I know, you're all laughing at me, but the point is that you get used to writing safe code, and when you come across code written that isn't safe, you should know what to do.
• Java Certification
  2004-05-06 08:40:46 duanegran
  
  As a person with Java certification, I would suggest you broaden your criteria. Certification in Java is hard but it is perfectly possible to be a bad programmer or a bad team player and to achieve certification. When hiring I consider attitude, aptitude and skill, that latter of which is the most trainable aspect of the candidate.
• Java Certification
  2004-05-08 21:48:40 rickcarson
  
  Typically, the first part of a hiring process is to vet the cvs. At this point, your task is to reduce the pile down from say 1000, to say 10.
  
  Hence to do this efficiently, it is good to be able to discount 90%+ of the applicants on a single criterion. Certification serves that purpose admirably.
  
  Then you go looking at other factors.
  
  Once you've narrowed your search sufficiently, then you do phone interviews etc, if you don't find anyone you like, you change your search parameters, or get less fussy about one of the other requirements.
  
  

  
  When hiring I consider attitude, aptitude and skill, that latter of which is the most trainable aspect of the candidate.
  

  
  
  When hiring, none of those are easily testable, and all of the candidates are claiming them.
  
  If you want to spend a day or week on each initial candidate, then fine, go ahead. But if I get a stack of CVs to look at, I want to quickly be able to hand back to the people doing the hiring a short stack of 'try these ones first' a slightly bigger stack of 'and maybe these ones if you don't find one in the first lot that you like' and a much larger pile of 'burn these - and scatter the ashes'.
• Java Certification
  2004-05-09 14:40:31 tackline
  
  Discarding CVs on the basis of certification is less useful than discarding surnames starting from A-T and keeping U-Z. The only people I've seen proudly displaying Java Certification are hopeless programmers. You're not going to find M[rs] Wright that way.
• Java Certification
  2004-05-06 16:21:55 gvix
  
  Hello,
  
  Certification is certainly not the end-all criteria of hiring candidates.
  
  "When hiring I consider attitude, aptitude and skill"
  
  I agree that this is exactly what companies should be trying to assess when hiring candidates rather than grilling them on bookish questions. How do you, or your organization, assess these qualities?
  
  Regards,
  Vikram
• Java Certification
  2004-05-08 13:06:19 duanegran
  
  How do you, or your organization, assess these qualities [attitude, aptitude and skill[?
  
  One thing I've done before in an interview is bring in several sheets of paper and various pens. After breaking the ice in the interview I say, design an airport for me. It is sort of a game where the person should proceed to ask me probing questions about what I mean and to use the materials I've given to arrive at an answer.
  
  A good candidate finds out that what I really wanted was a customer's bag check in software and that a UML diagram representing the system (state diagram) would be ideal. The bad candidates start drawing an airport without asking any questions.
  
  In my opinion the thing that distinguishes good system designers from great ones is their ability to ask an intelligent question.
• Java Certification
  2004-05-10 00:38:58 jwenting
  
  You want an airport, I give you an airport.
  It's not the programmers' job to determine customer requirements in most companies, that's what architects and sales people are for.
  In fact, in most companies the programmers are pretty much completely shielded from any customer contact at all.
  
  So if you give me your requirements which are for an airport you get an airport.
  I'll ask you questions about things relating to airport design like prevailing winds (to plan runway directions), estimated number of aircraft operations (to determine the number of gates, parking spots, and runways) and the maximum aircraft size I should be prepared for (to determine runway length and taxiway width etc.).
  
  That should give me enough to at least draw a rough sketch of an airport that would serve your needs.
  
  Now if you want a checkin application, ask for that specific subset of airport functionality...
• Analysis
  2004-05-10 13:16:16 tackline
  
  I'd be a pretty dull job where a Software Engineer isn't involved with any requirement definition. Not necessarily directly with customers (I once saw a real live customer in 1998), but at some point the developer has to start interpreting, balancing and creating solutions. The difficult bit about answering such questions is working out what the interviewer wants to hear. Perhaps the questions should be directed towards what the potential employee would be required to do from day to day.
• Java Certification
  2004-05-08 21:53:35 rickcarson
  
  Try getting them to design something like a p2p client or filesharing app.
  
  Its a fairly easy thing, won't freak them out, and its an uncommon solution to a common problem (get data A from point B to point C)
  
  Then you might try asking them questions about their design choices, or ask them to think out loud (can they explain their thought processes).
  
  the way you describe your problem, it sounds more like a trap, or that you are testing requirements gathering, not design.
• Java Certification
  2004-05-07 01:47:45 jwenting
  
  One way is to have the actual future colleagues talk to the candidate to see how well they get on together.
  Being techies they'll start to talk shop sooner rather than later :)
• Java Certification
  2004-05-06 06:35:46 tvaananen
  
  

  I'd take a Java Certified person over any non certified person any day of the week. Even if the non certified person was *claiming* a lot more experience than the certified person.

  
  
  In other words, you let some organization decide who works for you? You could be hiring someone who never programmed one line of Java as a result. Congratulations!
• Java Certification
  2004-05-08 21:39:23 rickcarson
  
  Don't be like that. As I said before I've written questions for interviewing and the guy who answered the most right was a C++ guy who hadn't written Java... but he knew OO.
  
  (And for Java programming I'd take a good OO programmer over a bad Java programmer any day of the week)
  
  Now, lets consider the Java exam.
  
  I distinctly recall there being a few questions where you had to write a line of code. Okay, so statistically speaking they might have been able to do an exam without any of those questions.
  
  What other questions do you get? Well, there's lots of questions where they ask what happens at lines X, Y and Z - so you have to be able to say what kind of output the program is going to have (eg you can debug).
  
  Often, one of the answers is 'this will not compile' - so you have to be able to say whether or not a program will compile just by looking at it!!!
  
  Also the Java exam is deceptively deep. You get asked lots of multi choice questions, where there are multiple answers. Lets say there are four answers, and they tell you 'pick the two which are correct'.. there are six possible ways to answer this correctly, your odds of picking up random 'bonus points' by guessing are pretty bad. With five answers two of which are correct your odds of randomly getting the right combination is one in ten!
  
  Note that you get a big fat 0 if you get the question 'half right' or 'two thirds right'.
  
  Anyway... so lets take your theoretical candidate with certification, but no 'lines of code' written and see what we know:
  (1) that they care about Java enough to get certified (kind of inferred)
  (2) that they can recognise programs which won't compile
  (3) that they know the basic APIs really well
  (3) that they can figure out what the output of a typical Java program is likely to be
  (4) that they have a pretty good understanding of inheritance and class hierarchies and other OOishness
  
  Now I contrast that with some 'code monkey' just pooping out the code and letting the IDE and compiler do most of the work for them... and I don't even know if they can debug or understand OO concerns... I don't even know if they understand the keyword static, or if they just slap it in because the compiler complained at them...
  
  I'll take the certified person please!

• Interviewers need to understand themselves
  2004-05-04 07:02:11 invalidname
  
  

  Much of the article describes how an interviewer can do right by an interviewee, but there's also the issue of how the interviewer can do right by the company doing the hiring. Too often I've seen companies make hiring mistakes by not being honest with themselves about who they are and how they do things.

  For example, let's say your company is deadline-driven and subverts any process to make those dates. If an interviewee comes in and stresses that he or she values process, whether it be waterfall or XP, then that's not going to be a good match, because the company has shown by its actions that it doesn't value process. (Granted, this example shows a fairly dangerous pathology on the employer's part, but that's not the point; if your company behaves this way, you should at least have the objectivity and self-awareness to know as much and hire appropriately)

  Another example: there can be a real difference between Windows-based and U*ix-based Java developers - differences in tools, differences in attitudes towards open-source, differences in valuing WORA. If your shop is heavily weighted to one side or the other, it will become an issue for new hires. Again, know who you are.

  --invalidname

• Interviewers need to understand themselves
  2004-05-08 08:37:14 johnm
  
  

  Well put.

  This is another aspect of fear. Those hiring people seem to believe that they need to lie to prospective employees to convince them to work there.

  IME, the scary thing is that a lot of those types of hiring people don't actually think that they are lying. That is, I often find that they believe that they are just putting a good face on the situation. Partly that seems to be self-delusion.

• Best now ,or good for a long time ?
  2004-05-02 02:47:05 ianmoss
  
  To me I'd hope recruiters would try and establish not only that you are a capable developer / software engineer now, but that you will be in the future as well.
  
  Why are people recruiting ? Most of the time it is because they need more people for their current problem / development. It's fair to ask questions relating to this then. But people are going to have other problems in the future. So general development questions code be asked, and what learning environment they have been in in the past ?
  
  A lot of companies (rightly) want the best - say the top 5%. But obviously not everyone can have the top 5%, so you need an environment where everyone helps each other out. So to me the ability to help others, and communicate, are very important skills to have. How people assertain that in an interview is a tricky one.
  
  I guess in the current economic climate recruiters can as fussy as they want to be on candidates knowing any api's etc.
  
  (Ian is currently looking for work in the North Of England, and has over 5 years commercial Software Engineering experience)
• What does "the best" mean?
  2004-05-07 17:57:33 johnm
  
  

  A lot of companies (rightly) want the best - say the top 5%.

  Hmm... What's your evidence for that?

  Certainly a lot of companies pay lip service to that myth (for a *lot* of reasons) but I find this to be exactly like the fact that people bitch about how crappy the computers that they are using (both hw & sw) are but they don't actually do anything about it. I.e., the actual, revealed preference is quite different from what people say their preferences are.

  
  Note that there's a bit of discussion about this subject over in The Mythical Man-Month bookclub discussion forum.

  
  
• Best now ,or good for a long time ?
  2004-05-06 16:09:18 gvix
  
  Hello,
  
  You make excellent points in your post.
  
  "How people assertain that in an interview is a tricky one"
  
  This is very difficult to assess in a technical interview alone. My guess is that in this case, you have to rely on the references supplied by the interviewee. By making contact with the references, you can ascertain the general nature of the candidate. How does he work in a team? Is he supportive of others? Is he willing to share his knowledge around?
  
  Another question to ask the references is whether the interviewee passed on his knowledge to somebody else in the organization before leaving, and how well he passed it on.
  
  Regards,
  Vikram
• References
  2004-05-08 08:52:59 johnm
  
  

  Alas, nowadays, references for people are basically worthless. Not only is it self-selected (and so must, at least, be heavily discounted) but given the legal exposure (at least in the USA) companies are creating policies to say less about and what is said is more generic and meaningless about ex-employees/-contractors regardless of whether they were stellar, average, retarded, or evil.

• Good tips...
  2004-04-30 06:46:17 psummers8
  
  Although I was hoping for some tips on interviewing rather than giving an interview, I still think you offer some good advice for interviewers and I hope some of them read it.
  
  I think one thing you mention but don't elaborate on is making the candidate comfortable. Unless you are evaluating how someone reacts under duress, making a candidate comfortable will reveal the most about their skills and their personality. By making them more nervous than they already are, you might not be able to get as much out of them and you certainly won't get a good picture of who they actually are as a person. While it may be a technical interview, how this candidate interacts with the rest of the development team is also vitally important.
• Good tips...
  2004-05-06 16:02:02 gvix
  
  Hello,
  
  "While it may be a technical interview, how this candidate interacts with the rest of the development team is also vitally important"
  
  I think this is an excellent point. Do you have any suggestions on how the interviewers should assess this skill?
• Good tips...
  2004-05-07 17:26:52 johnm
  
  

  I was just talking with a friend of mine about this. Basically, this interviewer asked him to write some code. He wrote it correctly but the interviewer told him it was incorrect because, he claimed, a compiler would complain about a particular construct. Of course, this was completely wrong but my friend just sat there and did nothing about it.

  The point is not that, say, I as the interviewer, would be looking for any particular answer but rather I want to see if this person not only knows there stuff but is capable of defending their knowledge and doing so in a civil manner.

• Good tips...
  2004-05-07 17:43:39 johnm
  
  

  For a more active interview, tell the candidate to bring in their laptop and have each interviewer spend part of their time pair programming with the candidate.

  There's a lot of variety in how you can run this so you can vary it depending on what you want to probe deeper for in each candidate.

  Note also that this is a very cheap way to get outside opinions on the various members of your team (if, e.g., you're the manager :-).

• Good tips...
  2004-05-10 00:50:41 jwenting
  
  That requires the candidate to own a laptop.
  Many people don't, at least here. Or if they have one it's owned by their employer...
  
  What would you think if a candidate did bring a laptop but it was a 6 year old clunker?
  Would you immediately discredit the person for not having the latest and greatest (even if unconsciously)?
  Or if they have a brandnew one that's more powerful than anything your own company has, would you hold that against him as vanity maybe (again, possibly unconsciously)?
  
  Candidates should not be required to bring in anything except maybe pen and paper and the invitation letter/email.
  
  YOU provide all the rest.
  If the candidate isn't familiar with your exact tools, don't hold it against him. Good people can learn, but they'll need more than the 10 minutes given to get really proficient with your IDE when they've never used it before so don't discredit them for being a tad slower than you'd be or having to ask where some function is located.
• Good tips...
  2004-05-10 10:34:13 johnm
  
  

  No, there's no requirement for the candidate to own a laptop. Remember that the point of this thread is how to determine if a candidate handles stress. Fore example, if they don't have one, did they communicate that in advance?

  The specific point of having them bring in their own laptop is also so that they are most comfortable with the tools and what not when they are driving so that the tool familiarity issue isn't an issue. Their choice of tools, platform, etc. is also a great talking point as it gets into a lot of facets of how the person thinks such as where they fall in the Emacs vs. vi vs. Eclipse vs. IDEA vs. NetBeans vs. etc. wars. :-)

  Having the candidates bring in their own laptops also makes it easy for them to show off stuff that they've worked on in action rather than just a briefcase full of e.g., code listings.

• Good tips...
  2004-05-05 06:03:36 mcbofh
  
  In my job we must be able to work effectively under massive pressure -- it's just the nature of the job that my group does for our company. If you don't have the technical skills, or at least the aptitude for learning them in a hurry, then we're not interested in talking to you.

  I interviewed a bloke a few months back who thought he had the skills and the aptitude. Sadly, he was unable to get past the first question I asked. Since it was reasonably unlikely that he would know that technical answer, what I was looking for was "I'm sorry, I don't what the answer is, but I'd start looking here, here and here as well as ask person X."

  That's the other part of my team's environment -- we don't have room for somebody who cannot admit that they do not know and do not know where to start looking.

• Good tips...
  2004-05-10 00:54:40 jwenting
  
  That's the other part of my team's environment -- we don't have room for somebody who cannot admit that they do not know and do not know where to start looking.
  
  
  That's the problem with interviews. You're placing the candidate under a lot of pressure and he gets uncertain.
  He doesn't know the answer but thinks you will hold it against him if he admits that so he stalls.
  
  You'd better consider asking what the candidate would do to find information he doesn't have. Where/who would he turn to, etc. (and in general terms, remember he doesn't yet know your company internals).
• Good tips...
  2004-05-06 16:05:15 gvix
  
  Hello,
  
  "In my job we must be able to work effectively under massive pressure"
  
  I think that this statement would describe everyone's job. Can you honestly say that there are jobs out there that do not require people to be able to work effectively under pressure?
  
  "we don't have room for somebody who cannot admit that they do not know and do not know where to start looking"
  
  Yup. Good point. That is one qualification that is required from all candidates. How do you think this should be assessed?
  
  Regards,
  Vikram
• P-p-p-pressure!?!
  2004-05-08 09:01:02 johnm
  
  

  To drill down a wee bit, in different situations and different organizations, different types of pressures predominate. So, part of the question, IMHO, is to understand and articulate what those are so that e.g., hiring can focus on evaluating candidates that thrive in a particular context.

• Welcome to technical interviewing tips discussion!
  2004-04-29 16:22:56 gvix
  
  Hello,
  
  Welcome to the discussion on technical interviewing tips.
  
  How times have changed for us technical developers! I remember sitting in the lobby of a big banks office on Wall Street in early 1998, with a friend of mine, ready to start our first US jobs. My friend and I were over-awed by the occasion and the opportunity. Waiting for the contact person from the bank to arrive downstairs to take us up, we were suddenly approached by a man in a smart suit holding a briefcase. In conspiratorial tones, he enquired if we were developers (We were the only Indians in the building!).
  
  When we replied in the affirmative, he sat down next to us, opened up his briefcase and took out two sheets of paper. Each of these papers was a single page software development contract for another bank, down the street. Everything else was filled in the contract, except for two fields.
  
  The first field was for the name.
  The second field was for the contract rate.
  
  “I will fill in the names and you fill in the price” he says to both of us deadpan.
  
  That was it. No looking at resumes, no psychometric skill testing, no background reference checking and no interviews, let alone a technical interview. We were being offered the deal of a lifetime without as much as a squeak.
  
  While I bemoan the loss of those golden days, when every man and his dog could apparently cut code, I realized that it would not last, and the industry would plateau eventually. Jobs would require narrow focus, and skills would have to be proved.
  
  Technical Interviews are one way in which the skills of would be candidates are proved. This discussion came about because of my recent experiences in technical interviews while trying to get a job, and the accompanying article focuses on one such technical interview that I had. While I regret failing that particular interview and understand that I have shortcomings, I realized that the interview process itself was flawed. I therefore put together a list of items that I thought had gone wrong in the interview. I converted these items to tips for myself when I would conduct interviews myself.
  
  I am very interested to know if you agree/disagree with my tips. I would also love to hear from both sides of the fence, employees and employers, although the distinctions between the two sides are not clear-cut. After all, a technical interview is conducted by people who are developers themselves.
  
  I look forward to your comments
  
  Vikram
• Welcome to technical interviewing tips discussion!
  2004-05-06 13:29:58 nickhomeaccount
  
  I like the advice you provide. I am just a developer and I have not had to interview many people, but I thought I would pass on a piece of interviewing advice I was given. I was told to ask the interviewee general questions about their previous projects (to get them talking kind-of ‘developer-to-developer’). Then listen to the answers. See how much detail they provide. See how much enthusiasm they have for the project. See if they really enjoyed (or were proud) of the project. Anyway, that’s my 2 cents.
• Welcome to technical interviewing tips discussion!
  2004-05-06 15:59:08 gvix
  
  Thanks for your post.
  
  "I was told to ask the interviewee general questions about their previous projects (to get them talking kind-of ‘developer-to-developer’). Then listen to the answers. See how much detail they provide."
  
  This is exactly what I suggest in my tip 5 and I think it is a great way to conduct an interview. It serves two purposes. First, the interviewee gets comfortable talking about his previous projects. Second, it allows you, as an interviewer, to see the depth of the interviewee's knowledge and experience. All in all, a great strategy to understand the skill set of the interviewee.
  
  Regards,
  Vikram