4 ms·
> I'm not fast at reasoning about code, and I often make trivial mistakes just trying to get a "first draft" of a program out. If I get behind or the interviewe
by adamzerner 5y ago
> I'm not fast at reasoning about code, and I often make trivial mistakes just trying to get a "first draft" of a program out. If I get behind or the interviewer starts interrupting to ask about the bad code I'm writing I get very stressed and have trouble both listening to the interviewer and trying to address the issues with the code.
Sounds to me that the author likes to program by "sketching". I do too! Paul Graham recommends this in Hackers and Painters.
> For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
>
> For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.
On the other hand, as the post describes, interviews are geared towards a more waterfall-y approach. I find this frustrating as well, but I think that there is something really important to keep in mind that this post misses, and that most conversations about coding interviews miss. The question is whether something is _predictive_ of job performance.
For example, consider the question "What is your favorite number?". Imagine that the larger the answer to that question, the more likely you are to perform well as a developer. You might object "But I'm never doing anything relevant to my favorite number on the job!". IMHO, it doesn't matter. The goal is to predict who will perform well on the job, and if having a large favorite number does this, it should be incorporated.
Now consider the question of how well you perform on waterfall-style interview questions. Like "What's your favorite number?", it isn't something that you will find yourself doing on the job. But that isn't the right question. The right question is whether or not it is predictive of job performance.
Of course, it seems unlikely that "What is your favorite number?" would predict job performance. And it seems unlikely that if you never code in a waterfall-style on the job, that coding in that style during an interview would predict job performance. But maybe it does. I'm skeptical, but who knows. More importantly, I think that this is the question that needs to be asked. And without strong data, it's hard to be too confident in the answer.
- jackblemming 5y ago>IMHO, it doesn't matter. The goal is to predict who will perform well on the job, and if having a large favorite number does this, it should be incorporated. What if it was skin color, how ethnic your name is, or your gender? Did you know the majority of developers are men? Should we throw all the female applications in the trash because they're statistically not as likely to be developers? Yeesh. Sorry if I sound hostile but... jeez. Correlation is not causation, etc etc.
- wiseowise 5y agoHow is skin color, ethical or gender are related to their point? > Should we throw all the female applications in the trash because they're statistically not as likely to be developers? What do you mean?
- ZephyrBlu 5y agoThe point is that top level comment talks about something being predictive of job performance. In this case, leetcode. What if skin colour, ethnicity or gender were highly predictive of job performance? It doesn't seem very ethical to judge candidates like this. I believe the GP is not convinced by the "all that matters is that it's predictive of job performance" idea.
- wiseowise 5y agoAnything else aside from whataboutisms?
- adamzerner 5y agoThings like skin color are different from things like leetcode ability. Looking through a veil of ignorance, I definitely would not want hiring decisions to be made based on the former. But looking through the same veil of ignorance, I would be ok with hiring decisions being made based on the latter. Well, actually, thinking about it again now, I'm not so sure. But this now becomes an ethical question. Which is certainly important. But I want to be clear that the ethical question is a different question from the question of what a purely self-interested company should do. To that self-interest question, I think the OP and lots of people argue that the answer is "leetcode-style questions having nothing to do with the job and are thus a bad idea". My claims are that 1) this is the wrong way to think about that self-interest question. The right way is to ask whether it is predictive of job performance. And 2) although I also suspect that leetcode-style questions aren't predictive, it's hard to be confident in that without good data.