It's that time again and i'm applying for jobs.<p>First perspective job has a coding exam, foobar! I never seem to do well in these, just ties my brain up in knots.<p>How do you guys handle programming tasks for interviews, where they should only take a predetermined amount of time?<p>I'm half way through my time on this task already and I haven't even touched the unit tests.<p>It seems that anytime I get one of these tests, I spend far too long digesting the problem, far too long planning, far too long coding up first the first half.<p>That brings me to about half way through my allotted time and then I start to panic.<p>I feel useless. I mean don't tell me a future job is dependant on the interviewer liking my code or that there is a clock running. I've been able to break out more complicated tasks in less time, it's just when there's this whole judgement thing going on I get fired. Mainly because there is a million ways to do something..<p>Funny thing is, that any time I go into a new job, it was without prior coding and I exceed their expectations :/
> <i>I'm half way through my time on this task already and I haven't even touched the unit tests.</i><p>Well, generally, if you're wanting to do TDD/BDD, start with the tests first. Then write your code until the tests pass. That being said, TDD/BDD isn't exactly a timesaver in most cases, so I'd understand why you'd do it in the opposite order.<p>But anyway, to answer your question: I write a crappy/sloppy solution first, as fast I can. No thinking... just pretend you're coding for fun on a low-stakes project that nobody will ever see. Then I go back and try to plan a better way to do it. If I can refactor/recode it before the timer goes off, then that's great. If I can't, no biggie.
<i>I'm half way through my time on this task already and I haven't even touched the unit tests.</i><p>Well, my first bit of advice would be to avoid HN/FB/Twitter/etc during high pressure situations. Forgive my misunderstanding if you didn't mean you were literally halfway through it while posting.<p><i>That brings me to about half way through my allotted time and then I start to panic.</i><p>I recently had a candidate experience a panic attack during an interview. I felt badly (I've dealt with anxiety/panic myself) for him but there was nothing to do about it... the interview ended and of course he didn't get an offer. Point is: if you're prone to panic in high pressure situations it's nothing to be ashamed of but something you'll have to deal with as a separate issue.<p>There are a zillion amazing strategies for managing anxiety; meditation, breathing exercises, playing music and petting cats are the ones that I prefer.
It seems to be an anxiety issue. There are two ways to fix this, one is temporal and it is to practice. The other is permanent but more difficult and it is to find internal peace. Sadly, how to achieve that goes beyond the scope of this comment.<p>Beyond anxiety, it might serve you a change of perspective.
Don't think of the interview as an engineering problem, it is a communication problem. Even if you don't finish it, it should be salvageable by explaining all the things you considered and were about to consider. If they don't value this, it is their loss. And, Honestly, they did you a favor, a nice place to work would respect your time and listen after making you work on a test.
Coding challenges are getting very popular now because they save time during hiring processes. Recruiters use them to filter out candidates. Usually having a bad answer is better than an incomplete one. For that reason it is important to start with a simple solution and iterate over it.<p>One frustrating thing in my opinion is that coding challenges only measure CS skills like data structures, DP, graph. While important those are not as relevant as more specific knowledge like HTML5, iOS, Android, etc.
I have to admit that I'm not familiar with this problem. I mean, I understand if we're taking about those forms where you get 20 minutes of half an hour, but it seems to me that you are talking about those cases where you get a few days or a week.<p>This makes me think you might be in that small space where you are a decent programmer, but still don't have enough experience to be confident.<p>If that's the case, don't worry, it gets easier in time, at least in my case it did.
Do practice problems until you get a feel for how to organise your time.<p>I knew I was going to be given a couple of tests on <a href="https://codility.com/" rel="nofollow">https://codility.com/</a> so I practiced for a few hours on example problems I found online before. It really helped.