Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview Zen, tool for asynchronous coding interviews

interviewzen.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: Interview Zen, tool for asynchronous coding interviews

#21

Post by steve8918 »

Oh boy.

So now, we are supposed to be evaluated on our "thought process"? Based on what we type in the middle of programming? Talk about a completely ridiculous notion.

First off, what is the point? What matters is the finished product. When I code, I try a bunch of different ideas, get to a working prototype to make sure that the idea can actually work, and then I start to whittle down to what I believe is the best solution.

What does it matter what intermediate steps I come up with? All that matters is the code that I present for code review to my co-workers, and the code that I ultimately check-in. Trying to divine someone's "thought process" (which other people are completely unqualified to do, just based on what you see them type on the screen) is more stupid hoops to jump through in what is already becoming an increasing ridiculous hiring process for programmers.

Re: Interview Zen, tool for asynchronous coding interviews

#22

Post by kabdib »

steve8918 wrote: post #21

Oh boy. So now, we are supposed to be evaluated on our "thought process"? Based on what we type in the middle of programming? Talk about a completely ridiculous notion. First off, what is the point? What matters is the finished product. When I code, I try a bunch of different ideas, get to a working prototype to make sure that the idea can actually work, and then I start to whittle down to what I believe is the best…

I would probably do okay at this. But I know some good people who would not. One of them is nearly blind, and is one of the best systems programmers I know.

Since I use Emacs nearly exclusively (Visual Studio for debugging, and other tools for writing documentation), I would revert to "I have to type code in a dumb editor" mode, and my fingers would be stupid. You'd see some stumbling around. I'm not sure it's useful knowledge for the interviewer.

Re: Interview Zen, tool for asynchronous coding interviews

#23

Post by lifeisstillgood »

shanelja wrote: post #16

It's certainly not perfect, but I came up with it under pressure in less than 90 seconds without checking online for the modulo return values, so I'm rather proud of it. $x = 1; while($x if((($x % 5) == 0) && (($x % 3) != 0)){ print("Buzz"); }else{ if(($x % 3) == 0){ if(($x % 5) == 0) { print("FizzBuzz"); } else { print("Fizz"); } }else{ print($x); }} ++$x; } ?>

I am a bit lost on the syntax, but its always good to check for division by 15 first. You have sort of caught that I think in 5 and not 3, but that just seems an odd idiom.

The homepage shows a simple example in C.

Oh, I used to use this on coding tests, the first guy who asked can I do it recursively in Scheme - I could have kissed him !

Re: Interview Zen, tool for asynchronous coding interviews

#25

Post by espinchi »

jotux wrote: post #24

While pretty, I think tools like see[mike]code are a little more practical: http://i.seemikecode.com/ I think a conversation with someone as they code, rather than a reply of what they did, is an easier way to evaluate skill.

However, you can't do asynchronous interviews to a bunch of candidates with seemikecode. (A different business is whether that is a good practice or not.)

Re: Interview Zen, tool for asynchronous coding interviews

#26

Post by ragmondo »

jarito wrote: post #9

Okay. Tried it out. This has some promise, but I think there might be some issues in actual use. One of the major bonuses of this for me as an interviewer is to see how the candidate solves the problem over time (as opposed to just seeing the finished product). However, as a candidate, the coding process is pretty painful. I tried it out for C# and there is no intellisense, no compilation, no type checking, etc. This…

just a "me too" . Without a "run this script" viz-a-vie c9 or udacity ... then I would just use whatever ide was to hand and then cut/paste at the end

Re: Interview Zen, tool for asynchronous coding interviews

#28

Post by typicalrunt »

jarito wrote: post #9

Okay. Tried it out. This has some promise, but I think there might be some issues in actual use. One of the major bonuses of this for me as an interviewer is to see how the candidate solves the problem over time (as opposed to just seeing the finished product). However, as a candidate, the coding process is pretty painful. I tried it out for C# and there is no intellisense, no compilation, no type checking, etc. This…

This really depends on the applicant and the coding question being asked. Writing a fizzbuzz implementation shouldn't require any IDE, intellisense, or any tools for that matter. I wouldn't expect a coding interview using this tool to be asking anything more than a simple coding question, or else this gets unweildy quickly, but not because of a lack of an IDE, but because I'm typing in a small textarea.

You should try writing out some code on paper some time and see how you do. Without any of the fancy tools to act as a crutch, you'll find that your memory gets better and you are able to crunch more logic in your head.

Re: Interview Zen, tool for asynchronous coding interviews

#30

Post by typicalrunt »

steve8918 wrote: post #21

Oh boy. So now, we are supposed to be evaluated on our "thought process"? Based on what we type in the middle of programming? Talk about a completely ridiculous notion. First off, what is the point? What matters is the finished product. When I code, I try a bunch of different ideas, get to a working prototype to make sure that the idea can actually work, and then I start to whittle down to what I believe is the best…

Showing the mistakes I made while coding was actually something I liked about it. I would hope that after I write the code, I can justify some of the backspaces I used. Even when writing the fizzbuzz implementation in Ruby I found that I used the wrong conditional logic at first (puts "fizz" if i % 3 == 0) and then decided to change it to a more traditional if-else block format. Sure, that meant I took 2m10s to finish the test, but now I have proof why it took the extra 30 seconds. That's something I have no problem showing to a potential employer, because I can show how I'm constantly trying to improve my code even as I write it.
Post reply on HN