Java Interview questions: Multiple Inheritance

Recruiting and interviewing is a never ending task for development managers. Sometimes you get help from HR, but you're still on your own when deciding to hire or not to hire. Or as I've written last time in "Java Interview questions: Write a String Reverser":

Interviewing developers for a programming job is hard and tedious. There are some excellent Guides, like the Joel Guerilla Guide to interviewing, but in the end you need to decide yourself to hire or not to hire. To get a quick idea about their programming abilities I have considered asking the String reverse question.

Beside the String reverse question I have another favorite.

Does Java support multiple inheritance?

Well, obviously Java does not have multiple inheritance in the classical sense of the word. So the right answer should be "no", or "no, but" or "yes, but". From there one can explore several ways. Mostly I start by asking if the Java language designers were too stupid to implement multiple inheritance? Why did the C++ guys implement it then? We mostly land at the Diamond Anti-Pattern then:

In object-oriented programming languages with multiple inheritance and knowledge organization, the diamond problem is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If a method in D calls a method defined in A (and does not override the method), and B and C have overridden that method differently, then from which class does it inherit: B, or C?

The other way to explore is how Java "emulates" multiple inheritance? The answer, which might already have surfaced, ist Interfaces. We then usually discuss interfaces in Java, if, when and how the candidate has used them in the past. What are interfaces good for, does he like them? I can explore how good he is at modelling and sometimes make him draw a diagram with interfaces. We go on with problems of interfaces in Java, and what happens when two interfaces have the same static fields and a class implements both - some kind of "multiple inheritance" in Java:

public interface I1 {
   String NAME = "codemonkeyism";

public interface I2 {
   String NAME = "stephan";

public class C implements I1, I2 {
   public static void main(String[] args) {

Staying true, the language designer decided that this does not work in Java: reference to NAME is ambiguous, both variable NAME 
              in I1 and variable NAME in I2 match
1 error

There are many more ways to explore with the candidate, e.g. what are the modifiers of interface methods. Are mixins or traits a better solution to the diamand problem than interfaces? Or are they just as bad as multiple inheritance? As I'm no longer very fond of inheritance and think most uses are a code smell, one can also discuss the down side of inheritance - thight coupling for example - with the candidate.


Why do I ask this question and what do I learn from it? Inheritance is a very basic concept in OO and should be understood by every Java developer. Reflection on his work and going beyond knowing the syntax is an essential trait also, therefor the multiple inheritance question. I prefer questions that spawn many opportunities to explore. The inheritance question is one of them: Mutliple inheritance, language design, code smells, solutions, interfaces, role based development.

If you interview with me, you should know the answers, or tell me you've read my blog.

See also:

7 Bad Signs not to Work for a Software Company or Startup

Photo by mundo resink

There is a job offer, you're on a job hunt or a headhunter calls you. With the ending recession this scenario becomes more likely again. What are signs that you should not sign up with a company?

As someone who did a lot of recruiting and talked to many developers, I've prepared a list of signs that would tell me not to sign up with a company.

  1. No Source Control:
    Source control systems (SCM) are essential to software development. Be it Subversion, Perforce, Git, Mercurial or any other. Without source control integrating the work from different developers and projects is a nightmare. As Joel says in the legendary Joel Test:

    But if you don't have source control, you're going to stress out trying to get programmers to work together.

    There are still companies without SCMs, don't sign up there.

  2. No top tools or only home brewed ones (IDE, Build System, ...):
    Without the right tools, you can't work. Depending on the programming language and enviroment, the company should use an IDE, debuggers, build systems that allow one-stop builds and professional deployments. Without the right tools, software development is a pain. If you're a professional, insist on professional tools.
  3. No business model or not enough money:
    If you interview with a startup, ask them how much money they have and how long it lasts. Do not hire with a company that has less than 6 months of money - they most likely won't make it. The same goes for a company without a business model. No income is high risk. If you're young and like to take risks, it can be a worthwhile journey though (see the y-combinator financing model). It might be fun, and it might be valuable for you, but you have been warned.

    Some further reading, especially when joining a startup, is the excellent article Guy Kawasaki’s 10 Questions to Ask Before You Join a Startup:

    How much money do you have in the bank? This is a simple question. You just want a number. If you’re told that “investors are ready to put in more” or “we have a line of credit,” beware because a promise of money isn’t the same as money.

  4. They don't let you talk to or see developers:
    During many years of recruitment, I've always been astonished how few developers wanted to see their working space and talk to developers. Talking to other developers will enable you too get to know a prospective company. If they do not let you talk to developers, don't go for the job.
  5. High turnover:
    A bad sign is high turnover. There is always a reason for it. Ask people in the industry about the prospective company. Ask during the interview, if the job is new or if you are a replacement. Casually ask developers how long they have been with the company. As Kate Lorenz writes in Six Signs to Run -- Not Walk -- From Your Job:

    After two weeks on the job, you are already halfway to becoming the employee with the most seniority. One of the biggest issues for human resources professionals today is employee retention. You will notice that most of the country's top companies have employees who have been around for years.

    Do not get a job at a company with a high turnover rate. Period.

  6. Hiring is mainly done by HR, not by developers/technical staff:
    If hiring is mainly done by a HR person, there will be lots of developers recruited only by HR. Most of the time, they have no clue about what a good developer looks like. If you want to work with good people - and you should, because it's the best way to learn - do not work for a company that doesn't do recruiting with technical staff. Bonus points for a company that also lets developers interview applicants.
  7. No decent hardware:
    A company should respect their developers. As with good tools, decent hardware helps developers to turn more requirements into working code. Developers therefor should have a decent PC (e.g. dual core 3Ghz, 4/8gb memory) and 2 22/24" screens. Bonus points for Macs. As shown in several studies, the easiest way to gain lots of productivity is two screens. A company that is not interested in the basics of productivity, is not worth working for. They will not respect you.

So - what about you? What are your signs that steer you towards a "No thanks" when interviewing with companies? I'd like to hear.

Thanks to @andreaskaiser @Tungano @mwessendorf @AgileArtem @Devgru @benjaminm @gjmilne for their input.

Update: Great post on 10 Startup Red Flags by Adam MacBeth

Unboxing as a Java Interview Question

Sometimes I ask an unboxing question during Java interviews. "What can happen with unboxing? See this code:"

Integer i1;
// do some things with i1;
int i2 = i1;

The thing that can happen is that i1 is NULL which will result in a NullPointerException being thrown.

"What is the problem with the NPE here?" There are several ones. The big one is that developers search for dereferencing variables (think ".") when seeing a NPE. The line

int i2 = i1;

does not have a dot, the trained eye of a Java developer has problems to see the NPE there (if he didn't encounter the bug before).

"What would you have done instead, if you would have been the Sun developer designing the unboxing feature?"

Possible answers are:

  • Set i1 to the default value if i2 is null, 0 in this case (null being the default value for Integer)
  • Throw an IllegalArgumentException
  • Throw a ClassCastException
  • Throw an AutoUnboxingException (my favorite)

It's more about discussing design and programming decisions than getting the right answer from the candidate. With questions like this you can see how defensive a programmer can think, how he writes maintainable code and how good his micro-architecture design skills are. Often there is a dialog between the candidate and me about good design, error handling, exception handling and error messages.

What would you do?

Thanks for listening.

As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled)

Update: This code will throw an NPE too - obviously - but from reading the isSomething() line in a large app it might not be that obvious.

public class Test {
	public static void main(String[] args) {
		if (isSomething()) {
	public static Boolean isSomething() {
		return null;

Job Interviews for Java Developers: Attention to Detail

Someone has read my post about interviewing where I wrote about String reversal, but got it totally wrong. Ironic. He didn't show much attention to detail, took quotes out of context, put things into my mouth that I've never said and concluded "Want a job? Reverse a string. The sad state of job interviews today." This post even got to DZone. So my post could also be titled: The sad state of DZone today.

Most of my interviews are 1h to 1.5h and sometimes 15 minutes of the interview is about reversing a String. This is mainly to get into the thinking of the candidate, see how he deals with fringe cases (null values as arguments) and if he chooses a JDK reverse method or not. Jonethen didn't pay much attention to detail, so for a starter he got my name wrong, it's Stephan not Stephen. A minor detail but a sign for what was to come later in his post and the comments.

Jonathan is angered by my mentioning of the recursive version of reversing a string. Although I wrote why I think it's interesting to discuss a recursive solution, he ignores my arguments and writes

".. only that he would be much more impressed if someone did write it out."

I didn't say that.

"He would probably give higher preference to someone who did use that technique,..."

No I won't and I didn't say that either. I said "The best implementation in Java is to use the reverse method of the StringBuffer class in the JDK." I specifically pointed out that the reverse version is impractical in Java for the immutable String class alone, not to mention the surrogate pairs problem. So to make myself clear again, the best solution is to use the reverse method of the StringBuilder class. Any candidate who uses this method has already impressed me, because from my experience very very few developer know this. Most would write some kind of array swap method. But it's not the cause I ask this question. It's to see if someone can write code (which doesn't need to be compiler ready, he's no IDE in the end) and get into a discussion about programming, unit testing, fringe cases, how to handle errors, quality assurance and other topics. And if someone has read this blog? Or another blog? And knows the answer? Well good, the answer is just the beginning. And considering that very few developers read blogs and articles to learn something new, I'm happy to interview a candidate who reads blogs in general.

Without getting personal, I look for more attention to detail in the candidates I have than Jonathan did when he did shred my post. And I look with far more attention to detail into candidates than Jonathan did use when reading my post. Ironic.

One poster in the comments of Jonathans post suggested using StringBuilder instead of StringBuffer, because StringBuilder is not synchronized and faster therefore. I think modern VMs can use escape analysis to detect synchronized blocks or methods which can be optimized away, as in the local usage of StringBuffers. There should be no difference between StringBuffers and StringBuilders in modern Java VMs. But it doesn't hurt to use StringBuilder.

Ending his article: "If a interviewer wants to talk about my past projects with me, then it should not take him long to realize that I am a competent." Or read a blog, as Jonthan suggested in Blogging gets people hired.

Hopefully he doesn't read your blog.


PS: I wish I don't sound the least bit like Hani 😉