One Hour Hire - Hacking Engineer Interviews

Sorry, but they&#x27;re crazy if they think halfway decent engineers are going to spend 7.5 hours of their time doing a coding quiz before they even have a personal interview with them.<p>They seem to be forgetting that potential engineers are interviewing them just as much as they&#x27;re interviewing the engineers -- and such a crazy up-front time commitment is a sure way to weed out the engineers who have better things to do with their time.<p>This may be scalable for the company, but it certainly isn&#x27;t scalable for engineers looking for jobs at multiple companies.

There&#x27;s no shared risk here, it&#x27;s all on the candidate. Bad form.<p>Only something along the commitment of the 0.5-1hr &quot;weed out&quot; question can&#x2F;should be done remotely.<p>If you&#x27;re going to require people to do ~7 hrs of tests, that had better be at the office, pairing, with other folks (and at least give them a free breakfast&#x2F;lunch&#x2F;dinner!). 7 hrs while working a 40hr (or more!) week is a pretty hefty commitment, and I see no reason why that should be solely the burden of the candidate.<p>You should be able to trust one or two short, simple weed-out conversations (I tend to do one 30 minute &quot;deal-breaker&quot; discussion on non-tech stuff {make sure their and our deal-breakers are met}, then one about 1hr tech screen {fizzbuzz-sorts of things, but more diagnostic}).<p>After that, you should have a general sense of whether or not they are a) smart and b) can get stuff done. From there, you need to take a risk and bring them in. What is proposed is not fair to the candidate.

<p><pre><code> &quot;unable to implement a simple linked list&quot; &quot;Vet the technical competency of full stack rails engineers...&quot;</code></pre> because there are linked lists in ruby? <i>rolleyes</i><p>3 hrs of backend&#x2F;algo testing? <i>rolleyes</i><p>4 hrs of frontend? <i>rolleyes</i><p>I hope they enjoyed tooting their own horn, yet another place I know to avoid bothering to interview at.

Wow, what a douchebaggy post. I had good impression of Instacart as a product, but clearly Instacart as a company doesn&#x27;t deserve that level of respect. They&#x27;ve completely failed to assess their potential hires on what actually matters.

Unfortunately, I&#x27;ve done a 5-7 hour &quot;project&quot;, only to not hear back from the company for a month - and then it was from a recruiter, not a developer, who just told me that they had decided &quot;not to pursue further&quot;.<p>I decided at the time that I would never do this again, and that&#x27;s still more or less the case. I might be willing to make a deal - if someone from the company is willing to put a workday into one of my open source projects, even just trying it out and writing up the experience, I might be willing to spend a workday on their programming assignment.<p>Or, of course, if my family was starving and I was unemployed, I&#x27;d do it.<p>One huge difference here - they do say they&#x27;ll give <i>detailed</i> feedback. If I had gotten detailed feedback on my programming assignment instead of crickets chirping for a month and then a recruiter call with a one-sentence brush off, that would have taken quite a bit of the edge off. I do give them credit for this.<p>But still, they are mainly looking for a way to use a candidate&#x27;s time to their own at an 8:1 ratio. For me, this is a &quot;no apply&quot; condition.

Yet another company that pretends to believe the &quot;1 in 100&quot; canard:<p><i>If we assume that only 1 in 100 qualified engineers meets our bar ..</i>

Am I missing something here? The title says 1 hour hire but the problem listed says 7.5 (rails test: 0.5, backend: 3, frontend: 4). That seems anything but efficient and somewhat strange.<p>Why not provide the potential candidate with some actual work that you need done?

I know of few non-entry level developers of any reasonable skill level that would seriously consider this one-sided of an interview process unless there was some clear potential reward. Getting a job at instacart hardly sounds like something to get excited about. It sounds like they&#x27;ve &#x27;hacked&#x27; themselves out of consideration by many talented programmers.

Algorithms are easy, the solutions are all online. Cleaning up code is hard. Give the candidate a project with some failing tests and messed up code. Tell them to clean it up and add a feature or two. Congrats, you just tested someone on what they will actually be doing in their day job.

&quot;A rejected candidate should know unambiguously why they didn’t get the job.&quot;<p>I&#x27;d have to say that&#x27;s my favorite thing about this process. All too often applicants go away with no idea about what exactly why they weren&#x27;t a good fit. If someone gets rejected, the least you can do for them is to tell them how, so they can improve themselves.

&quot;...We&#x27;ve had to pass on some amazing engineers just because they did not have the rails web, front or back end experience. &quot;<p>Why would anyone want to work with amazing engineers?

&quot;hacking&quot; this, &quot;hacking&quot; that. the word is being way overused. just because you came up with a solution you think is good for you doesn&#x27;t mean you &#x27;hacked&#x27; anything.

You know the worst part about this? Once you&#x27;ve got through all that shit, you&#x27;re working on a shopping cart.

Maybe it works for them, but I don&#x27;t find any motivation to work on test project that exist only for their own sake. I mean, if the test project is actually a part of the real project that I would be working, then that&#x27;s okay. But to build something with made up requirements puts me off.

&gt; The candidate will join us in the office towards the end of the day, where we’ll spend time getting to know each other over dinner <i>or beers</i>.<p>Really?<p>The technical portion of the interview process described here is receiving a lot of well-deserved criticism, but I feel this is worth pointing out as well because it&#x27;s another example of how out-of-touch this company seems to be.<p>Any experienced candidate knows The Rule (don&#x27;t drink during the interview process, even at a social event), so an employer that <i>intentionally</i> puts a prospective employee in the position where he or she is effectively <i>asked</i> to do so is incredibly unthoughtful. And foolish to boot, as this could very well become a legal liability.

This is a powerful example of how (some) VC-backed companies fall into the trap of optimizing for hiring velocity rather than product-market fit.

The biggest waste of time is that candidates have to demonstrate general competency to every company he or she is considering. It&#x27;s a waste of engineering resources checking every candidate and a waste of time for the candidates. Is there a way to unify that across companies (other than by creating a certification scheme)? Is there a way to standardize the code sample procedure?

There&#x27;s always at least one idiot who responds to a perceived imbalance in a particular domain by going to the opposite extreme. This is not a good solution to the problems with current tech interviews.

The problem with this approach is that it is unnecessary time consuming on the applicants side and that the tests aren&#x27;t language agnostic. The goal to reduce the in-house effort is reasonable, however it can be achieved a lot easier. You can filter the 90% of applicants that are not qualified in tests that only take a couple of minutes. In my opinion the goal of automation in the hiring process should be limited to filtering out the obvious misfits, otherwise you risk to miss hidden talents among your applicants.<p>In the end you rather want to hire a brilliant engineer with little experience in the desired technology stack than a mediocre developer that is able to pass your automated tests because he has worked with the technology for years.

We (Heap) would use Manchuria if you were to open source it. We currently have a multi-tab spreadsheet. My previous employer had an awful Salesforce system which was about as fun as eating sand.<p>You might even get a PR or two. :)

I wish more places had a policy of giving detailed feedback... it&#x27;s bad enough getting rejected, but the stone-faced manner in which most places seem to do it makes it even worse.

The lack of respect for candidates is kind of frightening, given the current job market. What I&#x27;m hearing is that a successful candidate (one who goes through the whole process) is 1&#x2F;8 as important as a current employee (based on the hours they&#x27;re willing to put in). This sounds like it will do a great job of filtering candidates - assuming, of course, that you&#x27;re trying to filter for employees willing to put up with abuse from their employer.

In Sydney and London it was common to hire a contractor for a short term, put them to work on your project, and if they are any good offer them a full time position.<p>As long as this is made clear in the interview, I see no problem with this process.

Attempts to get free labor out of interviewees have already been tried by other unethical companies in the past, and most seasoned developers know not to fall for this.

&gt; A rejected candidate should know unambiguously why they didn’t get the job.<p>Yes. One more non-arrogant company.