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

How to win the coding interview

blog.devmastery.com

Post reply on HN
Print view View original

101–110 of 305 posts

Re: How to win the coding interview

#101

Post by meowface »

sundvor wrote: post #4

Very interesting article, thanks for writing! I have but one, eh, comment: > Your code should be commented Sure.. but: > * @param {string} stringToTest - the string to test. > // make sure we have a string. > if (typeof stringToTest !== "string") { > > function isPalindrome(stringToTest) { > ... > // if we get here, it's a palindrome > return true; Do we really need to explain that stringToTest means string to test?…

"// throw if we didn't get a string" before a throw statement two lines away from "make sure we have a string" would annoy the hell out of me in production code.

Re: How to win the coding interview

#102

Post by hvidgaard »

twblalock wrote: post #34
fenomas wrote: post #30

Earlier quoted context omitted.

Couldn't help but chuckle at this: 'use strict'; // avoid ambiguity and sloppy errors If the line that starts (or ought to start) virtually every JS file you ever write can't stand without explanation, one wonders what can!

n++; // increment n

I've had students that did this. It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail. Comments explain assumptions, and often "the why", never "the what" unless it's obscure because of optimizations.

Re: How to win the coding interview

#103

Post by bobbles »

meowface wrote: post #101
sundvor wrote: post #4

Very interesting article, thanks for writing! I have but one, eh, comment: > Your code should be commented Sure.. but: > * @param {string} stringToTest - the string to test. > // make sure we have a string. > if (typeof stringToTest !== "string") { > > function isPalindrome(stringToTest) { > ... > // if we get here, it's a palindrome > return true; Do we really need to explain that stringToTest means string to test?…

"// throw if we didn't get a string" before a throw statement two lines away from "make sure we have a string" would annoy the hell out of me in production code.

I can see a case for it if during the next 2 years of development more code is added between 'make sure' and 'throw...' because you do not want to want to worry about refactoring comments when code gets moved...

Re: How to win the coding interview

#104

Post by richforrester »

EpicEng wrote: post #76
enraged_camel wrote: post #70

Earlier quoted context omitted.

You don't want to pay 10 people for a week. You want to pay one person at a time over a 10 week stretch. That way, you can evaluate each candidate independently and hire the best one. This is undoubtedly a better approach than doing a bunch of coding interviews, so you should have a strong incentive to make sure you have the resources for it. After all, you want to minimize the risk of hiring mediocre people and maxi…

I don't know where you work, but I have never had the luxury of 2.5+ months to get a position filled if we can help it (and it's silly to assume that the work required behind the scenes to get this all working would result in no gaps between candidates, so more than 2.5 months). I also don't typically have the luxury of having great candidates in front of me who will wait multiple weeks to get into some weird one wee…

Thank you, this was almost exactly what I was going to respond with. My only addition:

"Alternatively, we can write/review some code on a whiteboard."

Re: How to win the coding interview

#105

Post by dmoy »

ffn wrote: post #81
kayman wrote: post #36

I'm tired of companies asking me to code at their interviews. I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value. Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Wor…

> evaluate the candidate But candidate evaluation is not an objective business, one company's perfect candidate might be complete trash at another firm. A company's interview process then is necessarily a reflection that company's character, culture, and attitude just as much as it is a process to find potential employees. For example, your suggested hiring process of doing essentially an extended homework assignment…

90% of devs there don't use his software, and we have no idea why his application was denied :/

Re: How to win the coding interview

#106

Post by LnxPrgr3 »

BurningFrog wrote: post #94
EpicEng wrote: post #66

Earlier quoted context omitted.

>Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Work that is small enough to be done in 1 week and big enough to deliver some value. Except now I have to jump through hoops with HR (let's just assume they'd be OK with this, which they almost certainly won't), get the contract in place, work with IT to get your environment set up, and…

I did a 2 week stint like this for a small company once, and the setup took maybe 10 minutes. In a bigger organization it's probably more involved, but if you set out to make it a standard way you interview some developers, I think it's perfectly doable. I agree that improvising it when a developer asks for it, which is what I think you're describing, would be harder.

My first development job worked like that--a one-month trial that got turned permanent something like 2 weeks in, at a tiny company hiring at a slow rate.

I'm glad it got me my first gig, but I'm not sure I recommend it. IME, any position that actually gets applicants gets a flood of hopelessly unqualified candidates. (Think: will fail FizzBuzz, even almost a decade after the blog post that started it.)

Re: How to win the coding interview

#107

Post by kriro »

Sometimes you can also solve whiteboard blackout issues with humor. I once was stuck because I couldn't quite figure out how to implement something (I think it was a peculiar sort). I proceeded to give up after reasoning through it for a bit and mumbled...well I can't quite get it now but let's move on since I'd probably never implement this and if I do I'd spend a lot more time on it and proceeded to add this line at the top of the whiteboard code.

import com.stackoverflow.* ;

One of the people in the room chuckled noticeably. I then went into a mini explanation of importing * vs. direct import (anticipating the obvious question) and was more or less free to use magic whenever I needed it :D

Re: How to win the coding interview

#108

Post by marlag »

I have ~20 years of experience in programming. The hardest part of my work is knowing if I have everything I need in order to classify a particular problem as one of a particular class so that I then can apply the tools that I know of would fit that problem-space and then use those tools to finish my task. For example, is the problem I'm facing a graph problem? If so, then I have a large set of tools (algorithms) to help me solve that problem. But is it a graph problem? It would suck for my employer or client, if I tried to solve a problem within a particular problem-space with tools suted for a different domain. It's kind of like that part of the Swedish standardized test where they test your math and logical abilities by presenting some information and then asking you, do you have what you need to solve this? If so, what is the answer?

Coding on a white board is useful I have come to find if there is a conversation going on and the interviewer use this opportunity to find out more about how this particular person thinks or works.

Re: How to win the coding interview

#110

Post by hvidgaard »

dimino wrote: post #53
jtchang wrote: post #31

Am I the only one that is has been coding for years and don't expect people to know regex off the top of their head? There are so many variants and keeping them straight between languages is a nightmare. Grep, egrep, POSIX, perl, python, php, javascript. They all have their idiosyncracies.

I feel that regex is kind of like SQL -- it's universal enough that knowing the major tropes is important for general software development.

Problem is that every framework have their own dialect of it, and many of them are not even regular expression, but something beyond that.
Post reply on HN