3 ms·

"I’m suddenly self-conscious about the prettiness of my code — it doesn’t matter if I can solve the problem, since I’m also competing against candidates who can

by mockery 11y ago

"I’m suddenly self-conscious about the prettiness of my code — it doesn’t matter if I can solve the problem, since I’m also competing against candidates who can solve the problem, so the real competition is probably about how elegant and idiomatic our code is." This is an incorrect assumption, at least when I interview people. A live coding interview has (almost) nothing to do with the "quality" of your code, and doesn't necessarily even demand complete correctness. It's about observing your process, and trying to simulate what it would be like to work with you: Do you approach a problem with caution until you're sure you understand it, or jump in head first and start writing code you hope is correct? Can you verbalize your thought process and communicate it to others? How good are you at reasoning about the runtime behavior and correctness of your solution? Do you consider edge cases and naturally want to test them? Things like that are won't show up in a take-home coding test, and tell me a huge amount about what kind of programmer you are, and whether I want to hire you. See: http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer http://www.yacoset.com/Home/signs-that-you-re-a-bad-programm... - there's a lot of truth to this article, and many of these flaws will be glaringly obvious in a live coding session. And yes, of course some people interview poorly or are just having a bad day. That's unfortunate, but I'm not about to give up a powerful interview tool just because it can have false negatives. Until I find a divining rod that will point out the best programmer in a room, asking a candidate to write some code is the fastest way to learn what kind of programmer they actually are. (And also immediately weed out people who can't actually write real code.)

usaphp 11y ago
> "It's about observing your process, and trying to simulate what it would be like to work with you" But coding at an interview under stress and time pressure has nothing to do with a work process in a normal company, unless you also force your employees to work under stress and strict timelines with you sitting behind their shoulder and watching every keystroke...
celadon 11y ago
If you aren't prioritizing for code quality and beauty, do you also explicitly tell candidates that? I think it's very difficult for candidates to understand exactly what the interviewer wants—and, of course, all interviewers are different. I think that, for better or worse, many people worry that they need to perform perfectly during the interview and actually deliver a perfect solution—instead of just approaching and developing a solution. I'm a designer, not a programmer, but I've found that I interview best when I get explicit guidance from the interviewer. "I want to hear more about x, don't worry about y. What I want to learn about you is z." It makes the interview feel like a collaborative process (especially helpful when interviewing people you will work directly with, as you're pre-selling them on the team dynamic they'll experience!). It allows me to provide the information the interviewer needs most, in order to effectively evaluate my abilities and fit. It also clarifies for the applicant what things are actually worth stressing out about.
MichaelDickens 11y ago
> A live coding interview has (almost) nothing to do with the "quality" of your code, and doesn't necessarily even demand complete correctness. It's about observing your process, and trying to simulate what it would be like to work with you I frequently hear people say things like this. Now maybe you do think this way and I'm not saying you don't, but I think that makes you exceptional. In about 80% of interviews I've done where I successfully completed the problem, I got an offer; and in 100% of interviews where I did not complete the problem, I did not get an offer. That seems to indicate pretty strongly that solving the problem is by far the most important thing for most interviewers.
- yoklov 11y ago
  I didn't take what he said to mean that solving the problem wasn't important, but that the quality of your solution (in terms of how 'elegant' or 'idiomatic' it is) wasn't important.

by mockery 11y ago

usaphp 11y ago

> "It's about observing your process, and trying to simulate what it would be like to work with you" But coding at an interview under stress and time pressure has nothing to do with a work process in a normal company, unless you also force your employees to work under stress and strict timelines with you sitting behind their shoulder and watching every keystroke...

celadon 11y ago

If you aren't prioritizing for code quality and beauty, do you also explicitly tell candidates that? I think it's very difficult for candidates to understand exactly what the interviewer wants—and, of course, all interviewers are different. I think that, for better or worse, many people worry that they need to perform perfectly during the interview and actually deliver a perfect solution—instead of just approaching and developing a solution. I'm a designer, not a programmer, but I've found that I interview best when I get explicit guidance from the interviewer. "I want to hear more about x, don't worry about y. What I want to learn about you is z." It makes the interview feel like a collaborative process (especially helpful when interviewing people you will work directly with, as you're pre-selling them on the team dynamic they'll experience!). It allows me to provide the information the interviewer needs most, in order to effectively evaluate my abilities and fit. It also clarifies for the applicant what things are actually worth stressing out about.

MichaelDickens 11y ago

> A live coding interview has (almost) nothing to do with the "quality" of your code, and doesn't necessarily even demand complete correctness. It's about observing your process, and trying to simulate what it would be like to work with you I frequently hear people say things like this. Now maybe you do think this way and I'm not saying you don't, but I think that makes you exceptional. In about 80% of interviews I've done where I successfully completed the problem, I got an offer; and in 100% of interviews where I did not complete the problem, I did not get an offer. That seems to indicate pretty strongly that solving the problem is by far the most important thing for most interviewers.

yoklov 11y ago
I didn't take what he said to mean that solving the problem wasn't important, but that the quality of your solution (in terms of how 'elegant' or 'idiomatic' it is) wasn't important.