Tough interview question
-
So this guy asks me what what my general exception handling policy is. Log the exception and allow it to propagate. OK, what would I do to avoid the system crashing and the end user sitting staring helpless at an error message, unable to do business? What could I answer? Redundancy, parallel systems? No, the system you are currently running crashes. Oh, user friendly error message, error must be logged and developers notified. I mean, really, on a system coded and tested properly, you can't really do much more. Some people are never happy.
-
Asking a question to which there really is no good, obvious or correct answer is a pretty standard interviewing technique. Most interviewers want to see your ability to think through different options, consider pros and cons of each and give a qualified answer. The other thing to look for is someone who gets frustrated or flustered, they're the ones you don't want.
Josh Gray wrote:
The other thing to look for is someone who gets frustrated or flustered, they're the ones you don't want.
Hmm, I don't know. From my limited personal experince, I can safely say that the ones that get frustrated of irritated when something doesn't work, they are way more productive and come up with many more solutions/ideeas then the calm ones. I think the main reason why they are calm is because they don't care much about their work. Now if you guys were talking about a TeamLeader, Architect or some other form of management than yeah, the person must not get frustrated/irritated. But a developer, IMHO I don't see a problem with it, as long as he/she does it's job.
I used to think.... Finally I realized it's no good.
-
Asking a question to which there really is no good, obvious or correct answer is a pretty standard interviewing technique. Most interviewers want to see your ability to think through different options, consider pros and cons of each and give a qualified answer. The other thing to look for is someone who gets frustrated or flustered, they're the ones you don't want.
Very true. Towards the end he straight out asked me how I handle frustrating situations, I suspect because his ruse of trying to frustrate me wasn't working. :laugh:
-
Josh Gray wrote:
The other thing to look for is someone who gets frustrated or flustered, they're the ones you don't want.
Hmm, I don't know. From my limited personal experince, I can safely say that the ones that get frustrated of irritated when something doesn't work, they are way more productive and come up with many more solutions/ideeas then the calm ones. I think the main reason why they are calm is because they don't care much about their work. Now if you guys were talking about a TeamLeader, Architect or some other form of management than yeah, the person must not get frustrated/irritated. But a developer, IMHO I don't see a problem with it, as long as he/she does it's job.
I used to think.... Finally I realized it's no good.
As I said in this interview, frustration is part of the job of development, compared to other jobs where the same actions give the same results fairly reliably. It's not whether you get frustrated or not, but how you react when you inevitably do get frustrated.
-
Brady Kelly wrote:
even if he does consider model validation, data annotations, and ORM's to be slow and messy, new-fangled crap
Well, they are...
Brady Kelly wrote:
despite being a few years younger than me.
He is wise beyond his years...
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001He doesn't know anything about those concepts, including the fact that data annotations, although being compiled into your binary, may still be overridden in any way you see fit. He also seemed to think that ORM's are all constrained to always use grossly inefficient queries, e.g. pulling all rows from the server then filtering them and so on. I understand his point that his code-base is too critical to business ops to to allow for trying out these new things if the old things are already working, but that reminds me of a story about some wet monkeys in a cage[^].
-
So this guy asks me what what my general exception handling policy is. Log the exception and allow it to propagate. OK, what would I do to avoid the system crashing and the end user sitting staring helpless at an error message, unable to do business? What could I answer? Redundancy, parallel systems? No, the system you are currently running crashes. Oh, user friendly error message, error must be logged and developers notified. I mean, really, on a system coded and tested properly, you can't really do much more. Some people are never happy.
Brady Kelly wrote:
So this guy asks me what what my general exception handling policy is.
My standard answer is: I don't write code that throws exceptions. I guess you guys do, so how do YOU handle your buggy code? Marc
-
Brady Kelly wrote:
even if he does consider model validation, data annotations, and ORM's to be slow and messy, new-fangled crap
Well, they are...
Brady Kelly wrote:
despite being a few years younger than me.
He is wise beyond his years...
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001John Simmons / outlaw programmer wrote:
Brady Kelly wrote: even if he does consider model validation, data annotations, and ORM's to be slow and messy, new-fangled crap Well, they are...
Are you saying that you don't believe in data validation?
John Simmons / outlaw programmer wrote:
Brady Kelly wrote: despite being a few years younger than me. He is wise beyond his years...
Or just clueless.
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
As I said in this interview, frustration is part of the job of development, compared to other jobs where the same actions give the same results fairly reliably. It's not whether you get frustrated or not, but how you react when you inevitably do get frustrated.
-
Brady Kelly wrote:
So this guy asks me what what my general exception handling policy is.
My standard answer is: I don't write code that throws exceptions. I guess you guys do, so how do YOU handle your buggy code? Marc
Good answer, if I wasn't in the formal context of a job interview I would have used it. If something results in an exception on prodcution, there is really nothing you can do except to spare the user the Yellow Screen of Death. If you need to handle 'special' exceptions, then your code needs work. If your infrastructure guys set you up the bomb, then the end user still can't use your app.
-
Good answer, if I wasn't in the formal context of a job interview I would have used it. If something results in an exception on prodcution, there is really nothing you can do except to spare the user the Yellow Screen of Death. If you need to handle 'special' exceptions, then your code needs work. If your infrastructure guys set you up the bomb, then the end user still can't use your app.
Brady Kelly wrote:
If something results in an exception on prodcution, there is really nothing you can do except to spare the user the Yellow Screen of Death.
Even that isn't enough for some people. Had a user last week get an error. The way I handle exceptions is to show a Whoops screen to the user letting them know that the problem has been reported to the appropriate person (me). And I get the email containing the YSOD plus a bunch of other error info. Whatever. This user then proceeds to try again...20 times. Same thing over and over and over, like he expects it to magically start working if he keeps entering the same data and hitting the submit button.
-
Eric Xue (brokensnow) wrote:
that's kind of question we pretty much asking ourselves on the daily-basis
Me too, but it's kind of a given in software development, something I do almost intuitively. When I'm asked to verbalise it, unless I can sit down and give it some concious thought, I find the request a little difficult. The rest of the interview was quite pleasant though, more discussion than interrogation. I think I would really enjoy working with the guy, even if he does consider model validation, data annotations, and ORM's to be slow and messy, new-fangled crap, despite being a few years younger than me.
Slow and messy during runtime or dev time? Because computers are way faster than programmers, and programmer time is a lot more expensive...
-
Brady Kelly wrote:
If something results in an exception on prodcution, there is really nothing you can do except to spare the user the Yellow Screen of Death.
Even that isn't enough for some people. Had a user last week get an error. The way I handle exceptions is to show a Whoops screen to the user letting them know that the problem has been reported to the appropriate person (me). And I get the email containing the YSOD plus a bunch of other error info. Whatever. This user then proceeds to try again...20 times. Same thing over and over and over, like he expects it to magically start working if he keeps entering the same data and hitting the submit button.
GenJerDan wrote:
This user then proceeds to try again...20 times. Same thing over and over and over, like he expects it to magically start working if he keeps entering the same data and hitting the submit button.
He's punishing you (the error report recipiant) for writing code that crashed :) Actually, he's just mad and frustrated. Too bad there's nothing you can do for him that won't make the next time even worse.
patbob
-
So this guy asks me what what my general exception handling policy is. Log the exception and allow it to propagate. OK, what would I do to avoid the system crashing and the end user sitting staring helpless at an error message, unable to do business? What could I answer? Redundancy, parallel systems? No, the system you are currently running crashes. Oh, user friendly error message, error must be logged and developers notified. I mean, really, on a system coded and tested properly, you can't really do much more. Some people are never happy.
Don't you love rhetorical questions from managers who have nothing better to do than to dream up questions like that ?
-
GenJerDan wrote:
This user then proceeds to try again...20 times. Same thing over and over and over, like he expects it to magically start working if he keeps entering the same data and hitting the submit button.
He's punishing you (the error report recipiant) for writing code that crashed :) Actually, he's just mad and frustrated. Too bad there's nothing you can do for him that won't make the next time even worse.
patbob
It's nice to see that the dev community hasn't lost sight of the need to serve the customer ;P
-
Slow and messy during runtime or dev time? Because computers are way faster than programmers, and programmer time is a lot more expensive...
Funny how end-user time is never considered in that equation :) ?
-
So this guy asks me what what my general exception handling policy is. Log the exception and allow it to propagate. OK, what would I do to avoid the system crashing and the end user sitting staring helpless at an error message, unable to do business? What could I answer? Redundancy, parallel systems? No, the system you are currently running crashes. Oh, user friendly error message, error must be logged and developers notified. I mean, really, on a system coded and tested properly, you can't really do much more. Some people are never happy.
I try to follow the rule "Never catch an exception you can't handle" although I do have catch blocks that add context and rethrow. When an unhandleable exception reaches the user, apologise, generate a report (crash dump, log file etc), and exit cleanly. What else could you do?
-
So this guy asks me what what my general exception handling policy is. Log the exception and allow it to propagate. OK, what would I do to avoid the system crashing and the end user sitting staring helpless at an error message, unable to do business? What could I answer? Redundancy, parallel systems? No, the system you are currently running crashes. Oh, user friendly error message, error must be logged and developers notified. I mean, really, on a system coded and tested properly, you can't really do much more. Some people are never happy.
This is more like a question for a politician who just needs to keep the conversation going aimlessly. There is no solution for system crash. Otherwise, we'll not have the term "blue screen of death". One exception is that if crash happens very often whenever your software is running, it is an indication that your software has an issue.
TOMZ_KV
-
So this guy asks me what what my general exception handling policy is. Log the exception and allow it to propagate. OK, what would I do to avoid the system crashing and the end user sitting staring helpless at an error message, unable to do business? What could I answer? Redundancy, parallel systems? No, the system you are currently running crashes. Oh, user friendly error message, error must be logged and developers notified. I mean, really, on a system coded and tested properly, you can't really do much more. Some people are never happy.
It depends on the systems requirements of couse. If the system is required to reset itself automatically if a fatal exception is caused logging an error message then that is how I will build it to be. Maybe the system requires a transfer to second 'parallel' system in the case of a fatal failure. A thing that I will look at is the fatality of the various exceptions that can be caused and structure is accordingly. At the end of the day any exception handling depends on the system requirements (what does the customer want).
-
Brady Kelly wrote:
even if he does consider model validation, data annotations, and ORM's to be slow and messy, new-fangled crap
Well, they are...
Brady Kelly wrote:
despite being a few years younger than me.
He is wise beyond his years...
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001ORM's provide functinality using code that you (or your dev team) didn't have to write nor (directly) maintain. For that, they have thier benefit IMHO. ORM's are not the answer for all situations, but to call a technology/framwork 'crap' shows that he is not objective.
-
So this guy asks me what what my general exception handling policy is. Log the exception and allow it to propagate. OK, what would I do to avoid the system crashing and the end user sitting staring helpless at an error message, unable to do business? What could I answer? Redundancy, parallel systems? No, the system you are currently running crashes. Oh, user friendly error message, error must be logged and developers notified. I mean, really, on a system coded and tested properly, you can't really do much more. Some people are never happy.
It also depends what exception was thrown and why. Is it something that means the end of the world, or just some recoverable program error? System calls can throw exceptions that aren't fatal, just an indication of a problem you can maybe deal with. I have lots of try / catch blocks in my code. And languages like Ada expect exceptions from the language defined runtimes...