I made this up out of whole cloth to help someone with mock interviews, but I think it’s broadly applicable to a lot of situations, particularly interview questions or technical conversations.  The idea is to work through goals from a high level to a nitpicky level of detail in an orderly way.

Let’s say someone asks you a stupid interview question, such as, “I want a stack of quarters the height of this building.”  Here’s how you could engage with that.

– Motivation: understand the big picture. “Can you help me out with the context for this requirement?  Why is it you’re trying to do that?”
– Environment: what is the context? “You mentioned the height of ‘this building’.  Can you help me out with whether we’re counting from the bottom of the lowest part of the foundation to the top of the highest peak in the roof, or where exactly you’d like this thing built?”
– Inputs: what are you being given, exactly? “So you’re going to give me a wheelbarrow full of quarters?  What kind?  I don’t know if they’ve changed dimensions over the years or not.  I’d have to go look that up.”
– Processing: what needs to be done? “Okay, so you’re talking about stacking coins here?  Do I have some kind of jig to hold them or something, or glue them together?  How am I supposed to get this to stand up?”
– Output: what exactly is the expected output? “Do you want me to actually build this, or just write a report on the feasibility?  Maybe you need a cost estimate?”

My favorite interview question for beginning programmers is deceivingly simple. “I’m going to give you two dates, and I want you prescribe a way to give me the number of days between them.”  I’m not actually looking for whether anyone knows the answer.  I’m looking for how they think about problem spaces.

There are a number of considerations here:

• should the answer be zero- or one-indexed?  In other words, if I give you two identical dates, are there zero or one day between them?
• What about time zones?
• What about the falsehoods programmers believe about time?

So here’s a MEIPO for this one:

Motivation Q: “can you help me out with why you’re trying to do this?”
A: “Let’s say I’m trying to do some finance calculations, so I need to compute the number of days between payments for interest calculations”

Environment Q: “What sorts of tools can I use?”
A: “any common programming language, so JavaScript, Python, Powershell, or you can use Excel or something. Whatever, really.”

Input Q: “You said you’re giving me two dates.  There are a lot of formats.  What should I expect?”
A: “Let’s just say ISO8601, so two strings formatted ‘YYYY-MM-DD'”

Processing Q: “Okay, so is there any funny business with time zones?  Can I assume that the dates correspond exactly to the same parameters each day?”
A: “You can assume that.  Bonus points if you can return a fractional day if I give you time components.  Extra bonus points if you can do it with time zones I specify.”

Bonus processing Q: “If the first date occurs after the other, are you expecting a negative number?”
A: “yes.”

Output Q: “okay, so it sounds like I need to return a float or an integer?  Do you have a preference?  How do I specify that there’s an error?”
A: “Float is fine.  Just return NaN if there’s an error.”

So, what’s the solution?  In some ways this is a test of how well applicants know common software.  By far the easiest way to do this in an interview setting is to use Excel.  So really, an ideal “Output Q” would go as follows: “I’m leaning toward just using Excel for this because it just stores dates as the number of days since an epoch, so it should be as simple as subtracting the two cells from each other.  Is an Excel error acceptable if there’s something wrong with the dates?  Are you okay with accepting Excel’s limitations around date processing?”