Discussions

News: An Army of Solipsists: Worst. Interview. Ever.

  1. "Worst. Interview. Ever." was posted on the "An Army of Solipsists" blog, detailing a poor fellow in an interview who apparently had padded his resume with buzzwords. Nothing new there, except that it highlights that what many consider "common knowledge" might not be so common. Among the questions the poor interviewee couldn't handle:
    1. Differences between Statement, PreparedStatement, CallableStatement.
    2. Differences between Set and List.
    3. Which JSTL tags are, well, JSTL and not Struts tags.
    4. Decent ways to validate email addresses.
    5. Fast Lane Reader pattern.
    Most of the literati (i.e., knowledgeable readers) would be able to answer all of the questions posed in the interview without much trouble, or at least be able to provide better answers, one hopes, but Your Humble Editor often questions how many people consider themselves among the knowledgeable without justification. What are your answers to the above questions, without cheating by looking them up if you don't know? It'd be an interesting exercise, and extra points (redeemable with karma) to those who answer publicly. BTW, am I the only one who's amused by the title "An Army of Solipsists?" A Solipsist is one who believes that his or her mind is the only thing they know exists; therefore, a member of an army of solipsists would not be convinced that the rest of the army existed at all (which means it wouldn't be much of an army.) Cute. P.P.S: This caught my eye for two reasons. One is that the interviewee is from Indianapolis, which is where your Humble Editor currently resides (and, no, it wasn't me!); the other is that this kind of intellectual divide is more common than we like to think, and I thought it a good opportunity.

    Threaded Messages (48)

  2. I'll bite.
    1. Differences between Statement, PreparedStatement, CallableStatement. Statement is straight sql to the server. PreparedStatement is precompiled on the server CallableStatement is a stored procedure.
    2. Differences between Set and List. Sets can't contain duplicates, Lists can.
    3. Which JSTL tags are, well, JSTL and not Struts tags. c:if, c:choose, c:when --> JSTL logic --> Struts... Aww hell, I'd probably fail this one.
    4. Decent ways to validate email addresses. Use a regular expression, just don't ask me to write it. Without my regexp cheat sheet or google.
    5. Fast Lane Reader pattern. Bypasses your regular database access (entity beans, hibernate or whatever) and uses a jdbc query to read some stuff quickly.
    You get karma whether you are right or wrong, correct? It's also probably a good idea to remove things from your resume if you don't think that you could answer any questions about it. Most interview questions will be based directly off your resume. Don't list VB as a skill if only used it in a 6 month project 5 years ago then be surprised when the interviewer starts asking you a bunch of VB questions.
  3. I had one better once... I don't like to ask more than a handful of technical questions because the best developers I know don't know a ton of things off the top of their heads anyway... the best developers are generalists who can look stuff up quickly and comprehend it quickly... so my interviewing is much more about personality and thought process... do you do any open-source work at all? Do you visit technology sites on a regular basis? What was the first computer you programmed? Have you ever done any Assembly programming (that last one usually tells me whether a candidate is ultimately going to be any good or not, not because they do or don't know Assembly, but I've universally found it to be true that those that have done Assembly at some point in their lives are better developers than those that haven't, for the most part). All that being said, there's of course a certain bar you have to be able to float above regardless, a certain minimum level of technical question you have to be able to give reasonable answers to (tell me the difference between a Map and a List is that one is keyed and one isn't and that's plenty good enough for me, I'm not looking for how their big-O notation compares with regard to retrieval speed or anything like that). So I do what I bet most people do: ask a simple question, then a slightly harder one, then a slightly harder one, and then one or two that even I might be a bit uncomfortable answering in the heat of an interview, and see where the candidate breaks. Pretty much like determing what speed a CPU gets marked as off the line! I also like to throw one or two sort of trick questions in the mix, just to see if they're actually paying attention and can think on their feet a little. I even tend to throw one of those out first because a reasonable candidate will notice it's a trick question, give the right answer a little sheepishly because they aren't sure it's a trick question or not, then I can joke about it and loosen them up a bit, at which point you can more accurately assess them because they aren't getting clobbered by their own nerves after that. Anyway, I started one candidate out with this question: "Where does server-side Javascript run?" And no, that's not a typo... Netscape used to have a server-side Javascript implementation, and we actually had one app that used it. Anyway, the guy fumbles for a few moments, then finally says "I don't know". Ok, fine, I like someone that can simply say I don't know in an interview, I actually prefer that to trying to BS me. Maybe he just got fooled by the trick question I figured. I wouldn't hold that against him *that* much, not as the first question, so I gave him the chance to recover cleanly. "Really? You don't know where **SERVER**-side Javascript executes?" And I emphasized "server" about as much as human vocal capabilities allow for. His reply? "Nope, I have not idea where SERVER-side Javascript executes". And the emphasis was there when he said it, so he clearly heard what I said, and he WASN'T being sarcastic, which would have been good in my opinion! Ok, I'm trying not to laugh at this point, so I pressed on: "Can you maybe reason out where SERVER-SIDE JAVASCRIPT might execute?" Again, very strong emphasize as I said it. But still, I get: "Nope, sorry, I can't figure it out". I'm not kidding, this actually happened, and this is about as verbatim as it gets, I remember it like it was yesterday. Needless to say, I asked a few more questions, just silly ones not on my list that I made up at that point, just because I was having fun with him at that point. I don't remember many of the specific questions after that, but it was stuff like "The primary sections of an HTML document are the head and the ___"? "What's the difference between the java command and the javac command?" (he was interviewing as a primarily Java-based web developer by the way). "Is HTTP stateful or stateless?" He couldn't answer any of them satisfactorily, but I didn't expect him to after that first one! I almost wish we had hired him anyway, I get the feeling our days would have been filled with laughter from that point on!


  4. "Where does server-side Javascript run?"

    And no, that's not a typo... Netscape used to have a server-side Javascript implementation, and we actually had one app that used it.

    Anyway, the guy fumbles for a few moments, then finally says "I don't know".

    Ok, fine, I like someone that can simply say I don't know in an interview, I actually prefer that to trying to BS me. Maybe he just got fooled by the trick question I figured. I wouldn't hold that against him *that* much, not as the first question, so I gave him the chance to recover cleanly.

    "Really? You don't know where **SERVER**-side Javascript executes?"

    And I emphasized "server" about as much as human vocal capabilities allow for. His reply?

    "Nope, I have not idea where SERVER-side Javascript executes".

    The correct answer is: server-side Javascript runs in Rhino (JavaScript for Java)
  5. Re: Not even close to the worst...[ Go to top ]

    ... the best developers are generalists who can look stuff up quickly and comprehend it quickly ...
    Agree 100% that determining this quality in the candidate should be the primary focus of any technical interview. Asking candidates a "long" series of "short" questions (each w/ exclusively "right" or "wrong" binary outcomes) is a poor process for determining a candidate's technical quality and productivity potential. Though I agree that anything listed on their resume should be convincingly understood by the candidate, it is important that all questions be formed so that the interview does not become a technical "trivia" challenge. I.e. ask questions like "please describe your understanding of (technology concept/problem X) and, should you not have immediate recall nor familiarity with (technology concept/problem X), then how would you approach acquiring the technical competency to answer this question?"
  6. I would like to answer to
    what factors would you use to decide whether to create a >RuntimeException or an Exception?
    I would always write a subclass of RuntimeException! Do I pass the test?
  7. Based on the questions asked, I probably wouldn't want to work for the employer. Here's what we can assume about them: From question 1, we learn they are using direct JDBC access. Not understanding the value of ORM is a minus. But worse, from the interest in Callable statement, we learn that the employer uses stored procedures and invokes them from java. This indicates the employer doesn't understand the value of loose coupling between tiers, and may have pushed business logic into the database, which makes changing it an integration problem. Yuck. From question 3, we learn that the employer uses Struts 1. Given that much better MVC alternatives have existed for several years, this tells me that the project is either a) maintaining a legacy app or b) has architects who don't follow the major trends in java land, or c) both. There is nothing wrong with a), but better candidates these days have experience with one or more of JSF, Spring MVC, Webwork/Struts 2, or Tapestry and aren't looking for Struts 1 jobs. Most people who have worked with one of these are going to cringe at the thought of going back to Struts 1. Aware IT shops will recognize this and start doing new development in one of these technologies and hire accordingly. Here's some news for you: if all you are doing is backfilling maintainers of a legacy app, you don't need or deserve the better candidates on the market. You probably should be hiring less experienced (and cheaper) developers and expecting to train them with what they need to know. You probably won't have much luck getting people who really know what they are doing, because they are wanting to work on things like Spring/Hibernate, SOA, EJB3/JEE5, SpringMVC/Struts2/JSF, etc... . This isn't 2002 anymore: experienced candidates have many options. The scary question is question 5. Frankly, I'd never heard of this pattern and after looking at it, I know why. The Fast Lane Reader pattern basically says "use JDBC directly to skip by your entity EJBs for reads". The question indicates the shop is one that didn't get the message about entity beans. Let me help: Entity Beans Suck - don't use them. The hint should have been that we have a pattern that tells us not to use them half the time. I can forgive shops who bought in to the big mistake that was EJB 2. It had a lot a marketing and the java community as a whole had a collective dellusion (which has since been remedied) that the approach of EJB 2 was a good one. However, anybody with a brain should have quickly figured out the viable part of EJB 2 was only stateless session beans and message beans. Again, any candidates who have a clue aren't going to work for projects that don't.
  8. Didn't you notice that interviewer just walks through areas of expertise from candidate's resume? And I believe there is nothing wrong with asking employer the questions of interest. Most times direct answers are much better than unjustified assumptions and false conclusions.
  9. OK, I didn't RTFA. Bad me. I just read it and now I feel silly -- they asked these questions because the candidate had the topics on his resume and they were searching for something, anything, of value in his skills. The blurb about the article gave me the impression these were questions they might ask any candidate.
  10. OK, let's be the first one, so that anyone can make fun of me instead of answering: - a PreparedStatement is precompiled on the database and can have input parameters, a CallableStatement is a PreparedStatement that can also have output parameters - a List is ordered (always keeps the items in the order they were inserted), a Set is not - I don't know anything about JSTL, and it's not written in my resume, I don't have to answer this one :) - a good regex should be fine - AFAIK, the fast lane reader pattern consists in using a Data Access Object to send back read-only forward-only tabular data instead of using an EJB, for perfomance purposes I agree the interview was bad, I hope I was better!
  11. Apparently TSS can run an online interviewing service =).
  12. This should be a lesson[ Go to top ]

    Don't fill your resume with technologies you don't really know just because once you read something about them, because someone will ask you questions about them.
  13. Re: This should be a lesson[ Go to top ]

    Funny, I tend to under represent things on mine. An astute resume reader might notice I have a couple of projects done in C++, but I don't list C++ on my resume as a language I know. I simply don't feel qualified in it anymore, despite having successful projects in it.
  14. Re: This should be a lesson[ Go to top ]

    The other side of the coin is that if you only have stuff you are playing with right now in your CV, your changes to get even invited to an interview might be low. You may lose the job or bidding just because of too simple CV. I will add everything I know I can handle with little training in my CV. If an interviewer asks me about something I'm not sure... Well, I just answer "I don't remember, but if you have a job with this technology for me next Monday, I will refresh my memory during weekend.". Of course, you will have to be sure that you have enough elementary knowledge to promise this. I've had enough tricky consultant jobs to know my abilities. But the point is that asking very detailed questions does not tell much about applicant's groundings, ability to learn and motivation (which is more important than detailed knowledge).
  15. I agree perfectly.
  16. Re: This should be a lesson[ Go to top ]

    Funny, I tend to under represent things on mine.

    An astute resume reader might notice I have a couple of projects done in C++, but I don't list C++ on my resume as a language I know. I simply don't feel qualified in it anymore, despite having successful projects in it.
    Why? C++ deep knowledge was in your brain, ok the time makes this knowledge nebulous, but it was yours, a quick review can make you a C++ master again. C++ old knowledge shows you a have a solid background very useful for Java too, solider than the typical Java-is-my-first-language guy.
  17. Re: This should be a lesson[ Go to top ]

    Absolutely. I phone interviewed one individual who had "client-server and web-application" experience on his resume. After a few questions of the compare/contrast variety, I asked "Describe the client-server architecture style". Blank stare. After a few more questions about the other jobs on the resume I came to the conclusion that this wasn't his resume. So, lesson 2: Don't put your name on someone else's resume and attempt to pass it off as your own. I felt like a bouncer looking at a 17 yr old with a fake id of someone 24.
  18. Re: This should be a lesson[ Go to top ]

    Non hardcore technical questions such as what kind of projects have you worked in at JP Morgan or American Airlines, or what did you do in the project sometimes expose a candidate quicker than technical questions (especially when someone else's resume being used by a candidate). It also demonstrate candidates communication skills, and personality to some extent. But more often candidates tend to put more tech buzz words on their resume than actully used by the projects they were in.
  19. I'm not sure what's worse; the interview or the....................fully................... justified....................text.................. that.....................most................. adults......................stopped............... using........................in...................1986. Yeah, it was neat-o when Scripsit first came out and I could right and left justify on my 9 pin Epson dot-matrix, but not so much after that month. Why do blogs continue to insist on using it? Especially technical blogs, where due to word length (often code withHorriblyOverlyLongFunctionAndMethodNames()) make the rest of the line stretch out ridiculously? (Not to mention the inability of modern browsers to kern correctly; something that has been working pretty well for the last few hundred years...) Ok, I need more coffee. Or less. Sorry about that. [Edited to break up that freakin' huge line. Come on, man, don't do that. Ouch.]
  20. I had to do a number of interviews a few years back an almost none of the people that were brought in could explain what the differences between different collections were. That was my easiest question. I even had one guy who brought in a stack of yellowed papers and when I asked him a question, he'd shuffle through them and point to one of the words (i.e. Collection) in some Java code. Actually, the guy might have had a photographic memory but I'm pretty sure he had never written any code. He told my coworker that he hadn't worked with Java 1.3 because it was too expensive.
  21. I remember conducting a phone interview where in between my questions I could hear the guy typing on his keyboard to look up the answers.
  22. Decent ways to validate email addresses.
    What a pitfall question. Validate the format or validate that it is real? Validating format may be the target question, and if so, it's a horrible one because the popular answer is so wrong. 1) There are two key parts to an email address. The part before and the part after the @. The part after the @ can be anything, but to be reasonable, it is most likely part of the internet where hosts are well known and public. The prior part, can be near anything w/ the exception of a few odd rules, such as period placement. In my internal network, if I wish to mail something across my SMTP server to a machine across the house out of laziness, I have used (Some machines will respect 0 as 127.0.0.1 by default). 2) The regexp is horridly long. Easiest you can do w/o porting the regexp and testing it properly is checking only for an @ symbol.
  23. Email addresses[ Go to top ]

    Decent ways to validate email addresses.


    What a pitfall question. Validate the format or validate that it is real? Validating format may be the target question, and if so, it's a horrible one because the popular answer is so wrong.

    1) There are two key parts to an email address. The part before and the part after the @. The part after the @ can be anything, but to be reasonable, it is most likely part of the internet where hosts are well known and public. The prior part, can be near anything w/ the exception of a few odd rules, such as period placement.

    In my internal network, if I wish to mail something across my SMTP server to a machine across the house out of laziness, I have used (Some machines will respect 0 as 127.0.0.1 by default).

    2) The regexp is horridly long.

    Easiest you can do w/o porting the regexp and testing it properly is checking only for an @ symbol.
    If I remember correct there was a class for EMail addresses in the Java Mail API. I guess that one is the only correct answer. (I have seen the correct regexp once in a book and it took more than one damn page)
  24. Regex[ Go to top ]

    Im a fan of this one for a quick validation ([a-zA-Z0-9_\\+\\-\\.]+)@((\\[[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.)|(([a-zA-Z0-9\\-]+\\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(
    ]?) Not toooo long and it seems to do the trick.
  25. Re: Email addresses[ Go to top ]

    Remind me why it's important to validate email addresses.
  26. Re: Email addresses[ Go to top ]

    Remind me why it's important to validate email addresses.
    So you can answer questions in an interview.
  27. Well[ Go to top ]

    I'd not be unfair, either. I'm currently working as a J2EE architect and project manager. I never carry around developer-specific know-how until I have to use it. I look up much of the details I need in google. I have learned a lot about patterns, but would not be able to quote them all. Most of the patterns are just common sense. I have great knowledge of distributed systems and distributed transaction handling. I know how to segment and partition databases so to boost performance. But still, to know about Hibernate's 2nd level cache best strategies, I have to look up documentation. It will cost me an hour, yes. But then, I can do much more with the information contained in this documentation than anyone who is new to distributed systems. I have been working on virtual shared memories or ORBs since 1996. I have seen the birth of EJBs right on from their first draft, and even suggested the implementation of the Timer Service in 2001, when MDBs existed only as a draft. To satisfy some employers and to avoid carrying around all the details I never care about in my intuitive decision making, I certified for SCEA. I would never certify as a SCJD. This said, I would never try to get hired for a developer position explicitly. Still, many employers think of an architect as a super-developer, who knows every corner of Java. Well, I don't - and I'm glad I don't. If I did, I wouldn't be a good architect. I concentrate on the essentials and on concepts. I dont care where a particular method in Java can be found, or which package. I google, in case I need it. In conclusion, I want to say that it heavily depends on what the candidate applied for. Was it a developer position ? Then yes, you are right - he's the wrong man. Is it a project manager, or an architect position ? Then yes, he could have been the right man. On a scale of 0-10, 10 being the best, I give myself a 4 in knowledge of Java. Regards, Jay
  28. Re: Well[ Go to top ]

    I'd not be unfair, either.

    I'm currently working as a J2EE architect and project manager. I never carry around developer-specific know-how until I have to use it. I look up much of the details I need in google. I have learned a lot about patterns, but would not be able to quote them all. Most of the patterns are just common sense.

    I have great knowledge of distributed systems and distributed transaction handling. I know how to segment and partition databases so to boost performance. But still, to know about Hibernate's 2nd level cache best strategies, I have to look up documentation. It will cost me an hour, yes. But then, I can do much more with the information contained in this documentation than anyone who is new to distributed systems. I have been working on virtual shared memories or ORBs since 1996. I have seen the birth of EJBs right on from their first draft, and even suggested the implementation of the Timer Service in 2001, when MDBs existed only as a draft. To satisfy some employers and to avoid carrying around all the details I never care about in my intuitive decision making, I certified for SCEA. I would never certify as a SCJD.

    This said, I would never try to get hired for a developer position explicitly. Still, many employers think of an architect as a super-developer, who knows every corner of Java. Well, I don't - and I'm glad I don't. If I did, I wouldn't be a good architect. I concentrate on the essentials and on concepts. I dont care where a particular method in Java can be found, or which package. I google, in case I need it.

    In conclusion, I want to say that it heavily depends on what the candidate applied for. Was it a developer position ? Then yes, you are right - he's the wrong man. Is it a project manager, or an architect position ? Then yes, he could have been the right man. On a scale of 0-10, 10 being the best, I give myself a 4 in knowledge of Java.

    Regards,

    Jay
    I agree for the most part... Any decent Java developer (and an architect, working with Java, should at least be a decent Java developer) should be able to supply answers that, though maybe not perfect, would at least let you know that they knew of the topic, even if they hadn't worked with them for a while. There are some interviewers who put way too much stock in someone not able to answer a ton of technical questions with complete accuracy. I think that's very wrong, and dangerous. You might end up mistaking someone with a photographic memory for someone with some common sense and the ability to think strategically. Unless you work with a limited set of technologies, there's just no way to keep even a fraction of all that information in your head. As previous poster said, there's google for that. I'd be more interested in hearing about previous projects and how they solved something than testing their memory for syntax. Having said all that, if your going to put JSTL on your resume...you'd better review it the night before. Mike
  29. Re: Well[ Go to top ]

    Any decent Java developer (and an architect, working with Java, should at least be a decent Java developer) should be able to supply answers that, though maybe not perfect, would at least let you know that they knew of the topic, even if they hadn't worked with them for a while. There are some interviewers who put way too much stock in someone not able to answer a ton of technical questions with complete accuracy. I think that's very wrong, and dangerous.
    I agree. But when you are hiring a Java developer, questions about the the standard java.util.Collections are good weeder questions. It's pretty hard to have any real experience developing in Java and not be familiar with these classes. If you've developed in a Java a great deal and don't know them really well, there's something wrong there. But these are really only going to allow you to gauge the developers experience in Java. They don't tell you anything about problem solving skills, which is really the most important skill for a developer to have, IMO.
  30. Where are my points?[ Go to top ]

    I knew all of these less #5, I had never heard of that title nor seen it on any java sites. I asked here amongst my fellow engineers and none of them had heard it either. A couple looked it up and we found that we all had used the pattern and were familiar with the process. I think the name should be refactored. :)
  31. Re: Where are my points?[ Go to top ]

    I knew all of these less #5, I had never heard of that title nor seen it on any java sites. I asked here amongst my fellow engineers and none of them had heard it either. A couple looked it up and we found that we all had used the pattern and were familiar with the process. I think the name should be refactored. :)
    This is an old J2EE Core Pattern. I keep that book in my basement. I believe the only reason the interviewer asked about it is because the interviewee mentioned it explicitly on his resume.
  32. It might also be wise for people interviewing candidates to *UPDATE* their questions. I was recently interviewed by a large payroll support firm here in SoCal and the question the hiring manager had was 1) What's the difference between an Array and a Vector? I told him him that Vectors can grow dynamically while Array's can't. He wasn't satisfied with my answer and stated I was missing something else. He wanted me to say that arrays can be typed while vectors can't (which I countered with, you must still be using JDK 1.4.X or below on new projects - and I also told him in that context, arrays can store primitives). The morale of the story - avoid development shops that only use IBM WebSphere (WebSphere Stigma?).
  33. The morale of the story - avoid development shops that only use IBM WebSphere (WebSphere Stigma?).
    W-SAD (because that's how it makes you feel) is now called RAD for Rational Application Developer. This new application combines the crappiness of WSAD with the crappiness of Rational.
  34. You, sir, are my hero for speaking the truth! We have unfortunately gotten into bed here with Websphere/RAD full-bore, so I have little choice but to use RAD for one major project (I've avoided it with others by not using anything Websphere-specific, at least nothing I can't hack by hand) I hear RAD 7 is better, but I'll believe that when I see it! RAD 6 is the worst piece of donkey dung I've ever seen in my life... I can't belive how much time I spend fighting the damned thing... fresh checkout won't build properly because RAD decided to rewrite a build path (it's smarter than the average developer, don'tcha know?!?)... app won't deploy because the EJB deploy didn't regen things properly because there's web services tied in (why the WS effects the EJB it was gen'd from is beyond me)... it's slower than my grandmother on a unicycle (even on my Core DUO 2.4 w/3Gb RAM in a much-optimized XP)... if you have a large JSP open (which arguably you shouldn't have in the first place, but I digress) and switch to another open file then back, the editor is all blank... argh, I could go on for days... and that's not even considering Websphere itself, which is only marginally better IMO. On some days I feel like doing as that Chinese CEO did a few days back, it doesn't even take a major product recall that threatend childrens' lives, all it takes is a few hours with RAD and Websphere. You know, they Satan and his spawn are walking the Earth today, but I'm not sure they're in the form everyone expected. (Ok, that last part might have been a TAD too far, but if you've spent quality time with RAD, you''d know) (hey, are dashes in tag names valid? I'm not sure!)
  35. Yeah absolutely well said....wonder how they developed a software which is about 1 GB during installation and has about 1.5 GB of updates which takes over a day to get downloaded and installed. wonder was this stuff created to make our life easier or tougher....sometimes feel like banning all IBM products (except rational rose) if i have the power to do that.. and IBM DB2...well i wont comment on it lest i lose my sanity!
  36. RAD 6 is the worst piece of donkey dung I've ever seen in my life... I can't belive how much time I spend fighting the damned thing... fresh checkout won't build properly because RAD decided to rewrite a build path (it's smarter than the average developer, don'tcha know?!?)... app won't deploy because the EJB deploy didn't regen things properly because there's web services tied in (why the WS effects the EJB it was gen'd from is beyond me)... it's slower than my grandmother on a unicycle (even on my Core DUO 2.4 w/3Gb RAM in a much-optimized XP)... if you have a large JSP open (which arguably you shouldn't have in the first place, but I digress) and switch to another open file then back, the editor is all blank.
    lol - you should try using it for WebSphere Portal Development :) We called that project hell-year, we became utterly frustrated with the RAD 6 bugs. Debugging anything made our 3GHZ machines w/ 2.5 gigs of RAM run to a crawl. Friends don't let friends use RAD, or WebSphere (unless they like getting stuck in the past).
  37. The morale of the story - avoid development shops that only use IBM WebSphere (WebSphere Stigma?).
    The sad truth is that you will have to avoid a lot of shops.
  38. The sad truth is that you will have to avoid a lot of shops.
    Might be so, but some development shops have started to take a look at Spring / Hibernate and Seam. JBOSS seems to be picking up steam in regards to the techs listed. The problem with WebSphere only shops is the fact that good developers usually end up leaving after a while (developer attrition). Let's face the fact that developers in general like working with newer technology. If you wanted to use JEE5 on a newer project, it will be close to impossible to use it in such a shop. You'll have to wait for IBM to release WebSphere 7 (a year from now?), then wait another two years for the Infrastructure team to update the servers to said version (another two years). A majority of the WebSphere shops I talked to are still running WebSphere 5.1.1.X. You'll be lucky to find a shop running WebSphere 6.1 configured w/ JDK 1.5 in production.
  39. A majority of the WebSphere shops I talked to are still running WebSphere 5.1.1.X. You'll be lucky to find a shop running WebSphere 6.1 configured w/ JDK 1.5 in production.
    Perhaps you talked to shops that are running WAS 5.1.1.x, but the bulk of WAS production customers at this point are running either 6.0.2.x or 6.1.0.x. I can empathize that developers in general like working with newer technology, but large IT shops (in general) don't move to the latest and greatest as fast as developers (in general) might like. That's life. This does not mean that large IT shops don't have lots of very sharp developers; I can vouch that they do. At the same time, there are lots of smaller shops and consultancies that also have very sharp developers. Saying "large IT shops lose their sharp developers because large shops don't move to the latest and greatest" is an oversimplification of why people work where they do. I find it humorous how an article on what questions are appropriate to ask interviewees morphed into a discussion of WebSphere service levels. Randy (IBM)
  40. A majority of the WebSphere shops I talked to are still running WebSphere 5.1.1.X. You'll be lucky to find a shop running WebSphere 6.1 configured w/ JDK 1.5 in production.
    Perhaps you talked to shops that are running WAS 5.1.1.x, but the bulk of WAS production customers at this point are running either 6.0.2.x or 6.1.0.x.
    Are there any numbers?
  41. levels.

    Randy (IBM)
    The thing is, I don't work for IBM nor it's competitors :) In regards to the bulk of the people running 6.1.X might be IBM itself. Large IT shops in general cannot move to the latest and greatest because they use IBM WebSphere software - it's as simple as that. Removing that infrastructure impediment will allow for a more agile IT shop, and the developers will surely be happier. In regards to interview questions, I generally find that people using the WebSphere stack do not know how to use Hibernate, Spring, JEE5, and etc.
  42. I've also been in the situation where a guy answered everything pretty well. Sounded smart enough but then when it came to actual coding, everything went out the window. Couldn't write a line of code to save his butt. Needless to say, he'll probably be moved in to management somewhere...
  43. Fast Lane Reader pattern[ Go to top ]

    I guess 'Fast Lane Reader pattern' sounds a lot cooler to people than 'using JDBC directly', which even has a word less :)
  44. Validating email[ Go to top ]

    "Decent ways to validate email addresses."
    Send an email? :)
  45. Hi, I liked the interview. Very funny. But please, bring that into context. Most (if not all) Consultant Agencies will sell you a correct or junior java developer as intermediate or senior developer. His resume wasn't even written by him. As a "senior" something I something do technical interviews. And usually, I ask the developer which "buzzword" is from him, and which one was put on his resume against its will: because I will ask questions on all of theses. Usually, the interview is faster and less embarrassing for both of us. You can even miss someone good because he didn't know nothing about Hibernate, JSTL or Spring, but still is (or could be) a valid java programmer in some other way. regards,
  46. Somewhat overrated[ Go to top ]

    Since I did Java almost from day one I think that it does not really matter if someone knows the difference between a set and a list off his head. The important thing is to know what these are in general (collection classes) and where to look them up. Validation of an email address? That is the kind of question where I would walk out on the interviewer. The only reasonable thing you can do is check whether there is a "." in it. Everything else (well almost) is pretty much context dependent. Fast Lane Reader? A bizarre "pattern" from the EJB 2.1 persistence? Anyway, if you want the person to have a good understanding of the language require the goddamn language certification! Saves you a lot of interview time. Also, I make a habit of basing my interviews on my requirements not on the resume of the candidate.
  47. Re: Somewhat overrated[ Go to top ]

    Since I did Java almost from day one I think that it does not really matter if someone knows the difference between a set and a list off his head.
    It's not crucial to know this off the top of your head for development but I can't imagine how an experienced developer wouldn't know this. If they don't, they probably have never used a set or don't really understand interfaces.
    Anyway, if you want the person to have a good understanding of the language require the goddamn language certification!
    This is nonsense. All of the candidates I have interviewed with a developer certificate have been the bottom of the barrel. Certifications do not tell you anything about a developers experience and they definitely don't correspond to their ability to solve problems. From what I can tell, most people who go out of their way to get certified do so because they have limited skills or experience. I don't even want one because I don't want to work at a place dumb enough to considerer a criteria for hiring. Moreover, hiring based on what technologies the developer has worked with before is a terrible hiring strategy.
  48. Worst Interviewer Ever ?[ Go to top ]

    I've been programming professionally for 13 years, I hold five sun certs, still forgotten half the API's though. These questions say more about the interviewer than the candidate. Statement types - As people have said, so what, what does this prove exactly ? This knowledge can be picked up in 2 minutes. I'd rather know if they understand architecture, design and genral DB concepts like third normal form. Differences between Set and List - Again so what, this can be picked up in two minutes, why not ask them an open question like what container classes/datastructures and algorithms they know about and how they work ? Struts - Legacy technology use something else, just ask if they know a few decent patterns MVC etc, who cares what tags they can remeber ? JSTL, I've used it again can be picked up in 2 minutes, who cares what the tags look like ? Email validation - As has been pointed out a pretty bad question, why not ask about if they know what a lexer is ? Do they know what a FSM is ? Can they write a parser ? Fast Lane Reader - Biggest load of crap I ever almost swallowed, Core J2EE patterns ? my a$$ ! Ask them if they've read GoF. I have many technologies and libraries on my CV, simply because I have used them in the past on real world projects. Some of them I may have been an expert on in the past, does it mean I'm gonna ace a trick question in an interview under pressure on a tech I used 4 years ago ? Interviewers and Agents have a responsibility to get the best of of the candidate in an interview, not to bludgeon them with dodgy questions ! If both sides don't manage this then they have BOTH failed !
  49. Re: Worst Interviewer Ever ?[ Go to top ]

    Fast Lane Reader - Biggest load of crap I ever almost swallowed, Core J2EE patterns ? my a$$ ! Ask them if they've read GoF
    Hey, this is not one of the Core J2EE patterns, even though the core patterns themselves are crap. It is a Java BluePrints pattern. Just to keep the record straight, since quite a few here said it is a core pattern.