Design Challenges For Interview

Senior questions

Design a house.
Design a breadtoaster.
Design an API for a disk.
Design a graphics library.
Design the game called Monopoly.
Design a fixed size memory allocator.
Design a button.

What you are looking for:

The interviewed is more concerned about getting more information from you and getting all facts straight rather than presenting a solution quickly that you will make useless by giving new requirements.
The interviewed takes care about safety and that the designed solution can be used only if used properly.
The interviewed conceives a very small subset of operations that allows to implement all possible operations. He can think abstractly and explain how some operations could be easily implemented using the most basic operations.

On Monopoly

For tech interviews I do, I nicked a question I was asked at an interview. "Design some of the classes to implement Monopoly". It works really well.

People who've just "been in the room" while engineering took place tend to just "um" and "ah" a lot, and they will hold the pen, but not use it.

People who've done a lot of grunt coding rather than actual design start talking about arrays of things and integers to store where you are in the arrays and some routines to work out the rents on properties. They will pick up the pen, but they'll start trying to write code.

OO design people will start saying things like "Ohh... there's properties. Oh and some of them are ownable and some aren't. And you can build on some of the ownable ones..." and they're sketching an type tree and putting behaviours in -- probably in some variant of Booch or UML class diag.. And those people can do OO design.

I've never put a functional developer through it, so I can't say how they'd answer.

The only real grief is when someone says "What's Monopoly?", in which case you have to find another boardgame you both know.

It's nice because it's not something you can "fake" or "learn" as such, you just have to be able to do it -- and you get to have a conversation about the stuff they're doing and get into their heads about how they work.

Frankly I'm bored of going to interviews for "senior" positions where I just get asked more complicated questions about exception handling that when I end up working there I find they don't use anyway... -- KatieLucas

Challenge the interviewers. Ask if they use these techniques, and why you, as a prospective senior person, need to know about them. If you fail the interview because of that then you probably didn't want the job anyway. Certainly I, when interviewing for more senior positions, want to hear someone asking "Why" - I deliberately create the situations where they ought to.

This sounds like an excellent question to pose. But I probably would rephrase it: How would you build a software version of Monopoly? This is so open-ended, the interviewee will immediately show how he approaches the problem. Does he think in objects? Functions? High-level abstractions? Data structures? Just reproducing the board game? Or adding computer-oriented features up the wazoo? Does he seek to narrow the requirements? Or does he make assumptions about the requirements? (What architecture? What kind of UI? What sort of system? What schedule? And so forth.) But while it is open-ended, the question is also contained enough to be a real problem. In fact, most design problems we face begin life as something like this.

Some of us forgot how Monopoly works.

What's "Monopoly"?

On designing a button

Ask the candidate how he would design a button. A good senior candidate will start off by asking what the requirements of the button are. The interviewer can answer with something very simple, like a blank rectangle on the screen that responds to the space bar being pressed. A good senior candidate would suggest a simple solution that fulfills only the stated requirements. Questions can then be asked about how their solution uses the existing classes of the software they are working with and how testing is done.

The interviewer can add a new requirement, such as the ability to display a text label, respond to a mouse click or take on a disabled state, and see how the candidate alters their design and testing to accommodate the new requirement. This cycle is repeated.

This can reveal a lot about the design skills of senior candidates. How much do they assume ? Do they fulfill only the current requirements or do they over design ? How do they respond to changing requirements ? Where do they use polymorphism ? How do they use delegation ? How do they refactor their design as the requirements change ? How much of their flexibility comes from following the requirements versus fearing change ? How easy was it to alter their existing design to accommodate the new requirements ?

I feel that how the candidate works in this situation predicts how they work in general. -- RodneyRyan?

Am I out if I find a way to make EverythingIsa Button? Or, if I start on an anti-hierarchy or anti-type tirade and argue that one should be able to click on a picture or change a picture to a button (and/or still be a picture) such that most traits are combinable between all widgets rather than make them mutually exclusive? After all, what is the difference between a button, a hyperlink (text), a clickable image, and a text entry-box with an On-Focus event? Indentation animation? That should not be limited to just grey rectangles. If I want to make a text box or a picture wiggle when one clicks on it, why not? I am just to provide the mechanism as a GUI kit designer, not force conventions on customers (who usually pay a premium for flexibility). No wonder my career has gone south lately. I think too much and they are afraid that thinkers are not doers :-) --top