Live data from Hacker News

Take-home interviews

blog.triplebyte.com

131–140 of 295 posts

Re: Take-home interviews

#131

Earlier quoted context omitted.

I have pseudo-coded on blackboards many times, which is really what a blackboard coding interview should be. If you get a ding for writing .foreach instead of .forEach, that seems a bit picky ;) However I realize I may have a bias as I do ok on most blackboard coding interviews I have done.. maybe been stumped 1 time out of 15 or so in my life? Some of it is a skill, that the more you do the better you get at it, but…

> I have pseudo-coded on blackboards many times, which is really what a blackboard coding interview should be. If you get a ding for writing .foreach instead of .forEach, that seems a bit picky ;) In my experience, some interviewers, particularly Amazon interviewers, get really anal about putting correct code on a whiteboard, sheet of paper, or bare text document. I personally do not when giving interviews. My bigger…

> In my experience, some interviewers, particularly Amazon interviewers, get really anal about putting correct code on a whiteboard

I had that experience with an Amazon interviewer. The guy who told me he expected perfect code also gave me zero feedback as I worked (despite me literally asking if I was headed in the direction he expected) and spent the entire time staring at his laptop. He'd apparently forgotten that he was scheduled for an interview, and also his manners.

Re: Take-home interviews

#132
I considered a job out in SF working for a decently well-known guy, Andrew Chen. I had gone through 4 coding interviews progressively working my way up their ladder to their CTO. Now, each of these I did well on but they didn't like how fast I went. Despite them saying "Our fastest done was 1hr!", they didn't seem to appreciate me going fast and came to the conclusion that I probably didn't know how to write production code -- just a quick hacker. Actually, it was rather annoying because their "top" iOS dev didn't even understand basic shit I was doing. He'd have to keep stopping me and being like wait -- why'd you do that? Yet as I worked my way up, I really enjoyed a couple of their engineers and CTO. I didn't have to hold THEIR hand during a code interview.

So I was an iOS developer getting considered for Android position, and they said "hey it's great you can code fast & all, but can you learn fast?" and told me to create an Android app that searched images on Google. I sighed because I had already been through 4 coding interviews, but oh well, this will be it I thought. Since I wanted to do a good job, I spent two hard days working on it basically all day every day. Since I was new to Android world, I had to learn that while being productive. You can see the result of my efforts here: https://github.com/joslinm/android-image-search-example. I thought I did a nice job because rather than using a HTTP library, I read the streams myself to give nice progress indicators for each image (which persisted even thru phone rotates).

I give it to them and they say, "ok seems to be working." After that, I was invited to SF to interview with them in person -- actually, interview is the wrong word, I would be working with them for 2 full days. So we did that. When I wasn't coding, I was being grilled about my work history (perfectly acceptable, but why didn't we do this earlier?). Finally, after that, I was told they had come to their decision. Thinking I was a shoe-in, I went to go meet with Andrew. Andrew's decision: "You're too entrepreneurial."

Now let's examine this for a quick second. They had come to a pretty fair conclusion that I was too entrepreneurial after talking to me. They realized, hey this kid is a go-getter and probably isn't the greatest fit for our #7. Yet this was AFTER copious amounts of coding and wasting my time doing all these code interviews and even joining them to code in-house. If they had just went about a pretty normal interview, they would have discovered this fact way earlier and not wasted either of our time. So why waste my time forcing me to code before they do their diligence? Because he's Andrew Chen; you can google his name and discover who he is. It would be a "honor" to work for such a prestigious start-up pundit. In other words, he can get away with it.

For those of you considering a start-up and actually have skill.. don't get taken advantage of by these bogus work projects. The employer wins because he's not paying you and gets a lot of evaluation for free. And if they do insist on you working with them for a couple days, you insist on getting paid for those couple days.

Re: Take-home interviews

#133

Seems good, I like the choice. In discussions on this topic I see a lot of: "Programming on the spot is hard, let people program at home"! But then other people say "Why should I program for free at home, my resume clearly shows I am already a skilled programmer. All this will do is cater to young people without families, or those fresh out of school". I am not looking to hire devs right now, but I am thinking about…

> Offer $500 as a 1099 contractor to complete the assignment within the next 2 weeks or so. I like this, not for the money, but because it guarantees that the company is not giving this assignment to 100 different candidates ($500 x 100 is getting prohibitive for a hiring budget). I'm more willing to put the effort if I know I'm one of the "finalists" for the position.

Agreed that it's a positive thing to actually pay people for nontrivial amounts of work.

Downside is that, as a company paying someone to accomplish a task, I'd want to give a different task to each applicant, so that if they do a good job, it provides value to the company.

And this is a problem because rarely are two programming problems exactly as difficult as each other, so the test isn't normalized. Interviewing is hard enough when you keep all the variables that you can control the same.

Re: Take-home interviews

#134

From the employees' perspective: Take home tests are the worst. Company says take home test will take 3 hours to complete. They never do. Schedule 2x or 3x the estimate. Especially if you want to impress the reviewer. You send it over, then the company says no or yes, only to move to new stage. In the worst case you ruined your weekend and received a no. But the company just took 10 minutes to arbitrarily reject your…

Or, if they don't actually expect you to spend more than 3 hours on the task, they will compare you to people who have spent 9 hours on it.

Had that recently: they said "spend no more than two hours on it" so I finished in about an hour and 45 that evening and flipped it over.

Then they started asking why my 20 or so unit tests only covered the basics when other candidates had full unit tests in the two hour time frame. I told them the other candidates were simply lying :-)

Re: Take-home interviews

#135
I would never take this option.

At my current workplace, I have the tools I need to work. Most of my softwares licences are under my employer's name. I have access to my snippets, my previous projects and many build processes (minifying my code, preprocessing my CSS, etc.). My workflow is great.

If you give me a project to do at home, I can't use any of that.

I would have to spent hours working either from my bed, my dining table or in a coffee, on a laptop. I would also be required to work on this project after the 40h/week that I already do.

I'll take the regular interview any time.

One of my worst interview process was one time when they required me to do a project of 20+h in a week. They knew I was employed elsewhere, so they let me give it Monday instead of Friday. This was ridiculous.

Otherwise, everything was doing very well. However, the experience really discouraged me from working there.

But I guess it's not all that bad, because I most likely dodged a bullet. If they can't even give correct deadlines to future employees, I can't imagine how they threat their own employees.

Re: Take-home interviews

#136
post #79

This is presented as a weeding out technique but it is actually a negotiation step. This allows the employer to establish precedent that you work off hours from home. This allows the employer to identify candidates that are willing to do whatever it takes for the job. These are the same people that won't do hardball negotiations for salary, employment terms or working conditions. Rather than weeding out the people wh…

My strategy was to tell them something like "First I'm going to interview at all the companies that don't require take home assignments, and then I'll get back to you if I don't have a job by then".

This. Happened with my most recent round of interviews. I took an initial stab at one assignment, moved onto other opportunities, and landed an offer before getting back to the project work.

At least the take-home work I did perform in my second-to-last job search provided good, compact example code for my last search.

Re: Take-home interviews

#137
post #125
post #48

Take home interviews are a great indicator of a company's hubris. "Its so awesome to work here people are going to jump at the chance to do my 3 hour homework assignment". The problem with them is fundamental: "You will only get someone desperate enough to take your exam." If the person is qualified they will be swimming in opportunities and will likely throw your exam directly in the trash heap. If they aren't you p…

> The problem with them is fundamental: "You will only get someone desperate enough to take your exam." Lots of people do poorly in whiteboard situations. As an employer, you may assert that you don't want any of them, fine. But I don't see the problem in giving people the option of using an alternative testing process.

Wait - where does it say this is an option? It isn't as far as I can tell - it is how they do it. You either invest 3-9 hours on a "project" before the interview or you don't get the interview.

This isn't "an alternative testing process" as such.

Re: Take-home interviews

#138

Earlier quoted context omitted.

> What other role requires you to complete an exam to be considered for a job (or even just an interview). Moreover a 4-8 hour exam with no syllabus. No 'past papers' etc As far as I can tell, essentially all of them. Of course, many of them have no practical way to even attempt to assess competence, so they fall back on "situational" and "culture fit" bullshit. > I think this should stop. In it's place, developers c…

"Problem the 1st: how do you verify the example project is actually the candidate's own work?" Have them discuss the code in depth. Architectural and design decisions, coding conventions, alternate approaches they rejected, etc. Pretty hard to fake this if they didn't write the code. "Problem the 3rd: evaluating a large, unfamiliar codebase is actually really hard." Good chance to assess the candidate's ability to do…

Yes, but that switches the cost back onto the company instead of the employee.

Re: Take-home interviews

#139
post #125

Earlier quoted context omitted.

> The problem with them is fundamental: "You will only get someone desperate enough to take your exam." Lots of people do poorly in whiteboard situations. As an employer, you may assert that you don't want any of them, fine. But I don't see the problem in giving people the option of using an alternative testing process.

Wait - where does it say this is an option? It isn't as far as I can tell - it is how they do it. You either invest 3-9 hours on a "project" before the interview or you don't get the interview. This isn't "an alternative testing process" as such.

I logged into my TripleByte account and selected it as an option. The UI is still broken, but yes: it's an option. It's a separate track you can choose to be on.

Re: Take-home interviews

#140
I've done quite a few "at home" programming challenges [1][2][3] as well as hacking challenges and most of my experiences have been overwhelmingly negative. The challenge is that "programming" is about 20% writing code and 80% other stuff (requirements, design, testing, security, documentation, meetings, beer, etc...). It seems like the proposed solution is not addressing the problem: Explaining how to solve a programming challenges you may have never heard of on the spot.

I do agree that interviews add a level of pressure, but what you're trying to gauge thought process. How does the candidate think about solving the problem; Can they iterate; Can we lower the space and/or time complexity; Can this be solved recursively, Are they receptive to input? A take home assignment does't help you figure any of that out. Usually, the team who is interviewing already knows the answer to the specific problem and all of the intricacies (based on having to solve it on an internal project or just because it's a question they've asked before), but the goal is to see someone thinking in real-time.

In my career, I've never had a time where I go off on my own, work on something and come back to the team with a solution. Even when I was writing TI-83 programs in High School to solve all of my science homework and finish 50 minute tests in 10 minutes; I still had classmates asking me about what I was doing along the way. There is always discussion and I feel like by sending me off on my own, all of that goes out of the window. You can't verify if I copied the code from anywhere else, you don't know if I had my buddy who is an engineer at another company break down the answer for me to spit it back to you, and you don't know if I paired with someone else to get the assignment complete. I'm obviously biased based on my experiences doing over 40 interviews in Silicon Valley/SF. My goal for this type of interview question would be to understand how the candidate thinks; I don't care if you write your answer in Brainfk[4].

[1] - https://github.com/joeblau/sample-elevator-control-system

[2] - https://github.com/joeblau/sample-top-ten-tweets

[3] - https://github.com/joeblau/sample-url-shortner

[4] - https://en.wikipedia.org/wiki/Brainfuck

Post reply on HN