Java interview questions

[snotnose]

I've got 40 years C experience, mostly with device drivers and OS internals (helped port Linux to the SH-4 back in 2000). I retired a few years back (thank you Qualcomm), and learned Java to scratch some itches.

Now I'm bored and at 63 want to get back into the game. Thinking Java might be a path

I have a standard list of questions I asked C/C++ candidates, none of them seem relevant to Java (read: pointers).

So, what are some interview questions I can expect as a beginning/intermediate Java programmer?

To be clear, I'm still looking for C/device driver jobs. I grok hardware very well. But I'd kinda like to do something different, even if it is for 1-2 years.

 

[zelmak]

Does Java use a pass by reference or a pass by value mechanism?

Does Java support multiple inheritance?

 

[Apteris]

1. What are the differences between == and .equals()?
2. How are the contracts of .equals() and .hashCode() related?
3. What is the difference between int and Integer?
4. What is the difference between an ArrayList and a LinkedList?
5. What is garbage collection, and why is it useful?
6. What are generics, and how do they work in Java?
7. What are Java streams, and how do they work?

There's thousands of these. You may be better served just googling "Java interview questions" and going through the results.

 

[Faramir]

When I’ve hired I let candidates code in whatever language they wanted to and figured they could pick up another one if need be. But if I needed someone to be productive in Java right away I’d want them to do the interview questions (standard leetcode type stuff, for better or worse) in java and judge comfort level from there.

I can’t think of a reason I’d ask a candidate whether a single file can have multiple top level classes, as I was once asked on an interview. What signal does that provide?

 

[Deleted member 43669]

Yeah, luckily, Trivial Pursuit interviews seem to be going out of style. Of course, yes, all hiring processes in the world suck.

It used to be typical to ask about OOP principles (what's polymorphism, etc.). Maybe stuff in the stdlib...

Note also that nowadays most jobs are Java + X; where X is Spring or something else. I'm not so sure people pay that much attention nowadays to language fundamentals.

 

[gregatron5]

Yeah, luckily, Trivial Pursuit interviews seem to be going out of style. Of course, yes, all hiring processes in the world suck.

It used to be typical to ask about OOP principles (what's polymorphism, etc.). Maybe stuff in the stdlib...

Note also that nowadays most jobs are Java + X; where X is Spring or something else. I'm not so sure people pay that much attention nowadays to language fundamentals.

We do. I have a non-standard style interview, but it gets to using a Collection, which then has to be de-duplicated. That eventually brings the discussion to List vs Set, which gets to "how does a Set know what if it has a duplicate?" Junior devs get a pass, but if you're a "senior java software developer/engineer" with a decade+ experience (and possibly and advanced degree) and don't know the purpose and importance of equals() and haschode() I get upset I wasted my time talking to you.

 

[Faramir]

Note also that nowadays most jobs are Java + X; where X is Spring or something else. I'm not so sure people pay that much attention nowadays to language fundamentals.

This is a negative signal IMO. If you so desperate for day 1 productivity that you can’t wait for a new hire to come up to speed on a framework then you should probably be going the contractor route and longer term fixing your pipeline issue.

 

[Apteris]

This is a negative signal IMO. If you so desperate for day 1 productivity that you can’t wait for a new hire to come up to speed on a framework then you should probably be going the contractor route and longer term fixing your pipeline issue.

I wouldn't mandate Spring knowledge for someone fresh out of college, but if they have at least a few years' experience it would be strange, these days, if they had not used Spring at all. Where enterprise software is concerned, it's second in importance only to the standard library, IMHO.

 

[Faramir]

I’ve been programming in java on and off since 1999 and never used spring (I only wish I had never used swing.) When I last interviewed I lost out on some offers because of that. It worked out in the end because the role I got was much better than any of the ones I didn’t, but without too much arrogance I think it’s fair to at least say those employers might have made a mistake.

 

[ramases]

Like Faramir, if we hire for permanent positions we take the long view; if I have concrete short-term productivity requirements I'll go shake a couple contractor trees.

Even if I were hiring for a role using Spring, I'd not ask Spring-specific questions, but ask questions specific to the problems Spring (claims to) solve.

For example, if we were to focus on Spring's IoC container, I'd ask things like "Why would you use Dependency Injection?", "How does a DI container play into it?", "What are the different options for expressing composition roots?" Likewise, I wouldn't ask questions specific to Hibernate, I'd ask questions on why you would use an ORM, what the advantages and disadvantages are, and so on.

Additionally and IMHO the core of Spring has been steadily rotting, and has done so for a long time, to the point where even if you subscribe to specific ways how Spring does things it at best a mediocre implementation of them, and has been for years. For example, even if you subscribe to the idea that using a DI container and that configuring it via annotations is a good idea, there are now DI containers that give you this without suffering from entire problem classes still existing with Spring. For example if you are willing to forego a number of DI container features that only tiny minority needs you can have compile time wiring, hence ensuring that unsatisfied injection point problems or type mismatches will pop up at compiletime instead of at runtime.

People who move into the Java ecosystem may end up being "socialised" in environments that do not use Spring, but would be able to learn Spring quickly because they already have experience with different but similar solutions, because the libraries they are used to solve the same problems as Spring does.

Anchoring your interview questions to specific solutions to a problem instead of the problem itself needlessly robs you of qualified candidates.

 

[gregatron5]

For example if you are willing to forego a number of DI container features that only tiny minority needs you can have compile time wiring, hence ensuring that unsatisfied injection point problems or type mismatches will pop up at compiletime instead of at runtime.

Sorry to derail, but which and do you have a preference? We're trying to carve off pieces of our Spring-based monolith (started in the 2.0 era, so there's some weird stuff in there), and I'm not afraid to suggest something different.

 

[Lt_Storm]

Additionally and IMHO the core of Spring has been steadily rotting, and has done so for a long time, to the point where even if you subscribe to specific ways how Spring does things it at best a mediocre implementation of them, and has been for years. For example, even if you subscribe to the idea that using a DI container and that configuring it via annotations is a good idea, there are now DI containers that give you this without suffering from entire problem classes still existing with Spring. For example if you are willing to forego a number of DI container features that only tiny minority needs you can have compile time wiring, hence ensuring that unsatisfied injection point problems or type mismatches will pop up at compiletime instead of at runtime.

Yes, for instance, Google's Guice always did this way better than Spring did.

 

[snotnose]

I could actually answer all your questions until you got to swing/spring. I've tried to figure out the Java GUI a couple times with no joy. In my defense, I've made 1 GUI in my life. In Tcl/Tk. 30 years ago. Not much call for a GUI when you're intercepting TCP/IP packets to send/receive them via your custom PCI driver for your custom hardware

Except for hashcode(), I'd never heard of that before. Then again, outside of strings I never compare objects.

Why I didn't google "Java interview questions" before starting this I'll never know.

My problem is Java isn't stuck in my head enough to pull things from memory. I consistently screw up the main() line. I can never remember if I want size() or length(), let alone .size or .length. I'm constantly googling "I need to foo", "I know how to foo, what are the arguments", etc. In other words, I know what I want to do, I'm just not sure of the library/method/whatever syntax. Don't even get me started on the import hell, I use vi and makefiles. I should learn an IDE one of these days.

In other words, if I was interviewing you for a C position you could answer all the questions, but your code on the whiteboard would thumbs down you. Mostly because I wouldn't be asking questions like "what is diamond syntax", "what are generic types", "what are streams" etc. Instead I'd ask you to whiteboard code using these concepts.

TL;DR googling 'Java interview questions' did the trick, I'm trying to not use cut and paste nor google nor an IDE to get better. And I should learn Eclipse as it would solve a lot of problems, even though that learning curve is steeper than Java's.

 

[Fruity Pebbles]

TL;DR googling 'Java interview questions' did the trick, I'm trying to not use cut and paste nor google nor an IDE to get better. And I should learn Eclipse as it would solve a lot of problems, even though that learning curve is steeper than Java's.

I'd recommend IntelliJ over Eclipse, but that's a personal preference.

 

[snotnose]

IntelliJ costs $$$, Eclipse doesn't.

To me the tradeoff is Eclipse vs Android Studio. I have both installed and avoid both like the plague due to the learning curve.

 

[Ben_H]

IntelliJ costs $$$, Eclipse doesn't.

To me the tradeoff is Eclipse vs Android Studio. I have both installed and avoid both like the plague due to the learning curve.

There's a free version of IntelliJ IDEA for personal/educational use (and if it's anything like the free version of PyCharm, should have built in tutorials for how to use it). It's limited for some features but for practicing basic interview question-type things, it'll probably be fine. If you need to do JavaEE stuff though then yeah Eclipse is your best bet for free options.

 

[Lt_Storm]

Intellij is worth every penny, whether you use Java or pretty much any other programming language. It has to be among the best programming software I have ever used.

 

[Apteris]

My problem is Java isn't stuck in my head enough to pull things from memory. I consistently screw up the main() line. I can never remember if I want size() or length(), let alone .size or .length. I'm constantly googling "I need to foo", "I know how to foo, what are the arguments", etc. In other words, I know what I want to do, I'm just not sure of the library/method/whatever syntax.

Practice should help with this.

Don't even get me started on the import hell, I use vi and makefiles.

For Java? That's... retro.

Seriously, forget that and learn Maven. There are other (possibly better) build systems for Java, but Maven is a common denominator and not a bad one at that. Managing dependencies manually is too 1995.

I should learn an IDE one of these days.

IntelliJ IDEA is pretty easy to just install and use. It has advanced features, yes, but also a tutorial, and you can learn as you go.

IDEA was (and remains) an invaluable tool for my own learning process. If you want to see a method's JavaDoc without an IDE's assistance, you'd need to go to the JavaDoc site and find the object and method you're interested in; with IDEA it's Command-J.

If you want to see what methods an object offers without an IDE's assistance, you need to read the API page for that object top to bottom; in IDEA its Command-Space, and it'll also suggest the method you most likely want in your current context. If you want to see all classes which implement an interface without an IDE's assistance, again, JavaDoc -- unless you're interested in not only the classes in the standard library, but also those in your project, in which case you're out of luck. In IDEA it's Command-U followed by Command-Alt-B. And any time you want to read a class, F4 and you're there. I can't tell you how much this helps.

IDEA is a comprehensive and very fast assistant to your efforts of learning what code is available within the scope of your current project, and how all of the code you have works. A directly thought-controlled code editing and lookup tool would, IMO, only be marginally faster.

 

[Deleted member 43669]

I could actually answer all your questions until you got to swing/spring. I've tried to figure out the Java GUI a couple times with no joy. In my defense, I've made 1 GUI in my life. In Tcl/Tk. 30 years ago. Not much call for a GUI when you're intercepting TCP/IP packets to send/receive them via your custom PCI driver for your custom hardware

Well, I don't think no one's ever going to ask you about Swing in an interview (someone mentioned, but not about current interview questions). Swing is pretty much dead (except, ironically, in IntelliJ). Jobs where you do desktop GUIs in Java are rare too. I wouldn't worry too much, unless you really want one of those- and even for that positions, I assume they won't expect Java GUI knowledge in the interview.

Except for hashcode(), I'd never heard of that before. Then again, outside of strings I never compare objects.

Well, that's a basic one for "foundational Java"-type questions. Again, I think those are not much in style nowadays (I'm not saying whether it's good or bad to ask that. Just stating what I think is the market...).

But you also use hashcode/equals when you want to put a custom type of yours into a HashMap/HashSet (and other types). If those are not overriden properly, you won't get correct behavior in many cases.

Many places will automate the creation of them, or due to how they do things... never require that. Still, it's Java basics, but it wouldn't be surprising that even people with some commercial Java experience do not know about them.

But again, foundational question- I don't think it's super high probability you'll get that, but some of the posters above seem to ask about that on interviews... so it shouldn't be a big surprise (plus, it's all pretty logical, consistent, and easy to learn).

Why I didn't google "Java interview questions" before starting this I'll never know.

Well, I'm not sure it's easy to find a "reputable source" for that. Like here, I expect many lists of that to be "what I think are good Java interview questions" vs. what you want; "what is likely I'll be asked in a job interview".

My problem is Java isn't stuck in my head enough to pull things from memory. I consistently screw up the main() line. I can never remember if I want size() or length(), let alone .size or .length. I'm constantly googling "I need to foo", "I know how to foo, what are the arguments", etc. In other words, I know what I want to do, I'm just not sure of the library/method/whatever syntax.

There is some inconsistency in the stdlib (or things that make sense but seem inconsistent; arrays length makes sense as a "field", collections length needs to be a method).

However, for interviews, as long as you don't claim to be a Java expert... well, *I* think it shouldn't matter if you get the minutiae right- it's something you can google quickly or your IDE can take care for you, and it doesn't really affect much your capability as a developer. But some interviewers might not share my opinion. Hopefully, not a majority.

Don't even get me started on the import hell, I use vi and makefiles. I should learn an IDE one of these days.

Java is an IDE-friendly language. Many other languages *CANNOT* have an effective IDE (or at least easily. Pylance on VS Code is pretty good, but it's probably oodles more complex than a Java IDE)... so it's worth taking advantage of.

Imports are not really hell. Classes in Java are namespaced, so it's java.util.HashSet... you either use the fully-qualified name, or use an import to clarify what you mean. It's pretty different to a C include, or a Python import...

In other words, if I was interviewing you for a C position you could answer all the questions, but your code on the whiteboard would thumbs down you. Mostly because I wouldn't be asking questions like "what is diamond syntax", "what are generic types", "what are streams" etc. Instead I'd ask you to whiteboard code using these concepts.

"All interviews are broken". It's just down to personal preference. Whiteboard interviews have problems too. It's just a matter of what the interviewer prefers, and the current trends on interviewing. I think there are some formats which are harder/easier to prepare for. Whiteboard interviews (IMHO) are relatively easy to prepare for (e.g. read Cracking the Code Interview and do the exercises). I'd rather prepare for that than for Trivial Pursuit interviews.

TL;DR googling 'Java interview questions' did the trick, I'm trying to not use cut and paste nor google nor an IDE to get better. And I should learn Eclipse as it would solve a lot of problems, even though that learning curve is steeper than Java's.

I dunno- I've been using Eclipse for so long I don't have a clear picture of what's hard about it.

There are ways (IIRC) to get Eclipse's completion engine and stuff in Vim (perhaps Neovim?)... if you want to go down that path. Also VS Code might be simpler.

As it has been posted above... what you shouldn't be using is make. It's pretty hard to use make for Java. As others mentioned, I like Maven (although Gradle is popular on the Internet nowadays...). I'd give that a shot.

 

[snotnose]

"All interviews are broken". It's just down to personal preference. Whiteboard interviews have problems too.

I had one interview where the first question was "reverse a string". This was in C. I put a pointer at the front of the string, one at the end, and walked them to the middle. We spent the rest of the interview with me convincing him my way worked. I got the job.

I dunno- I've been using Eclipse for so long I don't have a clear picture of what's hard about it.

That's how I feel about vi (or Vim). Dirty little secret: I don't really know vi all that well. But my fingers do. I look at my code, imagine what I want it to look like, and somehow it just happens.

 

[Lt_Storm]

Don't even get me started on the import hell, I use vi and makefiles. I should learn an IDE one of these days.

Also, it isn't really something you need to "learn", I mean, an IDE is just a smart text editor that understands the language and your program. If you like vi, then get the vi-mode on Intellij (or whatever other IDE you want to use, but, seriously, Intellij IDEA) and move forward with life. As for fancy IDE features like refactoring, I would recommend that you bind them to keybinds yourself, after all, you will remember your own keybinds.

 

[Lt_Storm]

Don't even get me started on the import hell, I use vi and makefiles. I should learn an IDE one of these days.

Java is an IDE-friendly language. Many other languages *CANNOT* have an effective IDE (or at least easily. Pylance on VS Code is pretty good, but it's probably oodles more complex than a Java IDE)... so it's worth taking advantage of.

I don't buy this one. I mean, I have used Intellij IDEA for Java, Ruby, Python, Clojure, and half a dozen other languages. It works fine and kicks the crap out of basic text editors for any language I have ever tried.

 

[ramases]

I don't buy this one. I mean, I have used Intellij IDEA for Java, Ruby, Python, Clojure, and half a dozen other languages. It works fine and kicks the crap out of basic text editors for any language I have ever tried.

I think it is more related to refactoring support than editing support: In a language with a strong type system you can have very powerful static code analysis, and as a consequence can perform wide-ranging refactoring on non-trivial codebases with the IDE doing all the heavy lifting for you: Want to add an argument (with a default value) to a method that is called dozens or hundreds of times in your code base?

No problem, the IDE will reliably find every single instance and make the change, and it can use the compiler as a completeness check.

There's of course also refactoring support in IDEs for languages with weak type systems, but they are either much more limited, or come with "this is best effort, we might/may/probably/certainly will miss things" caveats; what is worse, unless someone went to the bother to manually write a test for something that in another language the compiler would "test for free", it might only show up at runtime.

"All interviews are broken". It's just down to personal preference. Whiteboard interviews have problems too.

I had one interview where the first question was "reverse a string". This was in C. I put a pointer at the front of the string, one at the end, and walked them to the middle. We spent the rest of the interview with me convincing him my way worked.

The logical follow-up being how this reverse-in-place can be made to cope with variable-length encodings like UTF-8.

For example if you are willing to forego a number of DI container features that only tiny minority needs you can have compile time wiring, hence ensuring that unsatisfied injection point problems or type mismatches will pop up at compiletime instead of at runtime.

Sorry to derail, but which and do you have a preference? We're trying to carve off pieces of our Spring-based monolith (started in the 2.0 era, so there's some weird stuff in there), and I'm not afraid to suggest something different.

We so far (about a year into it in a couple projects) liked Quarkus. Once you get used to a couple of things it is pretty neat, and something like a ~35 MB fat jar including a http implementation (there's no application server), jax-rs/json runtime, hibernate and all the other nice things like structured logging, healthchecks, metrics, ... works for me.

Starts up nicely fast (about a second or two; remember all the wiring has already been set up at compile time, hence there's no need for JAR scanning or similar stuff), memory footprint is much lower than with Spring. You still need a GraalVM runtime, which even tho you only need it once for all applications isn't ... the smallest runtime environment, but if you really wanted to (and are willing to put up with what this requires; for example there's some plumbing involved in making reflection work for native builds), you can compile it down to an entirely self-contained native binary.

 

[gregatron5]

A couple follow-ups.

I never expect someone to remember proper syntax pedantry. If you know you're trying to get an array's or list's size and you use size() or .length and it's not the right thing, I don't really care. The compiler will catch that for you, and code completion will mean you'd probably not even gotten to a compiler error while actually writing code.

That said, if you try to do Collection<Thing> things = new Collection<>() I'm going to start questioning. If it's a snafu and you catch that, oh yeah, Collection is an interface and you need to instantiate a concrete implementation, I'll most likely chalk it up to interview jitters. If you have no idea that Collection is an interface, or that you can't instantiate an interface, we're done unless you're applying for a junior position. (And even then, I'd be a little leery.)

I have a different interviewing style from anyone I've ever interviewed for or with, though, so of course YMMV. I want to know you know the fundamentals of OOP and Java*, not that you've memorized syntax or some specific algorithm, and my interview is designed for that. That said, if one were to proclaim to know a specific tool I also know, I will make sure you're not lying about it. (I can't tell you the number of people who have "years" of "expert" experience with Hibernate and know absolutely nothing about how it works or about the database underneath it. If you don't know it, own it. It's ok. We'll teach you.)

--

I'm a staunch IntelliJ IDEA fanboy. I've been using it since you downloaded a jar and ran it from the command line. It's a good tool worth using, even if you have to pay for it. (I have a good long rant about modern tendencies to think "free" is better than "great-but-not-free".) There are only two things I've found that Eclipse does better, and it's not worth using a lesser tool for those two use cases.

One of the best pieces of advice I can (and do) give is: "Always read the tip of the day." Seriously. There's so much stuff in there. I've been using IDEA for two decades and I still learn stuff from the tip of the day (or am reminded of stuff I've forgotten). The IdeaVIM plugin is really good, too.

--

Thanks for the pointers for Guice and Quarkus. I've looked into them in the past but never really played with them. I'll give them another look next time I get the chance.

--

* Re: "fundamental Java". The Collections framework is something I consider "fundamental, Java." It is critical and essential to all modern Java programming. equals() and hashCode() are foundational to how Collections work. If you want to get into Java, aside from "core" features like Strings and base language stuff, you should really learn the Collections package. You'd also get a lot of mileage by really understanding Java generics, too. Almost no one really properly understands type erasures and bounded wildcards, and so (IMO) it's incredibly undervalued knowledge, but if you do understand it your code can really stand out above the rest.

 

[Lt_Storm]

Thanks for the pointers for Guice and Quarkus. I've looked into them in the past but never really played with them. I'll give them another look next time I get the chance.

Guice is nice because configuration is, for the most part, automagically figured out. So long as the constructor is annotated, and an implementation provided, it will inject the right thing at the right place. As I recall, more recent versions of Spring do this a bit too, but, I have always found that Guice's approach is more natural, elegant, and requires less hand holding. (To the point where, when I was running a framework built on Spring, I set it up so that, for the most part, Spring would ask Guice to do the dependency injection.)

 

[Jehos]

(I have a good long rant about modern tendencies to think "free" is better than "great-but-not-free".)

I want to join in when you do this rant.

 

[Little Mike]

1. What are the differences between == and .equals()?
2. How are the contracts of .equals() and .hashCode() related?
3. What is the difference between int and Integer?
4. What is the difference between an ArrayList and a LinkedList?
5. What is garbage collection, and why is it useful?
6. What are generics, and how do they work in Java?
7. What are Java streams, and how do they work?

There's thousands of these. You may be better served just googling "Java interview questions" and going through the results.

I'm a senior/staff-ish level engineer on a strategically important Java project, and as such do a decent amount of interviewing of "Java Developers" and I experimented at the beginning with asking these questions, but I quickly found that people who had memorized the answers were useless as actual teammates. If you consistently run into **** like this you're interviewing for jobs that expect you to be a mindless code monkey.

If the interviewee can find it on google during a bathroom break, it's not a good question. If they have any experience at all, ask them about things they experienced during previous projects.

 

[Apteris]

I'm a senior/staff-ish level engineer on a strategically important Java project, and as such do a decent amount of interviewing of "Java Developers" and I experimented at the beginning with asking these questions, but I quickly found that people who had memorized the answers were useless as actual teammates. If you consistently run into **** like this you're interviewing for jobs that expect you to be a mindless code monkey.

I ask these questions more than answer them. What I've found is that they are a useful filter, even seemingly simple ones like the first two. Perhaps the applicant pool is different where I am from where you are, but it's not rare to get an applicant who looks good on paper but stumbles when asked some of these questions.

If the interviewee can find it on google during a bathroom break, it's not a good question.

You can't acquire a deep understanding of the reasons why things work the way they do during a bathroom break.

If they have any experience at all, ask them about things they experienced during previous projects.

We do that, in addition to the above.

 

[Jehos]

I'm a senior/staff-ish level engineer on a strategically important Java project, and as such do a decent amount of interviewing of "Java Developers" and I experimented at the beginning with asking these questions, but I quickly found that people who had memorized the answers were useless as actual teammates. If you consistently run into **** like this you're interviewing for jobs that expect you to be a mindless code monkey.

I ask these questions more than answer them. What I've found is that they are a useful filter, even seemingly simple ones like the first two. Perhaps the applicant pool is different where I am from where you are, but it's not rare to get an applicant who looks good on paper but stumbles when asked some of these questions.

If the interviewee can find it on google during a bathroom break, it's not a good question.

You can't acquire a deep understanding of the reasons why things work the way they do during a bathroom break.

If they have any experience at all, ask them about things they experienced during previous projects.

We do that, in addition to the above.

A couple things:

1. You can generally tell if you're talking to a crap candidate even if you didn't ask those questions.
2. Those questions aren't demonstrating a deep understanding of anything.

Basically those trivia-type questions are redundant and YAGNI. Cut them out of your interview script.

 

[Apteris]

1. You can generally tell if you're talking to a crap candidate even if you didn't ask those questions.

They help.

2. Those questions aren't demonstrating a deep understanding of anything.

Basically those trivia-type questions are redundant and YAGNI. Cut them out of your interview script.

What would you have me replace them with?

 

[Lt_Storm]

I'm a senior/staff-ish level engineer on a strategically important Java project, and as such do a decent amount of interviewing of "Java Developers" and I experimented at the beginning with asking these questions, but I quickly found that people who had memorized the answers were useless as actual teammates. If you consistently run into **** like this you're interviewing for jobs that expect you to be a mindless code monkey.

I ask these questions more than answer them. What I've found is that they are a useful filter, even seemingly simple ones like the first two. Perhaps the applicant pool is different where I am from where you are, but it's not rare to get an applicant who looks good on paper but stumbles when asked some of these questions.

If the interviewee can find it on google during a bathroom break, it's not a good question.

You can't acquire a deep understanding of the reasons why things work the way they do during a bathroom break.

If they have any experience at all, ask them about things they experienced during previous projects.

We do that, in addition to the above.

A couple things:

1. You can generally tell if you're talking to a crap candidate even if you didn't ask those questions.
2. Those questions aren't demonstrating a deep understanding of anything.

Basically those trivia-type questions are redundant and YAGNI. Cut them out of your interview script.

Moreover, those questions are pretty language specific, if someone doesn't know the answers to them, it will take them a few hours of Java study to get them down. On the other hand, they don't tell you anything about how the interviewee handles the hard parts of development: do they know anything about how to gather requirements, break down a problem, how do they deal with design problems like scalability and performance, how do they react to feedback, etc.

As for what to ask: either talk about their experience or ask them design questions about some simplified real world problem. My favorite of these is a ticketing system, as it allows me to see if they are aware enough to ask me questions about how the system is going to actually be used, I can adjust the parameters to consider how they would respond to scale or performance requirements, and the central component, a priority queue, is simple enough that I can have them write a little bit of code and see if how they would go about testing it, and finally see how they react to feedback about that code.

 

[Jehos]

What would you have me replace them with?

Nothing. I mean it, YAGNI. Just remove them and go on with the other stuff in your interview script.

 

[Faramir]

If they have any experience at all, ask them about things they experienced during previous projects.

These conversational interviews only determine how likable the candidate is to the interviewer. Let’s not throw the baby out with the bath water.

 

[Apteris]

Moreover, those questions are pretty language specific, if someone doesn't know the answers to them, it will take them a few hours of Java study to get them down. On the other hand, they don't tell you anything about how the interviewee handles the hard parts of development: do they know anything about how to gather requirements, break down a problem, how do they deal with design problems like scalability and performance, how do they react to feedback, etc.

This notion of the talented polyglot developer who may or may not have studied Java but can pick it up in a few hours does not match my experience. I interview people for intermediate or senior Java positions, and if you've made it through the funnel thus far it means you have a few years of experience with Java specifically.

It also means you've already answered a standard set of questions, and should therefore have no issue answering the easy ones. Indeed, this is how it goes in practice: some candidates breeze through the examples above; 30 seconds is plenty of time to show that you know the answer to any one question. Other candidates have a surprising amount of difficulty. This correlates with the quality of the candidates' answers to later questions in the interview -- some of which are broader / more high-level.

You don't need to take my word for it. Sprinkle one or two beginner-level questions in the interviews you yourselves conduct, with applicants who list _years_ of experience with the language in question, and note the results. I only believed it myself when I saw it first-hand.

As for what to ask: either talk about their experience or ask them design questions about some simplified real world problem. My favorite of these is a ticketing system, as it allows me to see if they are aware enough to ask me questions about how the system is going to actually be used, I can adjust the parameters to consider how they would respond to scale or performance requirements, and the central component, a priority queue, is simple enough that I can have them write a little bit of code and see if how they would go about testing it, and finally see how they react to feedback about that code.

Not a bad idea. But once you establish the requirements, after discussing this with the candidate, do you ask them to implement them? How does that work out -- discussion and implementation -- and how long does it take to do all of it?

 

[Lt_Storm]

As for what to ask: either talk about their experience or ask them design questions about some simplified real world problem. My favorite of these is a ticketing system, as it allows me to see if they are aware enough to ask me questions about how the system is going to actually be used, I can adjust the parameters to consider how they would respond to scale or performance requirements, and the central component, a priority queue, is simple enough that I can have them write a little bit of code and see if how they would go about testing it, and finally see how they react to feedback about that code.

Not a bad idea. But once you establish the requirements, after discussing this with the candidate, do you ask them to implement them? How does that work out -- discussion and implementation -- and how long does it take to do all of it?

Given that, for the purposes of the interview, it is a toy question, you focus in on some toy part of it and ask them to write a little code. Generally speaking, you should be able to get at least a partial implementation of some sort of priority queue; not necessarily something fancy like a heap, nor something complete, but at least the interface and a couple methods on something that might be useful for some version of the requirements you discussed, possibly with hand waving for various functions that it might use.

Remember, the point of getting an implementation isn't to get them to write a correct working ideal implementation (this isn't a test), but instead just to get to a small sample of code written by them so you can see what it looks like, how they might test it, and have a bit of code to actually discuss with them.

As for how long this interview takes, about an hour with half an hour for discussion of requirements, design, and such and half an hour for a partial implementation of something and a discussion of how to test it, though, honestly, an hour and a half to two hours would be ideal. If you have less time, well, usually that is because there are multiple interviews and therefore you can coordinate with the other interviewers and focus on just one part of the interview.

 

[Lt_Storm]

If they have any experience at all, ask them about things they experienced during previous projects.

These conversational interviews only determine how likable the candidate is to the interviewer. Let’s not throw the baby out with the bath water.

If that's the case, it's because you didn't focus in on anything specific. I mean, if we are talking about your past experience, I am going to be asking questions about requirement / design / scaling / operational / etc. problems you encountered, how you solved them, and what you would do differently.

Even better, if you have some public work, I would pick some part of it that you wrote, bring the code up in a browser and have a discussion about it code review style.

 

[Jehos]

If they have any experience at all, ask them about things they experienced during previous projects.

These conversational interviews only determine how likable the candidate is to the interviewer.

If you're making hiring decisions based solely on how likable a candidate is, you probably shouldn't be interviewing people.

On a related now, interviews are always conversations. If you're treating them as tests, you shouldn't be asking those things in the interview, you should be asking them in a test before you spend time interviewing the candidate. I don't need to waste my time proctoring tests.

 

[Faramir]

I love how everyone on the internet is a genius at hiring that takes the same basic format that we know from research is unreliable and produces biased results and gets unbiased, high signal out of it. Do I know the right places to hang out, or what!

 

[Jehos]

I love how everyone on the internet is a genius at hiring that takes the same basic format that we know from research is unreliable and produces biased results and gets unbiased, high signal out of it. Do I know the right places to hang out, or what!

Being surrounded by super geniuses is a blessing.

 

[snotnose]

Wow, haven't checked this thread in a while.

When I say "import hell", what I mean is when I want to use someThing I need to "import java.foo.bar.someThing*";

As I don't use an IDE it's always fun trying to figure out what foo, bar, sometime blatz should be.

With C I always know what to #include, but with Java I always have to refer to the official docs. I find it annoying when those "this is how to use someThing" web pages don't tell you what to import.

Oh yeah, I refuse to "import some.random.joes.package", I don't care who the random joe is. I'd rather do without the package.

I've got both Eclipse and Android Studio installed, I should learn how to use one of them.....