Well here they are - a few more of my favorite questions and again "No" I am not going to give the answers (that's what Google is for!)
J2SE
1) Does every try{} block have to be followed by a catch{} block?
2) Which do you prefer - checked or unchecked exceptions? Why?
3) When you are reading code looking for potential memory leaks, what kinds of things should you look for?
4) Say I have a JavaBean Class that has 10 fields and I have two instances A and B. Write some code to copy all the values from A to B? How do I make sure that A and B are the same?
5) Name some ways in which two Java threads (running on the same VM) can communicate
JDBC
1) In the Statement class, the executeUpdate() method returns an int. What does that int represent?
2) What is a SQLWarning, how is it different from a SQLException?
J2EE
1) True or false, the J2EE spec allows you to create your own Threads within the container? And in practice?
2) What files are needed to define an EJB (1.1 to 2.1)? How about in EJB 3.0?
3) In JMS messaging - what is the difference between "Point to Point" and "Publish Subscribe"?
4) What are the different ways of storing and using a user session in J2EE? Indicate the pros and cons of each method?
Struts Basics
1) Name the XML files needed for Struts to work?
2) What kinds of things go into the Web.xml for a Struts-application?
3) What are the different ways in which Struts support exception handling? Which would you choose and why?
10 comments:
I dislike both your JDBC questions (what about Hibernate?) - you have to be jdbc addict to know that :P
Also first j2ee question is ... i have never read j2ee spec and hopefull never will :P
These questions seem a little too technology specific. You may hire very similar people of the back of them. Developers currently working with the technologies you're quizzing them on in that style will find the questions easier than those using alternatives. The specific nature of the questions may also put off good developers who prefer other technologies (with Struts and EJB that wouldn't be hard ;-) ). I'm sure you've more open ended questions in your batch, asking them and some higher level ones too (why would you choose Hibernate over EJB, when would you use Spring? what role do you see for dynamic JVM languages? etc) may result in the hiring of more diverse candidates.
This is what sucks about questions on a job interview. Contrary to the previous comment, I think the jdbc questions are pretty easy. However, I have no clue about the answers to the struts questions. Though the previous posters experiences are different than mine, I'm sure we are both good developers and we could pick up struts and jdbc with minimal effort. However we would both probably never get the opportunity to do so if we were asked these questions on an interview. I'm not saying that they are bad questions. I am just wondering/hoping that there is a better way to screen candidates.
A better JDBC question may be, "What are some ways you've managed to keep SQL out of your business domain logic?"
On asking Struts questions - yeah I only ask them if a person claims they've used Struts quite a bit.
But JDBC is a must have (for us) as we don't have Hibernate/iBatis/Toplink in house (although I would love to)
Best,
-Frank
John,
As I said in a prior comment I won't ask Struts/EJB questions if they don't have any experience there - it would be nice but it's not a "must have" for our team.
JDBC on the other hand is a must.
I do like your "higher level" questions - but often don't get to ask them due to time restrictions.
-Frank
The java questions are neat. I am not very excited about the j2ee questions.
memory leaks are a runtime problem which means you find them by measuring activity in the runtime. Searching the source code should only happen after you've identified the source of the memory leak.
Kind regards,
Kirk
http://www.javaperformancetuning.com
After reading your blog, it's extremely apparent your databased biased. I started my programming career in Oracle, was a DBA for a long time before I switched to Java back @ 1.2 and haven't looked back since.
And after all this, I can definitely say that you are way way way over emphasizing JDBC.
After reading a bit more though of your blog; I can see why you place emphasis on this since your java database tier is hand rolled. But perhaps you should put a disclaimer saying 'this is what to ask when your database layer is handrolled'.
I've written + collaborated on quite a few higher level jdbc frameworks in my day, including code generated, and I don't entirely understand your insistence on such strong JDBC knowledge. If your hand rolled framework was up to scratch, your jdbc calls etc. should all be insulated from most of your api users and it shouldn't have to be something they should be overly concerned w/ as opposed to actually solving business problems.
Hi Kirk,
Thanks for your comment - I agree - first step is analysis.
Love your site and mailing list - always a pleasure to read.
Thanks!
-Frank
Post a Comment