Hacker News Reader

Unfortunately the homework project is usually followed by an in-person whiteboard hazing, which nullifies those benefits. I recently interviewed with a well known tech mini-giant who admitted that my homework assignment was among the best they’ve received, but still flunked me based on the in-person slugfest so YMMV.

Name and shame. This is disgusting.

+1 Hear, hear!

Bearing in mind we're only hearing one side of the story, of course

Assuming, in good faith, that the poster is telling the truth, either the company lied and the homework project wasn’t that good, or they were more interested in whiteboard hazing and the project didn’t mean very much. What’s more like real software engineering: writing code on the spot, on a whiteboard, in front of people; or writing code at home, which you can then have a conversation about? A sane hiring process would put more weight on one than the other, and this company obviously wasn’t sane.

I won’t name but it wasn’t shameful. They ended up looking for someone with experience more balanced between web services and embedded devices, and my background was very focused on embedded. Had they gone purely by the homework, they might not have gotten the best candidate.

May be an NDA issue

What kind of NDA prohibits mentioning the company name and the fact that no offer was extended?

Shitty ones that many devs might sign anyway (i'll admit to not thoroughly reading the NDA's i've signed when interviewing at big companies)

I really think that all technical interview questions should be "open-book". Whether that's doing a homework assignment or simply telling the candidate what technical issues to study up on for the whiteboard.

For the brief stint that I did interviewing, I had candidates whiteboard after doing a homework assignment, but all I had them do was step through the very algorithm they had implemented in the homework using a very simple input dataset. None of them had any issues with the whiteboard, even those who were clearly very nervous/anxious.

Building software is hard enough as it is. I doubt making the coding tasks open book is probably not going to allow in many (if any) unqualified candidates.

Why not go all the way and make it “open internet”? Literally googling stuff takes up a substantial portion of any software engineer’s day. I would seriously doubt anyone who says otherwise.

I agree, though in context I assumed that using the internet was implied by my statement.

I had much the same experience earlier this year, probably with a different company. I think that maybe interview processes are sometimes created via a tug of war between different groups, and to function at all, the people who will be working with a new hire have to have a veto at the end. So you may start out talking to senior people elsewhere that are paddling the boat in a completely different direction.

> If you complain about having to spend a couple hours outside the interview on work, maybe you don't really want the job that bad enough

Maybe I'm talking to more than one company and don't feel like subjecting myself to this absolute nonsense over & over. Maybe I'm just feeling out the opportunity without having to worry about solving a made up issue and hope it conforms to what the employee reviewing it considers good.

What other in-demand professions(based on demand vs. qualified candidates) make potential employees sing & dance, and then go through a full interview process on top of that?

Do accountants have to balance a fictional company's books or find the most efficient structuring of a fictional company's taxes across multiple jurisdictions before being allowed to have an actual conversation with a peer about the role?

To add to this; if a company does want me to put effort into proving I can code a solution to whatever problem, then they better have gone to the trouble of:

a) setting up a git repo with working code in it (including tests, dependencies and whatever else) so I don't have to worry about inane(but taxing) decisions in terms of project structure/code style. Also, verify it works before sending it out to candidates.

b) including clear & detailed instructions on what is expected

c) given the test to current employees (blind) & timed them on it (allowing for the fact they know the domain & technology)

d) make it somewhat representative of day to day. i.e. I have 0 interest in spending time configuring and doing anything which is a 1-off task such as authentication etc..(unless the companies primary product is security/auth)

In short, make it easy for me to prove myself.

(c) and (d) are sensible suggestions, but I've got to question your (a) and (b).

It sounds like you don't think much of testing, if you're expecting tests to be handed to you. Testing is hard! Writing good test cases can be as hard as writing the code itself. If your tests are inane, then you're going to catch the easy bugs and miss all the hard ones.

And when on Earth do you get clear and detailed instructions on what is expected? At least in my current job, I feel like half of what I do is turn vague expectations into crisp technical requirements. If part of the assignment is for you to write a function, I can't include test cases for you because I don't know what type signature you're going to pick for the function. This isn't an inane detail. In some ways the signature of the function is more important than the implementation: the implementation is local to the function, but the signature is going to effect the structure of all of the code that uses it.

> It sounds like you don't think much of testing, if you're expecting tests to be handed to you

Should have been clearer They should have tests to cover their code (not the code I'm going to right).. This cuts down on me adding testing libs needed, any setup, and laying down a pattern for their expectations(wrt tests). With expectation dev would add tests to cover their code.

> And when on Earth do you get clear and detailed instructions on what is expected?

On the job, I have easy access to the information/easy access to the people with the information. Not to mention personal relationships with the people I need to query.

My usage of 'inane' refers to things that a dev on the job won't be doing 99.9% of the time. Things that take effort & thought to setup(initial project setup) but don't really give any insight into whether a dev can write & architect code well. All the things a company already has in place.

Ah, that all makes a lot more sense :-)

An interview is a two-way street. I've walked away from two interviews because the whole ordeal was going to be very time consuming and I just wasn't sold enough on the company.

I did do two coding exercises, though. In one case, the exercise was very fun, and I was able to use it as an excuse to work in a language that I didn't work often in. In another case, I really believed in the company, but I would only do something that took about 1-2 hours.

"Do accountants have to ..."

I'm a qualified accountant, and have, during an on-site interview, been asked to update a company cap table based on some information about additional fundraising and employee grant transactions.

notwithstanding that (itself an interesting data point)

> before being allowed to have an actual conversation with a peer about the role?

During the first conversation with a peer.

>If you complain about having to spend a couple hours outside the interview on work, maybe you don't really want the job that bad enough.

As an employee, I see it the opposite way. If a company is offloading interviewing costs onto interviewees in this way, then I am competing as a commodity and the overall offer is unlikely to be good. A company with this sort of process can afford to test everyone and pick up the 0.1% of folks who are geniuses that don't know that they're worth $150k+ at a salary of $60k/yr.

If I'm not imposing costs proportional to what I'm expending, I'm unnecessarily weakening my negotiating position and setting up the wrong incentives. This is why it's a good idea to get your customer service complaint resolved through tying up a phone agent, making a complaint on twitter, or generating a paper trail that concerns the "no regulatory incidents" department.

>If you complain about having to spend a couple hours outside the interview on work, maybe you don't really want the job that bad enough. People will spend weeks on an unpaid open-source project but then complain about 2 hours for something that might get them a great job.

I've happily spent weeks on unpaid open source projects and I complain about it. Mostly because homework requires no effort or investment on the company's part and it's too easy to hand it out to everybody and then toss candidates' hard work away after it's submitted because they don't like your name or something.

These days I mostly ignore homework requests and point companies to my GitHub profile. I haven't lost any good jobs that way. Companies that erect hoops that make it clear that their time is massively more valuable than yours before you're hired are going to treat you the same way once you're hired.

I disagree that homework is necessarily more realistic. IME all homework assignments have been the same kind of garbage asked by whiteboard happy companies - how to reverse a binary tree, etc. Pointless crap that has no relationship to 99% of real jobs in tech.

When I was running interviews I organized a 1 hour test during interview that was as realistic to the job in question as I could make it. I truly don't see why that isn't the standard.

in answer to number 3, those of us with kids probably aren't going to spend weeks on unpaid open source projects, if we are it will be ones we like, and just as we don't complain about having sex infrequently, watching Marvel movies late at night after everyone has gone to bed, or getting drunk with friends on rare occasions we won't complain about doing something we like as opposed to something we don't like and anyway most people that apply for a job apply for more than one job.

When my last gig got over I went through 10 places over a month and a week to find my next place. If homework was always only 2 hours each time that would be half a work week. The last homework I had to do actually needed some environment setup, but things had changed in some library etc. and I went through nearly 2 hours to setup environment I needed for the assignment. The homework was timed, I had 24 hours to complete from time it was sent. Somebody was sick that weekend and as a consequence I did not finish the assignment.

Supposedly applying for a job should take some hours to tailor make your resume, your cover letter and so forth, then some time to travel to interview and now extra hours to do homework. As far as might get me a great job it's been my experience that what it gets me is a job where people value getting things done but also having fun while doing it, with some foosball games and other perks littered about an open office all seemingly decorated by the same team working globally. There will of course be opportunities to determine the technical direction of projects and perhaps the company as a whole! etc. etc. Perhaps I am fortunate that all my jobs are great, but on the other hand if that is the case I am more likely to go for the job at the place that doesn't make me do the extra hours as opposed to the one that does.

on edit: of course people do complain about having sex infrequently but it is the infrequently they complain about, not the having.

Seconded. I really like the idea of a small homework assignment. Here is the last one I did for an interview: https://github.com/mohaine/expense-allocation

It was a great screen for them and something to talk about durning the interview.

That said you still do need to do some coding during the interview though. We've had enough candidates bring in professional interviewers to solve the coding portion of our remote interviews that there is no way we would trust that the candidate actually solved the homework themselves. We no longer allow any remote interviews due this alone.

Some food for thought...

What if a large group of developers banded together and said "We'll only interview with companies that offer us a range of choices on the interview process, because we want to be able to choose option(s) that suit our strengths. We do this because not only because we want to put our best selves forward but also because this helps nudge companies to explore the space of various interviewing methods, which ultimately makes the companies better off as well because they get better long-term matches."