4 ms·

If you read the section about point #11 you will see that it's less about whiteboard programming, but rather making sure that they code something during the int

If you read the section about point #11 you will see that it's less about whiteboard programming, but rather making sure that they code something during the interview process. Seems that all of your suggestions are in line with this advice. > Yet, every day, programmers are hired on the basis of an impressive resumé or because the interviewer enjoyed chatting with them. Or they are asked trivia questions (“what’s the difference between CreateDialog() and DialogBox()?”) which could be answered by looking at the documentation. You don’t care if they have memorized thousands of trivia about programming, you care if they are able to produce code. Or, even worse, they are asked “AHA!” questions: the kind of questions that seem easy when you know the answer, but if you don’t know the answer, they are impossible. > Please, just stop doing this. Do whatever you want during interviews, but make the candidate write some code.

seer 6y ago
You have to be incredibly lucky, or very experienced in this to ever get an interview coding exercise you look good in. Its incredibly stressful and usually gives the company a very weak signal of what you will they get as a dev. There is soooo much setup in a modern dev process, build tools, compilers, transpilers, code formatting configs, let alone editors, languages and frameworks you are comfortable in, its not even funny. You will be asking a candidate to understand a task completely without any prior knowledge, figure out whats the minimum setup they need to work on it successfully, implement the logic in very few iterations and no coding partners or knowledge repos to help them. Preferably with some testing setup, and to top it off you want them to do it in an hour. As I mentioned it can be done if you are incredibly lucky and know exactly what to do, or have done this before many times in different interviews. And what do you get in return? Can a person work under high stress - e.g. are they ok at working in a shitty environment? If everything this should be a red flag as that person will keep shitty envs around and not go out of his way to fix things. How good are his coding skills? Well not really, you will know that they can do interview tasks - e.g. a small bite sized problems that have easy solutions. Long term planing, refactoring, perseverance, etc. - no signal there. And worst of all, it tells the candidate that your company/team enjoys high stress, small problem, and making each other uncomfortable. Remember an interview is both ways, and you just earned yourself a red flag too. Btw, Adam Grant had some podcast episodes about interviewing last year that were really good and showed some companies that actually solve this in a very nice, humane _and effective_ way.
- vlovich123 6y ago
  You may want to take a mental breather before you do a coding interview. Those are the easy parts. The design ones I’ve found significantly more difficult. Generally you’re given simple coding problems to solve where all the tooling in the world isn’t necessary. Or you were given homework questions to do on your own time. Every interview mechanism in the world, no matter how fair or perfect, will always have someone who complains when they don’t make the cut. Don’t complain. Figure out what you need to fix and focus on that. The technical problems are ridiculously easy insofar as they expose the critical gaps in your knowledge. The answers are even often available online if you need help working through where you went wrong. You don’t need the code you wrote on a whiteboard - you should be able to remember your solution well enough to write it again from scratch. If your general approach was good but there were some minor error cases, the interviews are already set up to counteract the natural effect you describe.
- lolc 6y ago
  Relax, everybody understands that code written in one hour is going to be shit. We will know you care about fixing things because you point out in what ways the code is shit. If you are uncomfortable talking about shitty code, especially your shitty code, we don't want your commits. If you happen upon a company where people will judge you for writting shit code in that situation, consider yourself lucky they let you know early. And leave.
- tsimionescu 6y ago
  The main idea is to see how they code through a very simple problem, trying to make it as relaxed as possible. Of course you won't get to see how they develop years of software and juggle realistic time pressures (days or weeks, not minutes) with code quality and future maintainability. But, you do want to see if they are comfortable writing code and working through it. Really simple stuff, like reversing a linked list or fizz buzz or the like - not algorithm development, just simple coding. You want to see how they do it, how they interact with the interviewer. Ideally they will make some mistake and you'll also get a chance to see how they recover. And yes, it's an interview and they are likely to be highly stressed. You need to take that into account as an interviewer, try to put them at ease, and help them when you see they are blocked, and see how they use that help. If as an interviewer you're just looking for them to 'solve the problem', then yes, you're doing it wrong. People will falter, they will forget an important detail etc - it doesn't prove anything in itself, even if the problem is trivial. But if a candidate stumbles and can't recover (with help) on the easiest problem, if they are avoiding putting the code 'on paper', if they have no idea how to approach basic problems or slight complications after you get the first answer, something is definitely wrong and must be explored further. And note, I'm not thinking of a 1h coding challenge, on the contrary, something like one or several 5-10 minute exercises, where you would explore their coding.

seer 6y ago

You have to be incredibly lucky, or very experienced in this to ever get an interview coding exercise you look good in. Its incredibly stressful and usually gives the company a very weak signal of what you will they get as a dev. There is soooo much setup in a modern dev process, build tools, compilers, transpilers, code formatting configs, let alone editors, languages and frameworks you are comfortable in, its not even funny. You will be asking a candidate to understand a task completely without any prior knowledge, figure out whats the minimum setup they need to work on it successfully, implement the logic in very few iterations and no coding partners or knowledge repos to help them. Preferably with some testing setup, and to top it off you want them to do it in an hour. As I mentioned it can be done if you are incredibly lucky and know exactly what to do, or have done this before many times in different interviews. And what do you get in return? Can a person work under high stress - e.g. are they ok at working in a shitty environment? If everything this should be a red flag as that person will keep shitty envs around and not go out of his way to fix things. How good are his coding skills? Well not really, you will know that they can do interview tasks - e.g. a small bite sized problems that have easy solutions. Long term planing, refactoring, perseverance, etc. - no signal there. And worst of all, it tells the candidate that your company/team enjoys high stress, small problem, and making each other uncomfortable. Remember an interview is both ways, and you just earned yourself a red flag too. Btw, Adam Grant had some podcast episodes about interviewing last year that were really good and showed some companies that actually solve this in a very nice, humane _and effective_ way.

vlovich123 6y ago
You may want to take a mental breather before you do a coding interview. Those are the easy parts. The design ones I’ve found significantly more difficult. Generally you’re given simple coding problems to solve where all the tooling in the world isn’t necessary. Or you were given homework questions to do on your own time. Every interview mechanism in the world, no matter how fair or perfect, will always have someone who complains when they don’t make the cut. Don’t complain. Figure out what you need to fix and focus on that. The technical problems are ridiculously easy insofar as they expose the critical gaps in your knowledge. The answers are even often available online if you need help working through where you went wrong. You don’t need the code you wrote on a whiteboard - you should be able to remember your solution well enough to write it again from scratch. If your general approach was good but there were some minor error cases, the interviews are already set up to counteract the natural effect you describe.
lolc 6y ago
Relax, everybody understands that code written in one hour is going to be shit. We will know you care about fixing things because you point out in what ways the code is shit. If you are uncomfortable talking about shitty code, especially your shitty code, we don't want your commits. If you happen upon a company where people will judge you for writting shit code in that situation, consider yourself lucky they let you know early. And leave.
tsimionescu 6y ago
The main idea is to see how they code through a very simple problem, trying to make it as relaxed as possible. Of course you won't get to see how they develop years of software and juggle realistic time pressures (days or weeks, not minutes) with code quality and future maintainability. But, you do want to see if they are comfortable writing code and working through it. Really simple stuff, like reversing a linked list or fizz buzz or the like - not algorithm development, just simple coding. You want to see how they do it, how they interact with the interviewer. Ideally they will make some mistake and you'll also get a chance to see how they recover. And yes, it's an interview and they are likely to be highly stressed. You need to take that into account as an interviewer, try to put them at ease, and help them when you see they are blocked, and see how they use that help. If as an interviewer you're just looking for them to 'solve the problem', then yes, you're doing it wrong. People will falter, they will forget an important detail etc - it doesn't prove anything in itself, even if the problem is trivial. But if a candidate stumbles and can't recover (with help) on the easiest problem, if they are avoiding putting the code 'on paper', if they have no idea how to approach basic problems or slight complications after you get the first answer, something is definitely wrong and must be explored further. And note, I'm not thinking of a 1h coding challenge, on the contrary, something like one or several 5-10 minute exercises, where you would explore their coding.