11 ms·

Imagine someone walking up to Maya Angelou, handing her a white eraser marker, and asking her to write you a poem on a white board. She's obviously not going to

Imagine someone walking up to Maya Angelou, handing her a white eraser marker, and asking her to write you a poem on a white board. She's obviously not going to immediately write you a poem, at least not one thats any good. Is it fair to judge her poem writing abilities by this off the cuff creation?Creators can only do their best creation when they are in their comfortable space. Asking a programmer to write code over the phone will result in substandard quality no matter what.

philwelch 13y ago
Sorry, if I ask you to write a function that determines whether two given words are anagrams of each other, "I need to get into my comfortable space for my creative process to work" is an evasion. No one's asking for a masterpiece, just a demonstration of basic competence.
- seiji 13y ago
  What kills me with Do Work While We Stare At You interviews is my process is all over the place. I tend to draft something, try it, find my five mistakes, try more things, etc. That doesn't fly in an interview. At least, I don't feel it does. Interviewers expect mostly right and mostly very fast. I end up standing there trying to pre-think the entire problem so something correct comes out the first time, which, to them, is just dead time with me staring at the wall. The other option is to "dive in" and backtrack a lot, but the people watching can't tell the difference between actual incompetence and just figuring it out.
  - MichaelSalib 13y ago
    That doesn't fly in an interview. Actually, it does. I've been interviewing a lot lately, and I'm totally fine with people trying something, changing their mind, fixing mistakes, etc. When they get stuck, I help them out. All decent interviewers know that being interviewed is stressful and that you need to cut candidates some slack. Speaking personally, I don't care much about speed. I care about things like how much fluency do you have with your programming language (is writing a for loop something you have to struggle with?), do you know how to use a hash table (you'd be amazed at how many people don't), can you explain what the tradeoffs are when you make design choices and compare them to the alternatives, etc. Also, since I can, I'm going to complain about my pet peeve: candidates who want to write a solution in C++ or C or java (I let them choose any language they want) but who refuse to use a container library. They'll insist on using arrays, even when the problem pretty clearly requires something like std::vector. And then they'll tie themselves in knots to make static fixed size arrays work. Now, if you can justify why you don't want to use a @#$! container library, that's fine, but usually the justifications are garbage ("it will be too slow...no, I've never measured that"). What really gets me is that a good sw engineer should be able to see that rewriting stl::vector by hand in every application intertwining its code with your application code (vector's client) is a maintenance and performance nightmare.
  - fudisgud 13y ago
    And here's the rub: Running an interview this way is hard to do RIGHT. The questions have to be tractable for the given time, not too oblivious that the candidate blows through them, not too domain-specific that the interviewer ends up giving a lecture to education the interviewee on the domain. Then there's the proctoring of the question. Show of hands here: Who here has worked a companies where they used white boarding as part of their process? Did any of the following happen? * Interviewers asked pet questions instead of using a vetted list of questions * Interviewers never tried any of the questions in interview conditions * Interviewers were never trained/practiced giving these sorts of interviews * Random developers were pulled into interviews to proctor a white boarding. Guess what? The development team is learning how to interview candidates by interviewing candidates! Not prepping a team on how to interview seems very common. Maybe candidates are expendable and ultimately are the ones that need to prove themselves. I have to wonder how many times qualified candidates get bypassed because they didn't whiteboard just so to the interview's liking. More concerning, how many times have unqualified candidates buffalo inexperienced interviewers with hand-waves or by luck of having seen the problem before, and end up weighing down the team with incompetence.
  - philwelch 13y ago
    > What kills me with Do Work While We Stare At You interviews is my process is all over the place. I tend to draft something, try it, find my five mistakes, try more things, etc. Well yeah, that's exactly how those interviews generally go. You have to kind of narrate what you're doing, and that can be awkward at first but coming up with the optimal answer in the end is not the only goal of the interview. By all means show your work.
  - randallsquared 13y ago
    My process is similarly all over the place, but DWWWSAY suffers from the additional problem that 80% of my thinking power is taken up with social crap in a situation like this, so the interviewer is essentially seeing me at 20% speed. This may be why I have never gotten a job after being asked to demonstrate coding something on a whiteboard. :)
- rilindo 13y ago
  Here is a first go at it: https://gist.github.com/rilindo/6575580 https://gist.github.com/rilindo/6575580 Essentially, I just checked to see if the characters in the first string exists in other string and exits out of the code. It probably won't cover every use case (in other words, probably very buggy), but it is a start. However, I have the luxury of relaxing while looking up the functions online, writing the code by my lonesome and then verifying it by running it directly. Last I checked, not any of these things are likely not present or available in a white board interview. EDIT: I should at least put it in a function. :D
  - MichaelSalib 13y ago
    You might want to try something like 'return set(x)==set(y)'. Or, a better solution might be 'return set(collections.Counter(x).items())==set(collections.Counter(y).items())'. The point of the question isn't to see if you've memorized every single stdlib function. If you can describe a stdlib function but can't remember it, a good interviewer will tell you about it.
    - minikomi 13y ago
      Be careful using sets -- what about "banana" and "ban"
      - MichaelSalib 13y ago
        The OP's solution didn't deal with letter counts at all; my first expression was to show him a similar solution that was more succinct to illustrate the principle at work. My second solution deals with multiplicity properly.
        rilindo 13y ago
        Yes and I appreciate it. https://gist.github.com/rilindo/6576017 https://gist.github.com/rilindo/6576017 New toy to play with. :)
    - deleted 13y ago
      [deleted]
- jebblue 13y ago
  >> if I ask you to write a function that determines whether two given words are anagrams of each other I've no college degree, I've been writing software earning me a comfortable living for 2 decades and for fun for 3 decades. I've solved a lot of problems in software and never heard of Big O until recently on HN. If you ask me about college quiz stuff like fuzzbuster (fizzbuster?) or anagrams I have to Google what an anagram is in the first place. I've never seen anyone paid to write them, never had a manager ask me to write one.
  - philwelch 13y ago
    Anagrams aren't some sort of classic CS problem domain, it's just a relatively simple example. One would start the question by making sure you knew what an anagram was. Two words are anagrams you can rearrange the letters in one of them to make the other, like "Mary" and "army".
    - wavefunction 13y ago
      Phil, the point is who gives a flying f in production about anagrams. Noone has to deliver a meaningful abstraction in < an hour (or 15 minutes as a "simple" example of "puzzle" testing), and interviewing for that is truly ridiculous. You and others might find it meaningful but after two decades of development I really have to question those who do.
      - nl 13y ago
        Like you - I've never needed to solve an anagram in production. I think many are missing the point. In an interview situation, the anagram problem gets the person to write some basic, naive code (ie, proves that can track loops) which I think we would both agree is reasonable. Then the interviewer gets you to look at how to improve it. Hopefully you'll notice that iterating over both strings isn't very efficient, and reason about ways to improve that. It's that reasoning process that is important, not the knowledge of how to write an anagram solver. To be fair, though - most programmers should be able to solve it with a couple of hints.
- mmorett 13y ago
  https://gist.github.com/MichaelMorett/6576434 https://gist.github.com/MichaelMorett/6576434 I think I'd get yelled at in an interview for this one since I didn't punch down to String manipulation (which is probably what they're really looking for).
  - philwelch 13y ago
    Are you thinking of palindromes?
    - mmorett 13y ago
      LOL!!! I coughed up my beer on that comment. I feel so dumb. Yes, I was thinking palindromes. Either way, I blew that interview. :-)
- alok-g 13y ago
  >> No one's asking for a masterpiece, just a demonstration of basic competence. Once the candidate demonstrates the basic competence, what would be a good next step? How should one evaluate the higher level of thinking like creativity, (higher-level) problem solving, etc., which may be just as important for the position at hand as the basic competence? If you do have a good answer to the above, the next question could be if you could have tested this higher-level thinking without the basic coding competence if (and only if) so were the nature of the job.
- zerr 13y ago
  These kind of FizzBuzz stuff is not an issue I believe (although, "going blank" during the phone call or in similar situation is as well legitimate). The main problem is that interviewers (BigCo's) ask questions that require inventing Knuth-Morris-Pratt algorithm or K-D trees on the spot, whereas researches spent months... Of course I assume that the interviewee is not aware of these a priori (or it's been a decade since he last heard about these).

philwelch 13y ago

Sorry, if I ask you to write a function that determines whether two given words are anagrams of each other, "I need to get into my comfortable space for my creative process to work" is an evasion. No one's asking for a masterpiece, just a demonstration of basic competence.

seiji 13y ago
What kills me with Do Work While We Stare At You interviews is my process is all over the place. I tend to draft something, try it, find my five mistakes, try more things, etc. That doesn't fly in an interview. At least, I don't feel it does. Interviewers expect mostly right and mostly very fast. I end up standing there trying to pre-think the entire problem so something correct comes out the first time, which, to them, is just dead time with me staring at the wall. The other option is to "dive in" and backtrack a lot, but the people watching can't tell the difference between actual incompetence and just figuring it out.
- MichaelSalib 13y ago
  That doesn't fly in an interview. Actually, it does. I've been interviewing a lot lately, and I'm totally fine with people trying something, changing their mind, fixing mistakes, etc. When they get stuck, I help them out. All decent interviewers know that being interviewed is stressful and that you need to cut candidates some slack. Speaking personally, I don't care much about speed. I care about things like how much fluency do you have with your programming language (is writing a for loop something you have to struggle with?), do you know how to use a hash table (you'd be amazed at how many people don't), can you explain what the tradeoffs are when you make design choices and compare them to the alternatives, etc. Also, since I can, I'm going to complain about my pet peeve: candidates who want to write a solution in C++ or C or java (I let them choose any language they want) but who refuse to use a container library. They'll insist on using arrays, even when the problem pretty clearly requires something like std::vector. And then they'll tie themselves in knots to make static fixed size arrays work. Now, if you can justify why you don't want to use a @#$! container library, that's fine, but usually the justifications are garbage ("it will be too slow...no, I've never measured that"). What really gets me is that a good sw engineer should be able to see that rewriting stl::vector by hand in every application intertwining its code with your application code (vector's client) is a maintenance and performance nightmare.
- fudisgud 13y ago
  And here's the rub: Running an interview this way is hard to do RIGHT. The questions have to be tractable for the given time, not too oblivious that the candidate blows through them, not too domain-specific that the interviewer ends up giving a lecture to education the interviewee on the domain. Then there's the proctoring of the question. Show of hands here: Who here has worked a companies where they used white boarding as part of their process? Did any of the following happen? * Interviewers asked pet questions instead of using a vetted list of questions * Interviewers never tried any of the questions in interview conditions * Interviewers were never trained/practiced giving these sorts of interviews * Random developers were pulled into interviews to proctor a white boarding. Guess what? The development team is learning how to interview candidates by interviewing candidates! Not prepping a team on how to interview seems very common. Maybe candidates are expendable and ultimately are the ones that need to prove themselves. I have to wonder how many times qualified candidates get bypassed because they didn't whiteboard just so to the interview's liking. More concerning, how many times have unqualified candidates buffalo inexperienced interviewers with hand-waves or by luck of having seen the problem before, and end up weighing down the team with incompetence.
- philwelch 13y ago
  > What kills me with Do Work While We Stare At You interviews is my process is all over the place. I tend to draft something, try it, find my five mistakes, try more things, etc. Well yeah, that's exactly how those interviews generally go. You have to kind of narrate what you're doing, and that can be awkward at first but coming up with the optimal answer in the end is not the only goal of the interview. By all means show your work.
- randallsquared 13y ago
  My process is similarly all over the place, but DWWWSAY suffers from the additional problem that 80% of my thinking power is taken up with social crap in a situation like this, so the interviewer is essentially seeing me at 20% speed. This may be why I have never gotten a job after being asked to demonstrate coding something on a whiteboard. :)
rilindo 13y ago
Here is a first go at it: https://gist.github.com/rilindo/6575580 https://gist.github.com/rilindo/6575580 Essentially, I just checked to see if the characters in the first string exists in other string and exits out of the code. It probably won't cover every use case (in other words, probably very buggy), but it is a start. However, I have the luxury of relaxing while looking up the functions online, writing the code by my lonesome and then verifying it by running it directly. Last I checked, not any of these things are likely not present or available in a white board interview. EDIT: I should at least put it in a function. :D
- MichaelSalib 13y ago
  You might want to try something like 'return set(x)==set(y)'. Or, a better solution might be 'return set(collections.Counter(x).items())==set(collections.Counter(y).items())'. The point of the question isn't to see if you've memorized every single stdlib function. If you can describe a stdlib function but can't remember it, a good interviewer will tell you about it.
  - minikomi 13y ago
    Be careful using sets -- what about "banana" and "ban"
    - MichaelSalib 13y ago
      The OP's solution didn't deal with letter counts at all; my first expression was to show him a similar solution that was more succinct to illustrate the principle at work. My second solution deals with multiplicity properly.
      - rilindo 13y ago
        Yes and I appreciate it. https://gist.github.com/rilindo/6576017 https://gist.github.com/rilindo/6576017 New toy to play with. :)
  - deleted 13y ago
    [deleted]
jebblue 13y ago
>> if I ask you to write a function that determines whether two given words are anagrams of each other I've no college degree, I've been writing software earning me a comfortable living for 2 decades and for fun for 3 decades. I've solved a lot of problems in software and never heard of Big O until recently on HN. If you ask me about college quiz stuff like fuzzbuster (fizzbuster?) or anagrams I have to Google what an anagram is in the first place. I've never seen anyone paid to write them, never had a manager ask me to write one.
- philwelch 13y ago
  Anagrams aren't some sort of classic CS problem domain, it's just a relatively simple example. One would start the question by making sure you knew what an anagram was. Two words are anagrams you can rearrange the letters in one of them to make the other, like "Mary" and "army".
  - wavefunction 13y ago
    Phil, the point is who gives a flying f in production about anagrams. Noone has to deliver a meaningful abstraction in < an hour (or 15 minutes as a "simple" example of "puzzle" testing), and interviewing for that is truly ridiculous. You and others might find it meaningful but after two decades of development I really have to question those who do.
    - nl 13y ago
      Like you - I've never needed to solve an anagram in production. I think many are missing the point. In an interview situation, the anagram problem gets the person to write some basic, naive code (ie, proves that can track loops) which I think we would both agree is reasonable. Then the interviewer gets you to look at how to improve it. Hopefully you'll notice that iterating over both strings isn't very efficient, and reason about ways to improve that. It's that reasoning process that is important, not the knowledge of how to write an anagram solver. To be fair, though - most programmers should be able to solve it with a couple of hints.
mmorett 13y ago
https://gist.github.com/MichaelMorett/6576434 https://gist.github.com/MichaelMorett/6576434 I think I'd get yelled at in an interview for this one since I didn't punch down to String manipulation (which is probably what they're really looking for).
- philwelch 13y ago
  Are you thinking of palindromes?
  - mmorett 13y ago
    LOL!!! I coughed up my beer on that comment. I feel so dumb. Yes, I was thinking palindromes. Either way, I blew that interview. :-)
alok-g 13y ago
>> No one's asking for a masterpiece, just a demonstration of basic competence. Once the candidate demonstrates the basic competence, what would be a good next step? How should one evaluate the higher level of thinking like creativity, (higher-level) problem solving, etc., which may be just as important for the position at hand as the basic competence? If you do have a good answer to the above, the next question could be if you could have tested this higher-level thinking without the basic coding competence if (and only if) so were the nature of the job.
zerr 13y ago
These kind of FizzBuzz stuff is not an issue I believe (although, "going blank" during the phone call or in similar situation is as well legitimate). The main problem is that interviewers (BigCo's) ask questions that require inventing Knuth-Morris-Pratt algorithm or K-D trees on the spot, whereas researches spent months... Of course I assume that the interviewee is not aware of these a priori (or it's been a decade since he last heard about these).