"I would take a guess" is a great answer. By definition, nobody knows the root cause of the problem. Taking a guess is a much better next step than NOT taking a guess. By phrasing it as a "guess" you are showing that you are open to it not being correct, and taking the next guess, if needed.
I'm glad that you got the job. Other applicants probably had blank stares.
OK, spoiler alert: I'm going to spill the beans here....
...You are correct, Max, for that very logical answer. The explanation usually given in biz schools is this: Option A represents risk and potential reward. Option B leads to failure, so that's not a good option. And Option C also leads to failure. So Option A is the only one that might lead to success. If you try it and it fails, then you can still try something else. So it's the only viable course. As you say: someone's gotta make the tough calls.
@Tom: ...would you like to explain why you picked A?
You should know by now that the problem is getting me to STOP talking :-)
Once again, please remember that I have no background in business whatsoever -- I prefer the world of digital logic :-)
The problem started by saying "You're a CEO who needs to boost revenue" -- when we combine this with the comment in (B) that says "they'll add some revenue, though not nearly as much as you need" I take thsi to mean that I REALLY need to boost revenue.
Option (C) says "You ask your managers for further study." To me this implies that they've already done some study -- hence the fact you knwo (B) won't generate enough additional revenue -- will "further study" change anything? To me that's just a way to kick the can down the road.
Someone has to make the tough choices, and as a hypothetical CEO with nothing to lose I chose (A) :-)
Do you mean guess what the "right" answer is, or what the business school says it is, or...
I'm rubbish at the business side of things. I would say that if we already know (B) won't make enough money ... and we also know that managers waffle and cover their rosy cheeks -- then I would go for (A).
But that's easy for me to say when I don't have people's jobs/lives hanging in the ballance.
I guess another alternative would be to fire all of the managers :-)
Max: And I think they were prudent to hire you, Max. The more scientific method of finding the problem would be to treat each possible problem equally. But an educated guess is the place to start first, and it is what we all do every day in every problem we face. We often make mistakes, but that adds to the cumulative knowledge, doesn't it?
There's a business school standard exercise: You're a CEO who needs to boost revenue but faces a tough choice. A) You start a high-risk project that could yield enormous rewards.
B) You could instead expand existing lines of business, confident they'll add some revenue, though not nearly as much as you need.
I couldn't agree more. When I first moved to Boston before the completion of the Big Dig, it was horrendous to enter the tunnel to or from the airport, where at least six to eight lanes of traffic necked down to two lanes. I noticed a late-model Mercedes and some old junker vying to occupy the same space at the same time with neither giving an inch. I was slack-jawed to see the beater literally peel the side trim off the Mercedes.
I was once being sort of interviewed for a job. I say "sort of" because the interview was taking place in a pub over a pint or three of beer, but we digress...
One of the questions I was asked was "So we have a new system... we power it up... and it doesn't work as expected... how would you go about debugging it?"
I replied "I'd take a guess." I then went on to explain that everything depended on the circumstances and the particular system in question, but that my typical approach would be to observe what the system was doing -- e.g., what responses was it putting out -- plus any other "input" such as prior experiance with similar systems or prior experiance with systems performing similar actions -- and use my intuition to focus on what I thought might be the problem area.
If I was right, then I could hone in on the problem area really quickly and start the process of identifying the exact problem and coming up with a fix. If I was wrong, then I wouldn't have lost too much time (plus I would already gave gleaned some useful information as to what the problem was "not"), and I would commence a more exhaustive debugging process taking things step-by-step until I isolated the problem.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.