4 ms·

I believe this is reasonable advice but I believe it can be simplified even further. Live-coding in an interview be it in a text editor (shitty or otherwise -

I believe this is reasonable advice but I believe it can be simplified even further. Live-coding in an interview be it in a text editor (shitty or otherwise - those web based platforms can be really painful and slow to use when sharing a screen with zoom, e.g.) or on a whiteboard is a skill, and I’m not sure it is one that is worth optimizing for because I’m not sure that this particular skill really has much to do with day-to-day software development. I am sure it doesn’t hurt to be able to perform in a foreign environment with someone judging you over your shoulder but I hope dev work in general possesses as little of this type of work as possible. But you can simplify the problem considerably and ask someone to solve a fairly easy problem in just about any live coding fashion. To wit: I learned Java in school, spent some time at a job using other languages, then interviewed for an intermediate software developer position. The hiring manager asked me to write fizzbuzz in Java. I had never heard of the fizz buzz problem and I hadn’t written Java in some time. Still, I was able to successfully solve the problem with a minimum of difficulty (though admittedly a maximum of nerves). He asked me a few questions about how to improve the solution, and I mumbled some stuff about combining string concatenation statements instead of simply appending to the string, something which made him nod his head sagely and that I still consider to be a largely useless micro-optimization, but the main thing, the important part, is that I demonstrated some coding ability in a matter of minutes, right in front of his eyes. It’s something that sticks with me and I think it’s a valuable type of interview question. I got the job. https://en.wikipedia.org/wiki/Fizz_buzz https://en.wikipedia.org/wiki/Fizz_buzz

nprateem 4y ago
Writing fizz buzz is practically a meme, but worse, what can you really talk about? I agree about live coding which is why we send that test to them pre-interview - it's to screen potential candidates. If they get to an interview, a reasonable amount of it is to ask what they've done and why, e.g. * Did they write a CLI parser? * If so, did they add sensible options (e.g. to force overwriting files that exist on the destination or not), or aren't they bothering to check whether files already exist on the destination * Did they add/stub out tests? If so, to test what? * What does error handling look like? Boto performs retries by default. Is this their justification or didn't they think about it? * How else could they have done it (e.g. use a library vs shelling out to the aws cli binary). It's complicated enough that it helps show their proactiveness. The instructions include 'making it good', and also say they can just stub out/write comments for what they would do if they were doing it for real. It's saved loads of time in the past by filtering out people who don't even have the basics, and it's relevant to the work.
- avg_dev 4y ago
  I understand that your task which maxes out at one hour has some value. I have written such tests as a candidate and some have been good. I have iterated on the development of such tests as an interviewer. I feel that they can offer a candidate an opportunity to demonstrate their abilities without a big investment of time. But there still is the matter of that one hour. If I am applying to a job that has a hard limit on the amount of time that I can spend on that task, and I really want that job, you can bet that if I can figure out how to arrange my schedule so that I can spend more than an hour, and if I can figure out how to make it look like I spent no more than one hour, I will. And I believe there are those candidates who may not have the time to spend on unpaid work. It may be harder than it appears on the surface: There are quite likely other commitments in the candidate's life. There may be other interviews that the candidate is facing, each with its own technical requirements, some of which may requiring learning, study, or refreshing (as may your own). There may be other job application processes that the candidate is dealing with that also have one-hour pre-interview coding tasks. There is also the fact that the candidate has to trust that you will evaluate them fairly. I believe that a published rubric can go a long way to alleviate this particular concern. I'm not saying I have all the answers, as I know that I do not. But I believe that asking a candidate to take "one hour" of their lives for a simple coding task, unpaid, can sometimes cost more than is obvious. If I can ask someone to solve a question (fizzbuzz, the find method in a binary search tree, ...) in real-time, I feel it is sometimes more respectful of the candidate's time. If the candidate has the time and the inclination to code a pre-interview task, by all means, it is a great method of assessment.
  - nprateem 4y ago
    A link to github or other coding sample is also accepted. It's a starting point for asking questions.

nprateem 4y ago

Writing fizz buzz is practically a meme, but worse, what can you really talk about? I agree about live coding which is why we send that test to them pre-interview - it's to screen potential candidates. If they get to an interview, a reasonable amount of it is to ask what they've done and why, e.g. * Did they write a CLI parser? * If so, did they add sensible options (e.g. to force overwriting files that exist on the destination or not), or aren't they bothering to check whether files already exist on the destination * Did they add/stub out tests? If so, to test what? * What does error handling look like? Boto performs retries by default. Is this their justification or didn't they think about it? * How else could they have done it (e.g. use a library vs shelling out to the aws cli binary). It's complicated enough that it helps show their proactiveness. The instructions include 'making it good', and also say they can just stub out/write comments for what they would do if they were doing it for real. It's saved loads of time in the past by filtering out people who don't even have the basics, and it's relevant to the work.

avg_dev 4y ago
I understand that your task which maxes out at one hour has some value. I have written such tests as a candidate and some have been good. I have iterated on the development of such tests as an interviewer. I feel that they can offer a candidate an opportunity to demonstrate their abilities without a big investment of time. But there still is the matter of that one hour. If I am applying to a job that has a hard limit on the amount of time that I can spend on that task, and I really want that job, you can bet that if I can figure out how to arrange my schedule so that I can spend more than an hour, and if I can figure out how to make it look like I spent no more than one hour, I will. And I believe there are those candidates who may not have the time to spend on unpaid work. It may be harder than it appears on the surface: There are quite likely other commitments in the candidate's life. There may be other interviews that the candidate is facing, each with its own technical requirements, some of which may requiring learning, study, or refreshing (as may your own). There may be other job application processes that the candidate is dealing with that also have one-hour pre-interview coding tasks. There is also the fact that the candidate has to trust that you will evaluate them fairly. I believe that a published rubric can go a long way to alleviate this particular concern. I'm not saying I have all the answers, as I know that I do not. But I believe that asking a candidate to take "one hour" of their lives for a simple coding task, unpaid, can sometimes cost more than is obvious. If I can ask someone to solve a question (fizzbuzz, the find method in a binary search tree, ...) in real-time, I feel it is sometimes more respectful of the candidate's time. If the candidate has the time and the inclination to code a pre-interview task, by all means, it is a great method of assessment.
- nprateem 4y ago
  A link to github or other coding sample is also accepted. It's a starting point for asking questions.