|
|
|
|
|
|
by 8dot5by11
5464 days ago
|
|
|
Point taken. Its probably just dumb luck. Like any interview, I am told about their problem and how they have proceeded into uncharted territory. And I am asked, "What would you do to improve our issue/problem?" As it appears, I have worked on a similar issue. Apart from wanting to know the specifics of how I did it, they want to know about the anticipated risks and how to mediate them, the barriers I ran into, how to resolve those, which tools I used, etc. |
|
|
Put in other terms: they threw you a situation that you would probably have to handle if you were working there, and then asked what you would do in their situation.
I do this a lot when I come across problems because it lets me see how others think (I of course ask the questions after having solved the problem myself). And each of the answers to the questions have useful implications:
- Anticipated risks: have you thoroughly analyzed the possibilities, and do you understand the implications of your decision?
- Barriers: did you actually try this? [If you've tried to put a solution together yourself, you will come across most of the barriers anyway]
- Tools: did you use a tool with the constraints in mind? (one time, a person suggested that I take a million-line CSV file, put it into excel, and use the interface to find the sum of a column of numbers.)
It's easy to assume that, with a specific situation, the company may not have found a solution to the problem. However, more likely than not the developer you are interviewing with actually was the one who had to hobble together a solution, and he wants to see if you could do something similar if it happened to you.
The reason why I asked about which companies you interviewed with: many types of jobs in NYC are either client-facing or front-desk-support, both of which require mission-critical temperament and mental agility. You can't blame EC2 for failures ...