3 ms·

This is why interview code tests are... badly misguided. Most "fizzbuzz" screening is grossly artificial, denying one the feedback loops which are a critical el

This is why interview code tests are... badly misguided. Most "fizzbuzz" screening is grossly artificial, denying one the feedback loops which are a critical element of productivity, and without which one is relegated to spending time manual checking what automation does almost instantly. I rely heavily on the IDE reminding me of things, and quick compile/run cycles verifying correctness, rather than trying to think thru a myriad of special cases. Relegated to "whiteboard coding" interview questions, I'm left looking a whole lot worse than I am - not because I don't know it, but because I know enough that thoroughness is painfully slow (without leveraging tools multiplying my skills & speed).

darthdeus 10y ago
> This is why interview code tests are... badly misguided. Most "fizzbuzz" screening is grossly artificial, denying one the feedback loops which are a critical element of productivity, and without which one is relegated to spending time manual checking what automation does almost instantly. Do you really need to compile/run something like fizzbuzz? What if you're writing code that can't be run, such as when modifying a larger piece of code that won't run until all modifications are made? Isn't there some value in being able to verify correctness of code just by looking at it for a few seconds? Surely you can overlook some things, but with practice probably a lot less than people think.
userbinator 10y ago
I would argue that if you can't write a correct FizzBuzz without needing to compile and run it, or even worse, an IDE to hold your hand, you don't actually understand what's happening and are just leaning on a crutch. I rely heavily on the IDE reminding me of things, and quick compile/run cycles verifying correctness, rather than trying to think thru a myriad of special cases. The peril of that sort of workflow is that you often won't realise the importance of those special cases until it's too late to change things easily. "It looks like it works, it compiles and runs" --- I've heard this sentiment from such IDE users many times, and yet when I inspect their code, they inevitably missed something important. Someone once gave me a phrase I like to keep in mind when programming: "How can you tell the machine what to do if you're not even sure how to do it yourself?"
- lmm 10y ago
  All tools are crutches. I mean a good carpenter probably should be able to bash a nail in with a rock rather than a hammer, but that would be a crazy way to do interviews.
ctdonath 10y ago
"fizzbuzz" was the wrong example, picked for familiarity but understating intended complexity. Point was that forms of "whiteboard coding" completely overlook the point of the article.

darthdeus 10y ago

> This is why interview code tests are... badly misguided. Most "fizzbuzz" screening is grossly artificial, denying one the feedback loops which are a critical element of productivity, and without which one is relegated to spending time manual checking what automation does almost instantly. Do you really need to compile/run something like fizzbuzz? What if you're writing code that can't be run, such as when modifying a larger piece of code that won't run until all modifications are made? Isn't there some value in being able to verify correctness of code just by looking at it for a few seconds? Surely you can overlook some things, but with practice probably a lot less than people think.

userbinator 10y ago

I would argue that if you can't write a correct FizzBuzz without needing to compile and run it, or even worse, an IDE to hold your hand, you don't actually understand what's happening and are just leaning on a crutch. I rely heavily on the IDE reminding me of things, and quick compile/run cycles verifying correctness, rather than trying to think thru a myriad of special cases. The peril of that sort of workflow is that you often won't realise the importance of those special cases until it's too late to change things easily. "It looks like it works, it compiles and runs" --- I've heard this sentiment from such IDE users many times, and yet when I inspect their code, they inevitably missed something important. Someone once gave me a phrase I like to keep in mind when programming: "How can you tell the machine what to do if you're not even sure how to do it yourself?"

lmm 10y ago
All tools are crutches. I mean a good carpenter probably should be able to bash a nail in with a rock rather than a hammer, but that would be a crazy way to do interviews.

ctdonath 10y ago

"fizzbuzz" was the wrong example, picked for familiarity but understating intended complexity. Point was that forms of "whiteboard coding" completely overlook the point of the article.