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:

Staying true, the language designer decided that this does not work in Java:

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:”

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

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.