Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

  Why not just have candidates accomplish the thing you're
  assessing with an actual relational database?
My employer interviews like this, and I can tell you one reason it's not very common: It's a pain in the ass.

After all, it'd be unfair to judge someone on a platform they weren't familiar with - so now you gotta maintain a fleet of laptops with a really wide range of tools. And these have to sorta float outside the usual IT management system because they aren't really issued to a single person, and you gotta be online enough that people can google stuff, and you can't have hiring managers let other people use their login, that'd be bad security practice. And if you didn't confirm in advance what platform the candidate wanted to be tested on, you gotta haul three laptops to the interview. Oh, they're pretty good developer laptops and one went missing? We really ought to have people sign those out...

And even after that, you _still_ have to apply subjective measures like "were their variable names clear?" and judge them on communication - like if they see an opportunity to refactor the code for clarity, but they say they're focusing on completing the task before spending time on that.

I'm not saying it's a bad thing to do this, just that I can understand why many companies don't.



It is harder to build a work-sample regimen than to just send candidates to interviewers, sure. But then, the point of Triplebyte is that they're eating all that work for you.

Regarding "fleets of laptops" and environments and all that jazz: these seem like unforced obstacles. Just have the candidates use their own machines. Here's a crazy idea: have them use their own offices/couches, too.

Regarding security practices... come on. We have an interview process that involves giving remote developers read/write access to an entire AWS environment. These are simple engineering problems. If they're the only thing stopping you from having a better interviewing process, and you hire regularly, just go solve the problems.


  Just have the candidates use their own machines.
We tried inviting candidates to bring their own laptops, and it turns out often they didn't _have_ laptops - or we'd tell them there was a Java-based test and (perhaps due to a miscommunication or because this is an uncommon interview practice) they'd arrive with a laptop without a working Java VM or compiler.

Needless to say, you can't objectively compare two candidates' progress if one of them spends half the interview trying to get their environment set up!

  Regarding security practices... come on. [...]
  These are simple engineering problems.
Perhaps I wasn't clear: My employer is a medium-sized company, and consequentially IT security is actually a complex political problem rather than a simple engineering problem.

You've also made a pretty big shift in the goalposts there, from asking "why don't companies have candidates accomplish the thing they're assessing?" to asking "why don't companies have candidates accomplish the thing they're assessing, and perform remote video interviews, and have the ability to give spin up clean AWS environments and give remote semi-trusted interview candidates access to them?"


If you insist on doing the interview in person, why not just tell them ahead of time what their environment needs to do when they get there? Give people instructions and a script (formal or just a numbered list of steps) that determines they're ready to go.

Better yet, just don't make people do that stuff in your office.

Why bother videorecording interviews at all? I'd have problems writing a line of code with someone breathing down my neck. If you did it to me on the job, I'd chase you out of the room. I feel like a lot of these problems are, like I said, unforced.

Agree to disagree about the degree of difficulty of getting clean environments to candidates. You're either serious about recruiting as an engineering problem or you're not. "Not" is fine, but then don't pretend like there's some kind of rigor in deciding which corners you're willing to cut.

I'm not making this stuff up; this is how we've been hiring people for about 10 years now, and every time I hear someone explain how challenging or untenable our process is, I keep wondering, "what am I doing wrong to make this work so well for us?"


  Why bother videorecording interviews at all?
We don't record interviews. By "remote video interviews" I meant "remote interviews by videoconferencing such as Skype or Google Hangouts" which I assumed was what you meant when you proposed candidates use their own office or couch.

  why not just tell them ahead of time what their
  environment needs to do when they get there?
We did this, including a github test project they could check out and build to make sure everything was working. Still, about 50% of candidates arrived without a working environment.

We chose to supply a known-good laptop instead of rejecting such candidates instantly when they've spent time travelling to us etc.

  every time I hear someone explain how challenging or
  untenable our process is, I keep wondering, "what am
  I doing wrong to make this work so well for us?"
I'm not saying your process is challenging for _you_ given _your_ situation; I'm sure it works very well for you! I'm saying it's challenging for _us_ given _our_ situation :)


Maybe I'm being unclear. I'm asking: why does there need to be video or telephonic oversight of any sort for a work-sample challenge? Why are you assigning yourself that problem? We've never done that and never had a problem.


Ah, you mean a take-home test?

Some people involved in our hiring process don't like them, they say experienced candidates stop responding when sent take-home tests. Their theory is employed people with families don't have the time - although we don't have hard empirical evidence for this for obvious reasons.


People don't do take-home tests because companies give them in addition to interview loops. I'm saying, just do the at-home test, and cut out the interviews.


> Needless to say, you can't objectively compare two candidates' progress if one of them spends half the interview trying to get their environment set up!

If most of the issues revolve around having roughly the same environment for candidates, just create ready to go VM images, for example VirtualBox, and share that with them. Or use a cloud desktop VM.

All of which make it easier for someone to succeed.


> Just have the candidates use their own machines

I agree with you generally, but you'd better have loaner machines ready. Not every candidate currently has a working, dev-capable laptop. Economic bias. (Hell, my current laptop is only 70% functional because I can't decide if I want to repair or replace it.)


If economic bias is your concern, then you shouldn't be asking people to travel onsite for a tech-out interview; you should be doing everything you can to make tech qualification remote, so that by the time you need to call them to your office, you and the candidate have a pretty good idea it's worth disrupting their work and home life with the trip.

After hundreds of interviews (I have no idea; lots, over 10 years of almost continuous hiring) I've never run into a candidate that couldn't do a tech challenge remotely.


And I don't know that that's better than "walk me through the query you'd use to do X". Because the reality is they may need to look up the exact syntax for something, and I can't gauge how much they actually know based on their googling; someone who knows nothing might stumble on a good search and seem to get it really quick, someone who knows all the fundamentals might spend 5 minutes trying to find a keyword that's just slipped his mind ('having', for instance, which I've used maybe...once? :P), who will seem like they know nothing.

Instead, just describe it to me. Best guess it. We'll dive into that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: