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.
Frankly speaking, that's kind of question we pretty much asking ourselves on the daily-basis just simply because the end-users usually are the stakeholders for those projects we are delivering to. Just to share some my experience with you, there is no such system without any bug or along with a superior usability during my entire career. Plus the end-users never stop complaining about this or that no matter how prefect your software product is. As said, I can feel your pain but in reality, that's something we can't get away from on the daily-basis. :((
-
Frankly speaking, that's kind of question we pretty much asking ourselves on the daily-basis just simply because the end-users usually are the stakeholders for those projects we are delivering to. Just to share some my experience with you, there is no such system without any bug or along with a superior usability during my entire career. Plus the end-users never stop complaining about this or that no matter how prefect your software product is. As said, I can feel your pain but in reality, that's something we can't get away from on the daily-basis. :((
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.
-
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.
What the hell are you up so early on a Saturday morning?
-
What the hell are you up so early on a Saturday morning?
That time of the month - begging clients to either accept my work and pay me, or tell me what to change. I was in bed by 8pm last night.
-
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.
-
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.
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, 2001 -
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
