Technical interviews are used for the interviewers to whip their junk out and lay it on the table. They are usually more interested in letting you know how much they know instead of evaluating how well you could do the job. It’s probably they only time in life were they will get to intimidate someone.

I guess it’s payback for every dodge ball they had thrown at their head in gym class.

One interface can extend any number of interfaces.
try following compiles
interface x{} interface y{} interface xy extends x,y{}

One class can implement any number of interfaces.

One class can extend only one class.

@Arden, I do agree with you to a large extend. Depending on the work we have been dealt we can be doing almost no coding from scratch and there are thousands who do similar work day in and day out. Infact, though i hate to admit it, i too have faced a very similar situation for most projects i have worked on.
But my opinion is that we can still learn some of these basics as this will help us understand why the original developers wrote the code in the way they did so.
You also cannot rule out the possibility that we might have to write a whole new application one of these days and at that time, this learning will benefit us (and the debuggers who end up debugging/adding to our code in the future!)
As a side note, some of the most satisfying moments are when we(the debugging guys) actually recognize areas where the developers did not make the right design decision (or at least we feel so!) … but this is quickly followed by the sadness brought by the realization that we debuggers cannot change code that is otherwise not labelled by the users as ‘BROKEN’
As for the interviewers, the fault is not with them but with the companies that employ them. Companies need to accept the fact that not every developer actually develops day in and day out. Once they accept that, the interviewers would begin asking more questions dependent on the type of work we used to do in the past.