Codefights

Post by pavel_lishin » Thu, Aug 21, 2014, 6:17 PM UTC

laumars wrote: post #40

Tiks wrote: post #18

Earlier quoted context omitted.

Yeap, great point. We currently sync the time with the server regularly to avoid cheating and given that the servers are under HN rush right now the delay is probably way more significant than it usually is. However, we are trying to figure out a better way to do this to make sure it doesn't start counting before the task loads.

Could you also start the timer after the player has acknowledged they've read the problem? At the moment you're unfairly disqualifying players who have reading difficulties (English isn't their first language, reading difficulties like dyslexia, or even those with partial eyesight so also read slower). Timing the person's ability to read English doesn't prove their ability to write Javascript et al.

Post by Too » Thu, Aug 21, 2014, 7:10 PM UTC

blatherard wrote: post #65

jrochkind1 wrote: post #64

Interesting idea. Several of the solutions I encountered are just... plain done wrong. They have a bug, sure, but the bug's actually there cause it was written in a really hacky way instead of the simplest way that would implement the function. I feel like it took me longer to find the bug in the hacky implementation than it would have to rewrite it 'right'. (For instance, the 'right' way to find "largest integer wit…

This reminds me of more than one job interview I've had. One included a puzzler that was "fix this horribly convoluted javascript code by adding exactly four characters." I'd consider myself a pretty good bug finder-and-fixer. As in, I've read multiple books on debugging methods and even given some talks on effective debugging. Nevertheless, these kinds of stumpers make me freeze up. I dunno exactly what puzzles like…

Post by danielweber » Thu, Aug 21, 2014, 7:36 PM UTC

Post by jrochkind1 » Thu, Aug 21, 2014, 10:09 PM UTC

Too wrote: post #73

blatherard wrote: post #65

Earlier quoted context omitted.

This reminds me of more than one job interview I've had. One included a puzzler that was "fix this horribly convoluted javascript code by adding exactly four characters." I'd consider myself a pretty good bug finder-and-fixer. As in, I've read multiple books on debugging methods and even given some talks on effective debugging. Nevertheless, these kinds of stumpers make me freeze up. I dunno exactly what puzzles like…

I've actually seen this mentality on production code. "The smaller the diff the better. And The less we change the less likely we are to introduce new bugs!!1".

Post by pyre » Fri, Aug 22, 2014, 1:21 AM UTC

squeaky-clean wrote: post #59

pyre wrote: post #58

Earlier quoted context omitted.

Reading the comments is about understanding what the function is supposed to be doing. Reading the code is about actually finding the bug. I can see the argument for allowing one to understand the problem prior to hunting down the bug.

While I understand point people are making, I think understanding the problem is part of the debugging process, and should be a part of the puzzle and timer. I remember entering programming competitions in high school and college. The first 5 minutes, when everyone is ripping open the envelope of their problem packet and trying to find the easiest problems was always very intense, and fun! Sometimes you would read th…