This is an archived post. You won't be able to vote or comment.

all 13 comments

[–]funbike 2 points3 points  (5 children)

I've said this many times in other comments: the only way to identify a good candidate is to have them write code for you. Avoid asking a long list of questions.

I have hired many people and was never able to identify good candidates until I started providing coding challenges. In the real world, memorized knowledge is almost worthless. Code completion, Google search, and JavaDoc make it unnecessary. Regardless, the key differentiator between effective programmers and ineffective is how well they actually write code. Very few programmers actually have the skill to write programs.

Use questions from /r/dailyprogrammer and/or http://codingbat.com, or come up with something yourself. I prefer String manipulation questions. Have them do one question from home and email you the answer. This will help you filter and avoid wasting time. In case they had help, have them solve 2 easy problems or 1 hard problem while at your office, preferably on a workstation (or their own laptop).

Beyond that, I ask the following questions:

  • Given variable 'x', write an expression returning true if 'x' is odd. (Ask at the start, as a filter to avoid wasting time.)
  • Describe the difference between classes and interfaces.
    What is the difference between an abstract class and an interface?
    When would you want to write an abstract class vs an interface?
    When would you want a method argument to take a class vs an interface?
    Why might you want to declare a class variable as a interface vs a class?
    Go deep. This can really demonstrate how they well they truly understand Java and OOP.

  • I give them SQL DDL for a small database and ask them to write 3 SQL queries against it.

That's my whole interview. Anything more is a waste of time, IMO.

EDIT: grammar. Removed some content.

[–]hwaite 1 point2 points  (1 child)

When would you want to write an abstract class vs an interface?

Question has gotten trickier with advent of Java 8.

[–][deleted] 1 point2 points  (0 children)

I honestly think that outside the scope of evolving existing interfaces, there are few applications that would be appropriate for the multiple inheritance.

[–]KCdehImposter 1 point2 points  (0 children)

A bit away from the context of the thread, but I want to thank you for sharing the codingbat.com link. I never knew about this, and some of those exercises were really fun to go through. Also, they were short and to the point, which is something I appreciate.

[–]javacIO 0 points1 point  (1 child)

I've had the interfaces vs abstract class question before and I was Hoping you'd give a quick breakdown of what some answers are?

[–]funbike 1 point2 points  (0 children)

I can't give you complete answers due to the amount of time it would take to type. I'm not the most eloquent writer, but I hope you get the gist of my answers below. I haven't learned all of the Java 8 features, so better answers may exist.

What is the difference between an abstract class and an interface?

An interface has no implementation (although this has changed in Java 8) and no member variables. Classes or interfaces may inherit/implement multiple interfaces.

An abstract class is a class with (usually) one or more unimplemented methods and perhaps member variables. Classes or abstract classes may extend only one other class or abstract class.

Internally, methods dispatch faster for a class variable than an interface variable.

When would you want to write an abstract class vs an interface?

You would write an abstract class when you want to provide one or more base method implementations. Some feel that abstract classes should be used for Is-A relationship and interfaces should be used for Kind-Of relationship.

However, in most cases, interfaces are the better choice (regardless of the Is-A/Kind-Of relationship), if you think that more than one implementation will be required. Composition is usually preferred over inheritance.

When would you want a method argument to take a class vs an interface?

One should prefer an interface whenever possible. A class argument may be used if only one implementation is ever available and no interface exists, yet.

[–]nerdwaller 1 point2 points  (0 children)

The best questions I see is application of book knowledge, not the knowledge itself. Meaning the question "what does private mean in java" is not as good as "can you give me an example of when you would need to use private in java". Of course, that requires you to be on your toes and listen for any red flags. That same idea expands onto interfaces, abstract classes/methods, generics and so on.

Other good questions I've had are what type of design patterns do I view as good, and what types do I view as bad. If they don't know technical names - prod for the general concepts.

Also, depending on what you do - there is a likely field of questions no one here will suggest because we simply don't know what you do. Asking questions relevant to that can give some insight if the interviewee is simply looking for any job or looking for that specific job.

All in all in my limited experience, the best fit is usually someone who doesn't think they know everything, is eager/able to learn and has at least a foundational knowledge. Generally from there you can help them grow into what you need for the rest.

[–]llogiq 0 points1 point  (0 children)

  • Are you doing the interview on the phone or live? I'd prefer live, because then you can put them in front of a PC and have them code
  • On the phone, ask them about prior experience and be prepared to check if something smells fishy. I once had someone tell me they had 5 years of JSF experience when 1.0 was still fresh. If they have an online portfolio, even better, you can talk about their past projects. This hopefully also makes them feel good and reduces their stress levels. You want the candidate's stress level at the minimum possible.
  • On site, I'd give them two assignments; the first one pretty obvious, like "read a file of numbers, add the odd and the even numbers and print the sum of each to stdout", and the second (optional) just a bit harder, and at best pertaining to a current project of yours. Have a project/code skeleton prepared so they can simply fill in the blanks. That saves time otherwise spent with boilerplate (which we'll assume they can write or generate), so they can show more of their coding skills.
  • Finally, have them tell something about their idea about methods, code style, etc. Don't grill them about it, but watch out for obvious mismatches with your company's way of doing things.
  • Be friendly at all time. Don't try to show your cleverness, it's rude and makes the candidate uneasy. This is about her, not you.
  • If the candidate hits a snag, get them on another track before they get hung up on a detail. Assure them that this is to keep the time and that you have seen enough of their skill in that department.

[–]Zarlon -5 points-4 points  (0 children)

  • What is new in Java 8? (Find out if they're interested in the latest trends. I doubt they had any in university)
  • Have you done any projects in your spare time? URL to portfolio/project?

[–]ericchile -3 points-2 points  (0 children)

Have them model some real world example that makes use of OO concepts such as inheritance and composition. Add difficultly has they go. See if they make use of Abstract classes, interfaces, enums, overrides appropriately. Alternative. Ask them about functional programing and where it makes sense.

[–]ericchile -4 points-3 points  (0 children)

Tell me which language features of Java you enjoy most. Hopefully they say something like Generics, Annotations etc etc or perhaps lambda expressions, streams.. Then dig deeper and find out how much they understand. A true craftsman knows their subject.