4 ms·

You have to be incredibly lucky, or very experienced in this to ever get an interview coding exercise you look good in. Its incredibly stressful and usually giv

• vlovich123 6y ago
  You may want to take a mental breather before you do a coding interview. Those are the easy parts. The design ones I’ve found significantly more difficult. Generally you’re given simple coding problems to solve where all the tooling in the world isn’t necessary. Or you were given homework questions to do on your own time. Every interview mechanism in the world, no matter how fair or perfect, will always have someone who complains when they don’t make the cut. Don’t complain. Figure out what you need to fix and focus on that. The technical problems are ridiculously easy insofar as they expose the critical gaps in your knowledge. The answers are even often available online if you need help working through where you went wrong. You don’t need the code you wrote on a whiteboard - you should be able to remember your solution well enough to write it again from scratch. If your general approach was good but there were some minor error cases, the interviews are already set up to counteract the natural effect you describe.
• lolc 6y ago
  Relax, everybody understands that code written in one hour is going to be shit. We will know you care about fixing things because you point out in what ways the code is shit. If you are uncomfortable talking about shitty code, especially your shitty code, we don't want your commits. If you happen upon a company where people will judge you for writting shit code in that situation, consider yourself lucky they let you know early. And leave.
• tsimionescu 6y ago
  The main idea is to see how they code through a very simple problem, trying to make it as relaxed as possible. Of course you won't get to see how they develop years of software and juggle realistic time pressures (days or weeks, not minutes) with code quality and future maintainability. But, you do want to see if they are comfortable writing code and working through it. Really simple stuff, like reversing a linked list or fizz buzz or the like - not algorithm development, just simple coding. You want to see how they do it, how they interact with the interviewer. Ideally they will make some mistake and you'll also get a chance to see how they recover. And yes, it's an interview and they are likely to be highly stressed. You need to take that into account as an interviewer, try to put them at ease, and help them when you see they are blocked, and see how they use that help. If as an interviewer you're just looking for them to 'solve the problem', then yes, you're doing it wrong. People will falter, they will forget an important detail etc - it doesn't prove anything in itself, even if the problem is trivial. But if a candidate stumbles and can't recover (with help) on the easiest problem, if they are avoiding putting the code 'on paper', if they have no idea how to approach basic problems or slight complications after you get the first answer, something is definitely wrong and must be explored further. And note, I'm not thinking of a 1h coding challenge, on the contrary, something like one or several 5-10 minute exercises, where you would explore their coding.
• sideshowb 6y ago
  What were the techniques the companies on those podcasts used?
• toast0 6y ago
  > How good are his coding skills? Well not really, you will know that they can do interview tasks - e.g. a small bite sized problems that have easy solutions. Long term planing, refactoring, perseverance, etc. - no signal there. Not many people are able to do a 3 month interview so their long term skills can be observed. Part of a good interview process is coming to a decision without using a lot of the candidate's time. They're busy people, and if they don't get an offer, or don't like the offer, it's time they could have spent doing something productive or fun. I've worked with people who couldn't actually demonstrate the skills I'm looking for in my coding exercise: listen to a problen description, ask clarifying questions, and discuss a solution; write down what the output should look like given an example input; write code that does what you discussed. I don't want to work with people who can't do at least those things. Yes, writing code on a whiteboard isn't how most code is written. Yes, most problems aren't neatly packaged things that fit all that into 40 minutes. Yes, it can be stressful, which is unfortunate.
  • seer 6y ago
    The best coding interview task I’ve ever seen was from “x-team” people - when I applied I was automatically sent a zip with a generated coding challenge consisting of a small express app that needed some bugfixes, some really obvious, some not so much and some subtle ones. After I finished I had some tests to tell me how well I’ve done and some hashes generated to prove I’ve actually done what needed doing. It was amazing - no contact with the people required, they know upfront that I am able to code “something” and we can now continue the interview in a more traditional setting. There was _some_ time pressure but nothing scary, and I could use my own hardware and software to solve the problem. Awesome. Only thing missing as a signal for them was for teamwork, but it nailed the coding part for me.
• stefs 6y ago
  iirc joel wrote another post specifically about this. the problem here is that some people applying for a job aren't able to write a loop for summing numbers from 1 to 100 in pseudocode. this is not about syntax errors, this is about weeding out impostors who can't program at all. if your argument is: "but i know a genius programmer who's so socially inept and anxiety ridden that they can't write a loop if someones watching!" i.e. "sum = 0; for (i=1..100) sum += i" then sorry, but good luck elsewhere.
  • mateo411 6y ago
    I have this problem. My problem is when I see this question I freeze and then I come up with a solution like this. n = 100; return n(n+1)/2