Hacker News Reader

Comment by azinman2 | Hacker News Reader

I really disagree with this. Yes it’s crappy if you put in many hours and don’t get the job. Interviewing sucks for everyone. But having been on both sides of this equation (hiring and being hired), I believe the take home is the best chance to evaluate someone. They’re able to work without the pressure of someone staring at them and clock ticking, given google and all their normal ways of working, and something long enough to be able to more realisticly assess them.

It’s amazing what a short assignment can tell you about a person, and it makes the follow up on site productive because there are so many ways to ask about their work.

Personally for Apple I asked specifically to be given one of these instead of the whiteboard, as I get overly stressed in a “pop quiz” type setup. They still ended up pop quizzing me twice, and one of them I didn’t do well on. It was my take home that pushed me over the edge and got me hired.

View on HN

NO FREE CODE. After getting through the recruitment hell I settled for one important rule for my sanity - symmetric time and effort involvement, i.e. pair programming with the engineer, onsite session with the team. Otherwise the project will likely be rejected for the most trivial reason but in fact most probably because of finding someone more desperate and cheaper. And yes, I've been on the other side as well interviewing people once.

> pair programming with the engineer

This is probably the single best interview session I've ever had. Give-and-take is always good for easing the process, but in one case I had a programmer actually sit down with me at a laptop and pair program our way through an hour task. Still time pressure, I suppose, but it was vastly more natural and informative than any other interview I've done.

I had one person say after I put in 4 hours "The code wasn't clean". That was his feedback.

I pressed him and he eventually said "I ran this by 3 Senior Python experts I know. All of them said the code wasn't good." No other details.

Before he even gave me the assignment he made his decision. He lied about asking 3 other people.

Coding assignments are always one sided. Unless someone from the company is going to sit with me and invest equal hours into the project, I will never do another one.

They are used by companies to filter out desperate employees (young engineers who don't have reputation to fall back on, or nothing to lose by doing it) and it signals a lower value to the company.

Perhaps the opportunity of the assignment was to “right the record,” hoping to be surprised. It would have been nice to be more upfront about that.

I disagree with the notion of desperate employee — I’m anything but that, but I prefer a take home to show my engineering worth rather than a whiteboard if those are the two choices. Of course if you’re super famous then you probably won’t get either, depending on the company and it’s processes. That said I’ve been down the M&A path and still got (many) whiteboard interviews.

> if those are the two choices

I would be shocked if any company in the world gives you this choice.

Apple did, and I’ve had others do so in the past as well.

That's bullshit. When I was hiring I needed a Skype/Phone call, and 1 hour of on-site or just another more technical call/interview (1-2 hours max if it goes really well). Hired 3 great folks and 1 that decided it's not a job for him, because he found it boring after all.

I never take the "a couple hours long assignments" because the scope is never "a couple hours", once company wanted me to build a chat service that would take at least 20 hours of work to get properly done with testing, etc.

Absolutely.

I'm talking one that I recall that asked for parsing Apache logs from a stream, displaying moving averages for most popular URLs, aggregates of visitor counts, having high water mark "alerts" for ingress traffic and monitoring rolling averages to "de-alert" when traffic dropped below that, including of course unit tests and documentation...

One, that's more than a couple of hours. And two, that sounds awfully like something you're planning to use, whether I'm hired or not...

Not everyone performs well in a technical call, especially since the questions rarely correlate with the daily job / workflow. Sounds like you found people who did.

From reading the Reddit post, I think it's the combination of a take-home assignment plus the standard on-site whiteboard test battery that the OP was arguing against, and I admit I'm sympathetic to that. I remember interviewing at one place a few years back that had a relatively complex at-home assignment -- you had to write code that would hit various URLs that would return a string containing a long basic math formula (e.g., "1234-(3529(42-34)/2)+45", but going on for ~60 characters), write code that would parse that string to produce the result, then hit another URL pointed to by the result, while treating all the results as a node graph you needed to find the shortest path through. Granted, I'm one of those annoying self-taught programmers without a computer science background, so I probably found that a bit harder than someone recently out of school with these algorithms fresh in their mind -- but I got through the challenge correctly, wrote pretty nicely-structured and commented code to boot...which was, as far as I can tell, completely ignored* by the interviewers, who just asked me more on-the-spot algorithm questions instead.

I've been at other interviews in which the on-site interview is a walkthrough of the code I'd written, asking questions about why I made various choices. I think this is really a much better way to do programming interviews. It still weeds out people parroting code without understanding it, but it's a better example of what a candidate's actual code looks like -- and for the vast majority of programming jobs, that's probably more important than whether they've memorized algorithms that rarely come up outside other whiteboard tests.

I spent multiple hours on one assignment, only to have the guy tell me off in a 2 min email. Didn't even have the courtesy to give me a call and let me justify the decisions I made with the code.

If you want me to spend more than 30 minutes programming for you, that's called work, and I would like to get paid for that.

They shouldn’t be asking you to code anything related to their actual work — it should be a toy assignment.

I think it all comes down to personal pref, but the data seems to show that whiteboard interviews are good to filter middle of the road talent, but top/bottom can look the same.

It doesn't matter what they use it for. They can use it all they want as long as they pay me for it.

> Personally for Apple I asked specifically to be given one of these instead of the whiteboard, as I get overly stressed in a “pop quiz” type setup. They still ended up pop quizzing me twice, and one of them I didn’t do well on.

I get a brain freeze when the clock is ticking. I've been practicing with ticking clock but its still hard.

None of the companies showed even 1% flexibility with their process. They say its a standard and they can't compare candidates if they use different methods for everyone.

Use interviewing.io to practice this (and possibly get a job out of it).

Companies will differ depending on the role, team, and who’s interviewing you.

Reply on news.ycombinator.com