Absolutely No Machete Juggling » Avoiding The Big Design Interview Question
If you're supposed to design the Car class, ask if there are other types of vehicles in the system. If not, don't make a Vehicle parent class, and explain that you see no need unless the system required additional vehicles. Before you draw a box named Tire, ask if the car needs to be able to support snow tires or some other kind of interchangeable tire. If not, why would you make a class or interface for them? Start as simply as you can and only draw a new box when you've extracted enough information from the interviewer to deem it warranted. If you jump up to the whiteboard and draw two or three boxes before asking any questions, you're placing your interview at risk because the interviewer may be picturing a completely different usage of this system than you are.
Of course, it's always possible that the interviewer will keep asking for the same information, arguing that you should show your OO skills off without requirements that drive that design out. If you want the job, your best bet there is to take a random stab at the appropriate level of complexity and hope that you strike somewhere near what the interviewer wants. In that situation, however, I'd imagine your interviewer doesn't know much about designing good software, and their codebase might be an over-engineered mess, so you may not want that job.
Read full article from Absolutely No Machete Juggling » Avoiding The Big Design Interview Question
No comments:
Post a Comment