Hacker News Reader

Comment by w1ntermute | Hacker News Reader

Yep - for all their talk about how traditional interviewing is broken, if you go through their screening process, you'll discover that it devolves into the same old puzzles and algorithms questions you get in any other interview. The result being that a terrible software engineer who had spent some time memorizing the highlights of CLRS would do much better on a TripleByte interview than a good software engineer who hadn't spent his spare time studying material orthogonal to his day-to-day work.

View on HN

Hey, one of the Triplebyte founders here. We do using coding problems but we try hard to mitigate the issues you bring up. We give candidates a selection of problems to choose from and we'll often explain how to solve a problem if it seems they're getting stuck. We're less interested in sudden flashes of insight and more looking to see if someone can write code and implement ideas they talk about.

We know it's still not perfect though and our goal is to keep experimenting to find what works best and be open about the results. As we mentioned in our last blog post, we're planning to offer take home tests as an option for our next experiment.

I found the tests pretty interesting and thankfully not puzzle-like, though a little like an advanced fizzbuzz as it was a series of unconnected methods. I was really hoping for some feedback at the end as to how I did and what the weak areas were, do you offer any feedback at all?

Perhaps as well as take home tests you could consider a longer form one which builds a feature using several methods, offering help if required so most people don't get stuck. Say parsing a set of data files, something like that.

When hiring I've found walking through something like real work with candidates most useful, and also crucially using the same challenge for all for comparison.

I've been through the process and it wasn't careercup style puzzle questions. It was mostly practical things or things related to CS interests (programming a game) and they let you google documentation and use any tool you would normally use.

I have also done it. None of the things you mentioned predict success. In fact, very little aside from basic hygiene is likely to predict success, which is what renders these purportedly meritocratic hiring processes so out of touch with reality.

How would you design an interview process ?

The evidence simply does not support present hiring methodologies as predictive of successful business outcomes. Therefore, you should hire and invest in people who need jobs. The reason the increasingly widely accepted status quo of interview processes continues is essentially due to confirmation bias: companies want you to feel like you are part of a special, select team. In reality, we are not that much different from each other. The evidence suggests hiring people who need jobs and dispensing with the bs.

One of the cruelest ironies of the post-recession hiring environment has been how companies are much more interested in hiring those who are already employed.

Where is the evidence that present hiring methodologies don't predict successful business outcomes? I recall seeing evidence re: resumes, but not on the overall process itself [1].

If this data is present (data showing that present hiring methodologies don't predict successful business outcomes), do you have data showing that hiring people who need jobs is any better? We /are/ different from each other -- as an example so obvious it borders on the ridiculous, people who have been programming for ten years will be much faster at it than people who haven't. At what point do you draw the line to state that people stop being different? If so, what data did you use to draw that line?

[1] http://blog.alinelerner.com/resumes-suck-heres-the-data/

Just one instance. https://twitter.com/mxcl/status/608682016205344768 , I've seen hundreds like this.

Honestly, if you weren't in the room you can't tell what happened. It's just as likely that he wasn't a good culture fit.

"Cultural fit" - I forgot this term existed outside of the HBO television show "Silicon Valley".

It's a nice catchall phrase for all kinds of discrimination that would be illegal if stated explicitly. If we call it a gut feeling or culture fit, it's suddenly legal.

Cannot ++ you enough. In my experience, people prefer to surround themselves with those similar to them. The same holds true for any software organization.

It is important to work with people who are you are comfortable working with.

Just as it was important to people in the pre-1960s southern US that their children only go to school with children whose families they were "comfortable with." Somehow, they've since (somewhat) figured out how to adjust to their discomfort.

I understand the paradigm paralysis - we have been led to believe that having the best CS zombies in the world is what makes success, but it's just not true. Meanwhile, jobs aren't filled and the people who need them are suffering.

Reply on news.ycombinator.com