Hacker News Reader

I have one major disagreement with you:

> I have a Github profile with more than enough stuff on it

Based on my experience only, you're in the minority here. Most candidates I've interviewed have barely anything on GitHub. Some UI/UX-ish people will have a portfolio, which involves a lot of "view source" and isn't too rewarding. Lots of perfectly good working programmers have no active open source participation, not even a "dump of code" type of GH profile, making it difficult to tell wheat from chaff. Having them do code tests is pretty much the only way that doesn't involve talking to every single one.

Look at the other side, too: I've gone through hiring processes in the past as a candidate that started with a 30-45 minute conversation with the hiring manager, and proceeded to the onsite interview stage. This inevitably ended up being the classic 6-hour beatdown, with both sides muddling through without truly understanding what either is doing. These are usually so inconclusive (especially at bigger companies) that no one can make a decision, so they end up saying "no". Now both sides are 6+ hours in the hole. This could have been a simple 2-4 hour asynchronous code test, which would have provided hard information to the hiring team instead of the usual inconclusive bullshit.

> Having them do code tests is pretty much the only way that doesn't involve talking to every single one.

I get where you're coming from. But to me that's still a very, very selfish way of approaching this. You are asking for a blind burn of four hours of their time just to consider talking to them. Four hours is a lot of time. It's half a workday. You're asking for a hell of a lot just to not-a-culture-fit them out afterwards. And from a practical perspective, somebody who's good and employed is unlikely to expend the effort unless you're a very special company, too, which complicates the search.

> I've gone through hiring processes in the past as a candidate that started with a 30-45 minute conversation with the hiring manager, and proceeded to the onsite interview stage. This inevitably ended up being the classic 6-hour beatdown, with both sides muddling through without truly understanding what either is doing.

See...this I don't get. I know within an hour or so of talking to somebody if I want to work with them, and past that literally everything else, aside from compensation, is belaboring the point. And I mean "an hour"; if I'm not enjoying the process at that point, I'll usually suggest we end the interview. But on the flip side, because I am a good community member and I network heavily, I might in those situations go "hey, I think this isn't a good fit, but I want to introduce you to my friend who I think might be a better fit." I've done this before, and I can't do that (and wouldn't be inclined to do it) after you've burned half a workday on a monkey-work project.

I think there are reasonable ways to get a demonstration of work, but they involve investment and give-a-shit that I think most companies are way too happy to be bad cultural citizens to consider. Like, here's a coding test I'd be happy to do: "add this feature to this open-source project you probably use every day", well, that'd be different. I'd be getting something for my time, too, both in terms of feature and in terms of public recognition for open-source contribution. But one-way, dance-monkey-dance, throw-it-away-after stuff? That's very selfish, and I think we should be better than that.

I wish there was a way to scale the "add feature to FOSS project we use" thing. Scale is a concern here because I see this exercise being doled out more than a few times, which means that every instance must involve someone deciding what features should be added. There's also a limit to how much can be added to the same handful of projects over time.

Can't ask all candidates to add the same feature over and over, or else this becomes throwaway code as well, which doesn't address any of the valid negatives you've raised.

> I know within an hour or so of talking to somebody if I want to work with them

Ha ha! I've had an HR department at a BigCorp tell me that there was a minimum duration to each interview (30 minutes for phone screen, at least 45 but preferably an hour for in-person), regardless of how they were doing. Their thinking was that more time spent by us would cause the candidate to consider us a more desirable employer. You can imagine my anguish at having to speak endlessly with people who would clearly never cut it on my team.

"But you can't just walk them out after an hour!"

> Can't ask all candidates to add the same feature over and over

Ehh. Make a list of, say, ten features across the stuff you use. You really think that's not going to be enough for fifty candidates, if the state of the industry is as apocalyptic as everyone says it is?

I don't know, I personally consider an all-day onsite interview to be a bigger waste of my time. With two or four hours spent on a take-home test, those can be any time during the day, probably time that I would have been wasting anyway. An interview has to happen during business hours, which means I have to take one of my scarce and therefore precious vacation days, and then actually go somewhere which is likely to take two hours round trip anyway, and that commuting time is entirely wasted. At least a work sample test can be an opportunity to practice my skills and an interesting challenge in itself. Then again, I actually used to do programming contests back in school so maybe that's just my personal preference.

Well, there's a pretty big difference between 2 hrs and 4 hrs. Most people are applying to multiple places when they are looking for a job. So let's say 3 places a week. Now this is the difference between 6 hrs (already a lot) vs. 12 hrs (practically insane) per week on this stuff.

And at the end of all that work, the candidate receives a binary yes/no. 1 bit of information. On the other hand, the 6 hour 'beatdown', as you term it, gives the candidate an incredible wealth of information. They see what their prospective coworkers are like, what the office is like, how people interact with each other, maybe what people talk about over lunch. So 3 interviews with 1 bit of information (12 hrs) each or 2 on-site interviews (12 hrs) with a hell of a lot? What's the rational choice?

And I'm not against programming assignments, but 4 hrs each?

Nearly all of the work I do for my employer is on public github. I always wonder though because if you just went to my personal github page it's not necessarily obvious that my Day Job is just a click or two away as these are contributions to another public repo, not one of my own. My own personal repo collection has close to nothing related to any job I'd ever want.

How do you feel about the all day interview process some large companies are currently using? Keep in mind you probably had 1-3 phone + computer interviews before the in person interview.

A take home test seems like a less time intensive process as you at least don't need to take time off from your normal job to do it.

Are you paying as well as these top tech companies? Do candidates know it?

Are you providing as many career opportunities and growth as Google/Facebook/etc? Do candidates know it?

These big companies get away with it because their hiring funnel is jam packed with top talent.

Rejecting a lot of top talent is no big deal for these companies. There is still tons of top talent who will jump through the hoops.

But a big hint: they won't jump through the hoops to work at your company!

> How do you feel about the all day interview process some large companies are currently using?

I don't go for the all-day ones (I just decline; after my last Google interview I'm done putting myself through the wringer for a whateverjob), but I really do enjoy in-person interviews. Like, last time I was looking for a FT gig I did at least a phone interview at 35 places and an in-person at 20. I enjoy interacting with people. I get a great lay of the land of what the market looks like, what's not just "cutting edge" but what is, in practice, the leading edge of what people are actually trying to use in anger. This is, in addition to just learning about a given company, why I view in-person interviews as a two-way street. After my last FT company shuttered, I moved into consulting largely because I have a better view of the world than most people working for individual companies. I've learned, from talking to a ton of people, many things that might even seem like offhand facts from idle conversation that have helped me. Like, I happened to remember that D3 instances exist in AWS from a chat with somebody on one of those interviews and in the process I saved a client $20K/month in EBS costs.

Maybe it's a Shockingly Minority Viewpoint, but I think that, in a healthy business relationship (and it's important to realize that employer/employee is a business relationship), both sides get something, even if it's the short relationship of an interview.

I love interviewing. Like, I'd do it as a hobby if I could. That said, my own preferences are not likely to be salient to the greater community of potential hires. So, I have to put them aside when designing hiring pipelines.

Having given this problem a lot of thought and experimentation, I've come to realize that designing good work sample based hiring pipelines is very difficult. Designing hiring pipelines based on something else is impossible.

In addition, Take-home test is better because it is more flexible than an in-person or even phone interview.

At my company, we use take-home problems to answer: "is this person worth interviewing?" Can you take a simple problem and code us an equally simple solution? It's basically FizzBuzz.

I rarely have people balk at doing this, but when they do, I'm happy to look at other code samples. I just need to know if they can write code.

Totally. And I mean, I don't think I'm unreasonable. If it's the kind of thing I can reel off the top of my head or open `pry` and bang out in a couple minutes, I'll usually indulge. It's the multi-hour odysseys that are a big nope.