Interview pro-tip
-
@julmu said:
@Severity One said:
Remember, they are under stress, and the infinite loop is a pretty stupid thing to do.
If they're applying for a senior developer position then they should have the ability to fix stupid things under stress. The clients won't care how stupid the cause of a critical bug is -- they just want that bug fixed as soon as possible.
Plus, they already have been given the hint that there's a bug in the code.
-
@julmu said:
If they're applying for a senior developer position then they should have the ability to fix stupid things under stress. The clients won't care how stupid the cause of a critical bug is -- they just want that bug fixed as soon as possible.
Who said it was a senior position? Other than that, it's a completely artificial situation. I have fixed ciritcal (or perhaps even stupid) bugs under time pressure, but none that even remotely resemble the interview question. It's difficult to gauge a candidate's prowess, and so you need to resort to artificial questions, but the point I was trying to make (and which you completely miss by picking this exact question from my post) is that it's a bit more complex than one might assume, and what appears clear to whoever wrote the question, may not be clear at all to somebody else, for whatever reason.The interviewer blames it on stupid candidates; I'd be tempted to lay part of the blame on a lack of empathy and lack of preparation on the part of the interviewer.
-
@boomzilla said:
@dhromed said:
But does "larger brain area" generally mean "more processing and correct outcomes" or "hyperactive"?
More likely, it's just phrenology dressed up with more modern measurements and small p-values.
Feh, kids today. If you're gonna do phrenology, just get out the calipers and do some phrenology. What's all this brain scan business...
-
@Severity One said:
It's difficult to gauge a candidate's prowess, and so you need to resort to artificial questions, but the point I was trying to make (and which you completely miss by picking this exact question from my post) is that it's a bit more complex than one might assume, and what appears clear to whoever wrote the question, may not be clear at all to somebody else, for whatever reason.
The question was aimed at noticing that the while loop either executed its body infinitely or not at all. I've never had to fix something like that in a critical, time sensitive manner, but I've certainly done something like that accidentally. And I've come across it many times (though the loop was usually more complex than this one). It may not be an immediate disqualification, but it's far from a complex problem.
I can see a forum member skimming it an not noticing the issue, but it seems like a pretty reasonable question when interviewing a candidate for C# development. There's pretty much nothing that you could ask in an interview that someone, perfectly qualified, isn't capable of messing up. That's a given, but it's not a reason not to use a question like this, which is pretty straightforward (i.e., not a trick question like a Nagesh troll).
-
@boomzilla said:
The question was aimed at noticing that the while loop either executed its body infinitely or not at all. I've never had to fix something like that in a critical, time sensitive manner,
That's part of the point, though. This problem would have been noticed when running in the debugger or from a unit test approximately 50 years before it ever hit an actual end-user.
The reason it's a bad interview question, IMO, is that interviewers usually don't get the tools of the trade-- that is, most of the time, the interviewer doesn't hand them a computer with IDE. The correct answer to a question like this is, "well, turn on the debugger and let's step through it." That's the developer you want to hire.
-
@boomzilla said:
@dhromed said:
But does "larger brain area" generally mean "more processing and correct outcomes" or "hyperactive"?
More likely, it's just phrenology dressed up with more modern measurements and small p-values.
Hey, they are small. It has to mean something!
But no, boomzilla, brain areas mean sh*t. You can use it to find a differentiation between tasks that doesn't have a direct behavioral translation (think of something like: difficulty roughly translates to reaction time), but there is no simple relation between brain areas and something like function (speech, face recognition, moving your left thumb) or intelligence. Heck, there isn't even a definition of intelligence.
-
@TGV said:
eck, there isn't even a definition of intelligence.
Gasp! You mean... cfgauss might be wrong? But he's a STRING THEORIST! And he knows some guy who went to South America! Unpossible.
-
@blakeyrat said:
The reason it's a bad interview question, IMO, is that interviewers usually don't get the tools of the trade-- that is, most of the time, the interviewer doesn't hand them a computer with IDE. The correct answer to a question like this is, "well, turn on the debugger and let's step through it." That's the developer you want to hire.
I get your point, and I think it's valid to an extent, but if you are completely dependent on stepping though code like this in order to spot such a simple bug then I wouldn't want to work with you. It also implies that your output would likely be worthless for anything without complete testing.
And it indicates that the dev's critical thinking capability is low or at least relatively disengaged. Probably small brain areas.
-
@boomzilla said:
I get your point, and I think it's valid to an extent, but if you are completely dependent on stepping though code like this in order to spot such a simple bug then I wouldn't want to work with you.
Code like this that SOMEONE ELSE WROTE? I think you're being unfair. My mental "code is correct" detectors only work on code I wrote, because the very way that I write it eliminates some bugs. (To give an example, I always type opening and closing braces at the same time.) My "code is correct" detector wouldn't flag this function because it's written in a way that I'd never personally write it.
But even if I debugged all my own code by stepping through it with the debugger (which I do, that is in fact the point of the fucking thing), why would that make me undesireable to work with? Because you use "sophisticated" open source tools which almost invariably lack useful debuggers? Because you hate useful tools? What's the reason?
@boomzilla said:
It also implies that your output would likely be worthless for anything without complete testing.
That's true of every programmer working on every project, and you're a moron if you think otherwise.
-
@Severity One said:
Who said it was a senior position? Other than that, it's a completely artificial situation. I have fixed ciritcal (or perhaps even stupid) bugs under time pressure, but none that even remotely resemble the interview question. It's difficult to gauge a candidate's prowess, and so you need to resort to artificial questions, but the point I was trying to make (and which you completely miss by picking this exact question from my post) is that it's a bit more complex than one might assume, and what appears clear to whoever wrote the question, may not be clear at all to somebody else, for whatever reason.
The interviewer blames it on stupid candidates; I'd be tempted to lay part of the blame on a lack of empathy and lack of preparation on the part of the interviewer.
I quoted only the sentence that I objected to. The other sentences in that paragraph referred to reasons why one would miss such bugs and I agreed with those so I didn't see a reason to quote those extranously.
If you haven't seen stupid code in you line of work then consider yourself lucky for having decent predecessors and co-workers. Just have a look at the Code SODs on the main page or any representative line threads in this forum and you'll see that not everyone is so lucky.
Neither of us know which position the interview was for.
I did mention the position I was talking about so people would know that I don't think that it applies to all positions.
You didn't, so I was under the impression that you consider stress endurance an unimportant ability for all developers.It's true that in real life developers are usually given the symptoms of the bug and not the exact function that is wrong.
So you would get a bug report saying "program keeps on printing the first line of the file on to the screen" which would make it easier to figure out the cause.
But in real life there are also bugs which aren't hidden in a single five line function and which don't happen always but still need to be fixed so it kind of balances out the bug.
We all have our bad days so I didn't mean to imply that you're a bad programmer if you didn't see the bug in the given code.
I don't think that somebody getting a job or not should be decided based on a single question but if they didn't do particularly well on other questions either then I don't think you can blame the interviewer for the candidate's bad day.
-
@blakeyrat said:
@boomzilla said:
I get your point, and I think it's valid to an extent, but if you are completely dependent on stepping though code like this in order to spot such a simple bug then I wouldn't want to work with you.
Code like this that SOMEONE ELSE WROTE? I think you're being unfair. My mental "code is correct" detectors only work on code I wrote, because the very way that I write it eliminates some bugs. (To give an example, I always type opening and closing braces at the same time.) My "code is correct" detector wouldn't flag this function because it's written in a way that I'd never personally write it.Yes, code that someone else wrote. I deal with other people's code all the time, as does anyone who has worked on a team. And code that I wrote in the past and haven't looked at recently might as well have been written by someone else. Your "code is correct" detector seems overly simplistic. If you mean, "see the bug at a glance," then I'd agree with you, as this function seems reasonably laid out. But again, after being told to find a bug, not being able to spot this makes you seem incompetent.
@blakeyrat said:
But even if I debugged all my own code by stepping through it with the debugger (which I do, that is in fact the point of the fucking thing), why would that make me undesireable to work with?
Stepping through all of your code after the fact and being unable to detect simple bugs like the one presented are different things. An inability to spot something that simple gives the impression that you don't really understand what you're doing. You probably throw code together and change things until they appear to work, at least in the test case that you choose to use. We're all familiar with this sort of dev, and missing this bug would be a red flag to me that you might be that sort of person.
@blakeyrat said:
Because you use "sophisticated" open source tools which almost invariably lack useful debuggers? Because you hate useful tools? What's the reason?
Uh, no. All of the stuff I regularly code in have useful debuggers. But that doesn't mean that I turn off my brain and outsource my thinking to my tools, which is what you seem to be arguing.
@blakeyrat said:
@boomzilla said:
It also implies that your output would likely be worthless for anything without complete testing.
That's true of every programmer working on every project, and you're a moron if you think otherwise.I'll forgive the pedantic dickweedery here and instead elaborate. You will not be able to anticipate the ways in which your code fails. Your code (levels of testing being equal) will fail more often than other devs' code, and will require a lot more rework. Of course, "complete testing" is a goal, not something that generally happens. Maybe there are places where this isn't important and the money flows freely, but it's not where I work.
-
@blakeyrat said:
The reason it's a bad interview question, IMO, is that interviewers usually don't get the tools of the trade-- that is, most of the time, the interviewer doesn't hand them a computer with IDE. The correct answer to a question like this is, "well, turn on the debugger and let's step through it." That's the developer you want to hire.
I agree that eyeing down code without an IDE is not realistic scenario, but I disagree about the use of a debugger. In my opinion, stepping through code with a debugger should only be done as an absolute last resort, when all other methods have failed. I have two principle reasons: 1) you're looking at the code too closely, and 2) you should be logging the execution.
1) Stepping through code is slow, much much slower than mentally tracing through the flow of execution. Using a debugger in this manner keeps you slow in the same way that using a calculator for simple arithmetic dulls your mental math abilities. Instead of whipping out the calculator for every equation, you should be able to quickly estimate and keep going. You should be able to step through the code yourself without a debugger to hold your hand. Debuggers tends to dunk you into an ocean of detail that is at the wrong level of abstraction to see bugs, unless the bug is something really braindead. For example, if you forget to initialize an object or verify some resource's availability, you won't see it in the debugger, because the debugger can only show you what you didn't forget. I'm not saying it wouldn't help identify the problem, rather, they're the wrong tool for the job. Debuggers are like a magnifying glass. For difficult bugs, I can't ever remember when inspecting the details of bad code resulted in finding the problem. Instead, what you really need to do is step back from the code and look at the big picture. A programmer's dependency of a debugger inhibits the reaction to do this. It's like saying, "the wind ripped our tent apart ... get out the loupe and let's look for the stitch that failed," instead of "this whole threading model is crap!"
2) If the code execution is too tricky/clever/challenging for this approach, then start inserting logging statements. This way, not only do you have a log of the execution (which you should be generating anyway!!), next time you need to trace through the code, you'll already have the signposts written. Otherwise, you have to fire up the debugger and step through everything yet again. Disciplined use of logging allows you to skip right to problem areas without wasting time working through the functioning code first. Instead of wondering why your application is repeatedly opening and closing connections to your database, you should be able look at the the logs, note that the "pool.maxconnections" setting was never set and inadvertently interpreted as zero in your program, and fix it right away. (That actually happened recently to me.)
I'd like to say I hold these opinions from experience. I used to use the debugger much more often than I do now, until I realized just how much it slows me down compared to my own tracing. And then, after observing the newguy debug his programs, I practically banned him from using it. The programs he wrote were NOT that complicated, and most of the time the stacktrace was more than enough to figure out the problem. ("This variable is null. Yes, it's this one, because it's the only one on that line which you are dereferencing. No, don't use the debugger, follow the code back to where it was initialized. Oh, it wasn't initialized? Well there's your problem.")
Then there's the matter of logging code execution, which I fervently believe in. If the code isn't telling me what it's doing while it's doing it, then it's not getting past my QA. Log every major transaction, every major IO block, every major external resource allocation (database connection, critical file reads, etc), then log the result of these attempts. Log your settings before you use them, and user inputs after you receive them. Log calls into ill-supported third-party modules. Log what is important, and nothing less. If the logging slows down your code, then you've chosen that criteria unwisely. If you're insane, you can suppress the logging in production where it matters the most. But no matter what, log in development, and the code execution will become so clear that the mental crutch of debuggers will be totally unneeded.
-
@boomzilla said:
But again, after being told to find a bug, not being able to spot this makes you seem incompetent.
I never stated whether or not I spotted the bug. I only said I think it's a bad interview question.
Not that you've ever actually read the text that I type-- for a few minutes there I almost forgot you were Boomzilla. Foolish me.
@boomzilla said:
Uh, no. All of the stuff I regularly code in have useful debuggers. But that doesn't mean that I turn off my brain and outsource my thinking to my tools, which is what you seem to be arguing.
I don't think of it as "turning off my brain"*, I think of it as "allowing me to forget about all the bullshit involved in programming and focus on the actual problem I'm solving.
*) Mostly because that's fucking retarded. "I'm an auto mechanic, but I don't use a torque wrench because I think it 'turns off my brain' if I don't just go by feel." Idiot.
@boomzilla said:
I'll forgive the pedantic dickweedery here and instead elaborate.
What pedantic dickweedery?
-
@Xyro said:
1) Stepping through code is slow, much much slower than mentally tracing through the flow of execution.
Then you're either using it wrong, or dealing with one of those shitty open source debuggers I've been talking about. You use conditional breakpoints at the suspected trouble-points, you add/remove breakpoints as its running and make judicious use of the "Play" and "Pause" buttons, you set watch values for your variables likely to have issues.
You don't just shove a breakpoint at the topmost line and click "Step Into" 47,000 times, which is what it sounds like you think "use the debugger" means.
@Xyro said:
Then there's the matter of logging code execution, which I fervently believe in. If the code isn't telling me what it's doing while it's doing it, then it's not getting past my QA. Log every major transaction, every major IO block, every major external resource allocation (database connection, critical file reads, etc), then log the result of these attempts. Log your settings before you use them, and user inputs after you receive them. Log calls into ill-supported third-party modules. Log what is important, and nothing less. If the logging slows down your code, then you've chosen that criteria unwisely. If you're insane, you can suppress the logging in production where it matters the most. But no matter what, log in development, and the code execution will become so clear that the mental crutch of debuggers will be totally unneeded.
So your log file is twice as large as the data your program is operating on?
-
@blakeyrat said:
@boomzilla said:
But again, after being told to find a bug, not being able to spot this makes you seem incompetent.
I never stated whether or not I spotted the bug. I only said I think it's a bad interview question.True, I was responding to what you asserted was the "correct" answer, which amounted to not even looking at the code without a debugger. I should really have used "the candidate" or "the developer" instead of you, but I guess I got lazy.
@blakeyrat said:
Not that you've ever actually read the text that I type-- for a few minutes there I almost forgot you were Boomzilla. Foolish me.
Based on the inconsistency of your responses, I suspect that I read your posts more closely than you do, which never ceases to amuse me.
@blakeyrat said:
I don't think of it as "turning off my brain"*, I think of it as "allowing me to forget about all the bullshit involved in programming and focus on the actual problem I'm solving.
*) Mostly because that's fucking retarded. "I'm an auto mechanic, but I don't use a torque wrench because I think it 'turns off my brain' if I don't just go by feel." Idiot.
What a stupid analogy. It's more like noticing the missing bolt instead of driving around until you find a problem.
@blakeyrat said:
@boomzilla said:
I'll forgive the pedantic dickweedery here and instead elaborate.
What pedantic dickweedery?Focusing on "complete testing" instead of the actual topic at hand, which was that you were arguing against spotting bugs by any means other than actually running the code under a debugger. So in this case, instead of dealing with the actual argument, you picked out an over generalized statement that any normal person would have understood to be peripheral to the issue, and then only focusing on that peripheral issue. Like the recent ellipsis discussion.
-
@boomzilla said:
Focusing on "complete testing" instead of the actual topic at hand, which was that you were arguing against spotting bugs by any means other than actually running the code under a debugger.
I'm sorry, when did I do that?
-
@blakeyrat said:
Then you're either using it wrong, or dealing with one of those shitty open source debuggers I've been talking about. You use conditional breakpoints at the suspected trouble-points, you add/remove breakpoints as its running and make judicious use of the "Play" and "Pause" buttons, you set watch values for your variables likely to have issues.
No ... no, that's pretty much exactly what I'm talking about. Instead of breakpoints, I'd highly recommend logging statements.@blakeyrat said:
So your log file is twice as large as the data your program is operating on?
Much larger, in fact!! I deal with millions of tiny (usually less than 10kB, often less than 1kB) and concurrent transactional messages that must be delivered in realtime before a short expiry. I try to use clear, unambiguous, and grammatically correct English in my logs, so they're often many, many, many times larger than the input data. I consider that a feature.When things go wrong, they go really really wrong. When things don't go wrong, we are often blamed anyway because we're in the middle. Logging is crucial to debugging, profiling, ... and CYA.
It's not uncommon to receive a ticket complaining that things are unquantifiably "slow". So I check out the log files...[...] 2012-07-09 12:38:18,607 DEBUG [main/XXXConnectionBase]: Got (and committed) message from [proprietary queue]. 2012-07-09 12:38:18,607 DEBUG [Worker-36/PerformTransaction]: Received message: [proprietary message head] 2012-07-09 12:38:18,607 DEBUG [Worker-36/PerformTransaction]: Message payload: [parsed message of proprietary payload] 2012-07-09 12:38:18,607 DEBUG [Worker-36/PerformTransaction]: XXX settings: [a dump of the proprietary transmission settings] 2012-07-09 12:38:18,608 DEBUG [Worker-36/PerformTransaction]: Sending message to backend... 2012-07-09 12:38:18,652 DEBUG [Worker-36/XXXSocketTransaction]: Sending [proprietary headshake protocol] 2012-07-09 12:38:18,746 DEBUG [Worker-36/PerformTransaction]: XXX socket call complete. 2012-07-09 12:38:18,747 DEBUG [Worker-36/PerformTransaction]: Sending reply: [proprietary reply] 2012-07-09 12:38:18,747 DEBUG [Worker-36/PerformTransaction]: Using these XXX reply settings: [a dump of the proprietary reply settings] 2012-07-09 12:38:18,748 DEBUG [Worker-36/XXXConnection]: Connected to [proprietary queue manager]. 2012-07-09 12:38:18,748 DEBUG [Worker-36/XXXConnection]: Queue [proprietary queue] has been opened. 2012-07-09 12:38:18,749 DEBUG [Worker-36/XXXConnectionBase]: Put (and committed) message on [proprietary queue]. [...]
No problems here. Check your own application!
-
@blakeyrat said:
@boomzilla said:
Focusing on "complete testing" instead of the actual topic at hand, which was that you were arguing against spotting bugs by any means other than actually running the code under a debugger.
I'm sorry, when did I do that?You should read your own posts. Here's where you made the point originally:
@blakeyrat said:The correct answer to a question like this is, "well, turn on the debugger and let's step through it." That's the developer you want to hire.
On a slightly different note...I haven't used VS's debugger with C#, but I could imagine a debugger, especially when you compile with optimizations turned on, that would optimize out the condition checking in the loop, so stepping though with the debugger would just stay on that line. And the sort of developer who required a debugger to find this sort of thing might also be the sort who would think the debugger was broken, because he's often the sort who thinks that the problem is more likely in someone else's code than his own.
-
@boomzilla said:
@blakeyrat said:
@boomzilla said:
Focusing on "complete testing" instead of the actual topic at hand, which was that you were arguing against spotting bugs by any means other than actually running the code under a debugger.
I'm sorry, when did I do that?You should read your own posts. Here's where you made the point originally:
@blakeyrat said:The correct answer to a question like this is, "well, turn on the debugger and let's step through it." That's the developer you want to hire.
Uh. Those are two completely different statements.
@boomzilla said:
On a slightly different note...I haven't used VS's debugger with C#, but I could imagine a debugger, especially when you compile with optimizations turned on, that would optimize out the condition checking in the loop, so stepping though with the debugger would just stay on that line.
So you could imagine something, and you're making hiring decisions based on that? Guess what? I can imagine broken-ass debuggers also. I have no fucking clue what the shit that has to do with this discussion.
-
@blakeyrat said:
Those are two completely different statements.
I'm sorry. I guess I'll stop attempting to communicate with you using multiple sentences that relate to each other.
@blakeyrat said:
So you could imagine something, and you're making hiring decisions based on that? Guess what? I can imagine broken-ass debuggers also. I have no fucking clue what the shit that has to do with this discussion.
Imagine a place where people wrote about their ideas. And sometimes, one idea leads to another. Then that idea gets written about. Someone else has another idea based on an earlier idea and writes about it. Then someone complains that the last idea is different from the previous. Now you've imagined this thread. Sorry for the multiple sentences. I tried to keep them short.
-
@dhromed said:
@Speakerphone Dude said:
@Science People said:
People with self-reported liberal views tended to have a larger anterior cingulate cortex -- a brain area involved in processing conflicting information. And those with conservative views were more likely to have a larger amygdala -- a region important for recognizing threats.
More info (speaker warning: video clip is on autoplay)
But does "larger brain area" generally mean "more processing and correct outcomes" or "hyperactive"?
Because it seems like the latter; since conservative views correlate with seeing threats everywhere (terrorists! aaah! gays! aaah!) and being generally fearful of the world at large (also somehow believing that this is not a tiresome and unproductive state of being).
And does my apparently enlarged cingulate cortext mean I'm more accepting of bullshit, or less?
probably more.
:\
If you need conflicting information remind yourself that those Liberals you identify with are backing the MPAA and other anti-American lobbies that put you at legal risk whenever you use "free" p2p content. Also the banks they support destroyed the economy and the poison of their biotech friends is causing more cancers, creating new poor sick people for kind souls to obamacare for, which is a boost for pills pushers and insurance companies (more Liberals lobbies). Bunch of evil wallet rapists sitting on top of well-meaning folks.
-
@Speakerphone Dude said:
Liberals, all of yous. Says the study:
@Science People said:
People with self-reported liberal views tended to have a larger anterior cingulate cortex -- a brain area involved in processing conflicting information. And those with conservative views were more likely to have a larger amygdala -- a region important for recognizing threats.
It's a professor in a white coat. He uses an expensive machine. IT MUST BE TRUE!
Repeat after me: I am a liberal. I am a liberal.
-
@blakeyrat said:
@TGV said:
eck, there isn't even a definition of intelligence.
Gasp! You mean... cfgauss might be wrong? But he's a STRING THEORIST! And he knows some guy who went to South America! Unpossible.
OMG, I read, er, scanned, the thread, and you just bulled the guy off. It was the last thing he wrote on this forum. But now that I think about it, he didn't write anything before that either. The name ... it was probably your alter ego. Or that of one of the other highly productive writers on this forum. If you're not all one and the same.
-
@TGV said:
OMG, I read, er, scanned, the thread, and you just bulled the guy off. It was the last thing he wrote on this forum.
Yeah I feel kind of bad about that.
-
@julmu said:
I quoted only the sentence that I objected to. The other sentences in that paragraph referred to reasons why one would miss such bugs and I agreed with those so I didn't see a reason to quote those extranously.
And in doing so, you completely missed the thing called 'context'.@julmu said:
If you haven't seen stupid code in you line of work then consider yourself lucky for having decent predecessors and co-workers.
Ha ha ha! You're funny. In fact, I'm the one responsible for maintaining coding standards, including things like static source code analysis (you'd be surprised how many bugs you find that way) and such, but without the authority to actually inflict corporal punishment on my co-workers for breaching the rules. And I didn't have time either. I hope I won't have to explain what happened when we decided to change the 'numberOfThreads' configuration parameter in a rather complex application written by a developer (I'm using the phrase loosely here) with a preference for static fields.This will be solved by taking away the option for developers to deliver their own archives to the support people (who deploy our applications). Instead, there will be a Netbeans → Subversion → Jenkins CI (continuous integration server) → Artifactory (Maven repository manager) → Netbeans cycle. Unit tests and static source code analysis are run by the CI server, and the results e-mailed to me. I'm currently on the look-out for a cane, like they used (use?) in British public schools.
@julmu said:
Neither of us know which position the interview was for.
Which makes it all the more surprising why you came up with the senior position. Nobody else did.@julmu said:
I did mention the position I was talking about so people would know that I don't think that it applies to all positions. You didn't, so I was under the impression that you consider stress endurance an unimportant ability for all developers.
You lost me there. But what's this obsession with stress? Most of my job is stress-free. If you are under stress for more than 10% of your time as a developer, you're doing something wrong. Either you're unfit for your position, or your employers have horns on their head and insisted that you sign the contract with your own blood.@julmu said:
It's true that in real life developers are usually given the symptoms of the bug and not the exact function that is wrong. So you would get a bug report saying "program keeps on printing the first line of the file on to the screen" which would make it easier to figure out the cause.
Which brings us back to my contention that this is a completely artificial question.@julmu said:
But in real life there are also bugs which aren't hidden in a single five line function and which don't happen always but still need to be fixed so it kind of balances out the bug.
In real life, this would never have made it past alpha testing, unless your company is run by Shaun the Sheep.@julmu said:
We all have our bad days so I didn't mean to imply that you're a bad programmer if you didn't see the bug in the given code.
I should bloody hope that you didn't mean to imply that, because I'm pretty much the rockstar kind of programmer, including the long hair. And no, not the kind of rockstar whose body is found in a hotel room at age 21 after he'd OD-ed on some contained substance, or one that would grace the pages of this venerable web site.As other have pointed out before me, the way we write code means that such silly mistakes as in the interview question would never happen. As soon as you write a loop, you have to ask yourself: what is the invariant? Or at the very least, how will the loop end? It took me two full seconds to see the bug because my brain simply doesn't work that way. And if I hadn't been told that there was an infinite loop, it might even have taken me longer.
@julmu said:
I don't think that somebody getting a job or not should be decided based on a single question but if they didn't do particularly well on other questions either then I don't think you can blame the interviewer for the candidate's bad day.
A day made much worse by a bad question, or at the very least, a bad interpretation of the answer. Basically, candidates get punished for the interviewer's lack of understanding that perception works differently between people, and between situations.
-
@Severity One said:
@julmu said:
I quoted only the sentence that I objected to. The other sentences in
And in doing so, you completely missed the thing called 'context'.
that paragraph referred to reasons why one would miss such bugs and I
agreed with those so I didn't see a reason to quote those extranously.@julmu said:
If you haven't seen stupid code
Ha ha ha! You're funny. In fact, I'm the one responsible for maintaining coding standards, including things like static source code analysis (you'd be surprised how many bugs you find that way) and such, but without the authority to actually inflict corporal punishment on my co-workers for breaching the rules. And I didn't have time either. I hope I won't have to explain what happened when we decided to change the 'numberOfThreads' configuration parameter in a rather complex application written by a developer (I'm using the phrase loosely here) with a preference for static fields.
in you line of work then consider yourself lucky for having decent
predecessors and co-workers.This will be solved by taking away the option for developers to deliver their own archives to the support people (who deploy our applications). Instead, there will be a Netbeans → Subversion → Jenkins CI (continuous integration server) → Artifactory (Maven repository manager) → Netbeans cycle. Unit tests and static source code analysis are run by the CI server, and the results e-mailed to me. I'm currently on the look-out for a cane, like they used (use?) in British public schools.
@julmu said:
Neither of us know which position the interview was for.
Which makes it all the more surprising why you came up with the senior position. Nobody else did.@julmu said:
I did mention the position I was talking about so people would know that I don't think that it applies to all positions. You didn't, so I was under the impression that you consider stress endurance an unimportant ability for all developers.
You lost me there. But what's this obsession with stress? Most of my job is stress-free. If you are under stress for more than 10% of your time as a developer, you're doing something wrong. Either you're unfit for your position, or your employers have horns on their head and insisted that you sign the contract with your own blood.@julmu said:
It's true that in real life developers are usually given the symptoms of the bug and not the exact function that is wrong. So you would get a bug report saying "program keeps on printing the
Which brings us back to my contention that this is a completely artificial question.
first line of the file on to the screen" which would make it easier to
figure out the cause.@julmu said:
But in real life there are also bugs which aren't hidden in a single five line function and which don't happen always but still need to be fixed so it kind of balances out the bug.
In real life, this would never have made it past alpha testing, unless your company is run by Shaun the Sheep.@julmu said:
We all have our bad days so I didn't mean to imply that you're a bad programmer if you didn't see the bug in the given code.
I should bloody hope that you didn't mean to imply that, because I'm pretty much the rockstar kind of programmer, including the long hair. And no, not the kind of rockstar whose body is found in a hotel room at age 21 after he'd OD-ed on some contained substance, or one that would grace the pages of this venerable web site.As other have pointed out before me, the way we write code means that such silly mistakes as in the interview question would never happen. As soon as you write a loop, you have to ask yourself: what is the invariant? Or at the very least, how will the loop end? It took me two full seconds to see the bug because my brain simply doesn't work that way. And if I hadn't been told that there was an infinite loop, it might even have taken me longer.
@julmu said:
I don't think that somebody getting a job or not should be decided based on a single question but if they didn't do particularly well on other questions either then I don't think you can blame the interviewer for the candidate's bad day.
A day made much worse by a bad question, or at the very least, a bad interpretation of the answer. Basically, candidates get punished for the interviewer's lack of understanding that perception works differently between people, and between situations.Reading this is like watching a tennis match, but with no cute chick in miniskirt making loud moaning sounds when they smash.
-
@Speakerphone Dude said:
Reading this is like watching a tennis match, but with no cute chick in miniskirt making loud moaning sounds when they smash.
Just a couple of guys chasing after their own balls-- only to realize they only have one, and it's green and covered in fuzz.
-
@Lorne Kates said:
Just a couple of guys chasing after their own balls-- only to realize they only have one, and it's green and covered in fuzz.
It's funny because it's true!
-
True. Also did not see it immediatley. And in real-life you would probably know there is such a loop as the requested action will not complete and hence you will activley look for an infinite loop. I mean if you have a bug and know the code (wrote it yourself) I immediatley start thinking were the bug is most likely to occur and why and usually that helps a lot to actually find it.
-
@Severity One said:
So before critisising all those dumb candidates, perhaps you should review your question, think of all aspects of it (after all, you know that you're writing an infinite loop, and that's the answer that you expect), and perhaps give it to your co-workers; after all, they did make it through the selection process.
Who said he hadn't done that? If you're going to bitch at me for assuming things then don't assume anything yourself.@Severity One said:
Most of my job is stress-free. If you are under stress for more than 10% of your time as a developer, you're doing something wrong. Either you're unfit for your position, or your employers have horns on their head and insisted that you sign the contract with your own blood.
I live in the real world where there aren't enough good jobs for everybody so I have to settle for a job where I'm not given enough time to do fancy things like unit tests and static source code analysis.@Speakerphone Dude said:
Reading this is like watching a tennis match, but with no cute chick in miniskirt making loud moaning sounds when they smash.
So it's like a men's tennis match? Thanks for the compliment -- I do consider myself the Federer of posting on forums.
-
@julmu said:
so I have to settle for a job where I'm not given enough time to do fancy things like quality assurance
FTFY.
You may not have enough time to perform such activities - but if they're not performed then you run the risk of low code quality.
-
@Cassidy said:
@julmu said:
so I have to settle for a job where I'm not given enough time to do fancy things like quality assurance
FTFY.
You may not have enough time to perform such activities - but if they're not performed then you run the promise of low code quality.
FTFY. Sad to say, BTDT. It doesn't matter if your own code is flawless, either - you have coworkers. One of you will fail. Some years back, one of my coworkers left, and I inherited that particular promised bounty of low quality code. We had a code review process, at least, and it caught most of the really bad code. But, there are things that didn't go through the code review process. "Oh, this would be simple to just have cron run it from my home directory every day." "Oh, I'll be the only one to ever run this program, so I'll just stick it in my bin." So many tasks that fell into one of these categories. And the code behind them were all delightful, happy unicorns - at least, that's what I remember now, after many years of therapy. Or something like that.
-
@tgape said:
It doesn't matter if your own code is flawless, either - you have coworkers. One of you will fail.
I feel that code put into production without being reviewed first is a process failure itself.
- If the code is small then it shouldn't take too long to review it.
- If the code is large then there's a greater potential for error which reviews could uncover (and peers could benefit from discussing the choice of techniques used)
I also know that if code isn't reviewed now, it will always be reviewed when failure occurs to determine and locate the source of the defect so there are significant benefits to checking-before-releasing.
"let's waste an hour looking at the code now. It will save us a day of downtime later"
- If the code is small then it shouldn't take too long to review it.
-
@tgape said:
And the code behind them were all delightful, happy unicorns - at least, that's what I remember now, after many years of
Fixed your typo.therapydrinking.
-
@Mcoder said:
It may change with the definition of wrongness, but I think a freaking infinite loop would fit any definition you can come up with.
It depends what you're trying to do. I'm currently working on some code that reads a device, saves the value read, bumps the pointer and loops back to the beginning. There are no test conditions on the pointer and (seemingly) no way to break out of the loop. What's actually going on is that the code waits for the device to signal that it's ready with a character and when the transfer is completed, an interrupt occurs that fires us out of the loop and into the bit that does all the error checking.
The loop is necessarily tight because the device is firing out new bytes of data pretty quickly, and there's no time to mess about with comparisons.
-
@Mcoder said:
It may change with the definition of wrongness, but I think a freaking infinite loop would fit any definition you can come up with.
@Gordonjcp said:
when the transfer is completed, an interrupt occurs that fires us out of the loop
If there's some condition/event that causes it to exit the loop then the loop runs a finite number of times.. so it's not an infinite loop.
-
@Cassidy said:
If there's some condition/event that causes it to exit the loop then the loop runs a finite number of times.. so it's not an infinite loop.
So, the heat death of the universe means all loops are finite?I had a colleague who prefered to use "indefinitely repeatable loop".
