Live data from Hacker News

A Method I’ve Used to Eliminate Bad Tech Hires

mattermark.com

81–90 of 517 posts

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#81

This is literally the only way I've gotten job offers. I'm a very competent programmer, but when I'm asked to solve some silly puzzle with someone staring over my shoulder, I freeze under pressure and can not think at all. Luckily not everyone thinks solving leetcode problems is a good way to hire.

If you can't code under pressure, you aren't a very competent programmer. Real world projects come with high pressure scenarios for software engineers. Code monkeys may be able to get away with low pressure, minimally impactful projects.

It's not like software development is the same as being a fighter pilot.

Code now or die isn't usually something most people face in their day job.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#82
The 2 hour version of this is what I've always done in actual interviews, except where we peer develop the solution together the whole time, and I let the candidate drive and lead as much as they want to.

The take home version might be useful beyond that, but I've found that solving some fun toy problem like, "let's build a little app for X" in a couple hours you absolutely know if the candidate can code and have a good feel for what it would be like to work with them.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#83
post #38

This is one of those "aha" solutions that people keep mentioning, but completely ignore how it would work in a non-ideal world. • What 2 hour project can you assign that would let the candidate go into enough depth for you to judge their code, design decisions, architecture skills? • If you give them more time (e.g. a weekend like in the article), is it still financially viable to the company, especially at $100/hr??…

Exactly. Their example:

> "Create a single page app that lets me enter movies in my home movie collection, store them in offline storage and search through them. I want to search by Genre, Title & Actors."

Significantly more than 2 hours, unless you are looking for a quick hack and for the candidate to repeatedly explain "I would have done it this other way if I had more time..."

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#84
post #82

The 2 hour version of this is what I've always done in actual interviews, except where we peer develop the solution together the whole time, and I let the candidate drive and lead as much as they want to. The take home version might be useful beyond that, but I've found that solving some fun toy problem like, "let's build a little app for X" in a couple hours you absolutely know if the candidate can code and have a g…

No, yours is different, basically an exam, that requires a lot of preparation, good sleep, etc. to perform well. Very few would be able to do it.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#85

This. 100% this. As many others are saying, I find that this is the most comfortable way for me as an interviewee to demonstrate that I do in fact know what I'm talking about. Put me in front of a room full of people and a whiteboard and throw something at me, and I'll freeze. Freezing in that situation and being a bad engineer are wholly separate things. Anecdotally, when I get one of these problems, I spent 20 minu…

This isn't a viable approach for much of the hiring pool, as a majority of working engineers have contracts which explicitly forbid work for contract for other employers. As such, if you hire any of those, you're hiring somebody with a proven willingness to ignore their contract, which is a strong anti-pattern.

It's possible to not pay them. Most candidates will do this for free, as it's far better than traditional ineffective hiring practices.

The thing is, there are always reasons why this method isn't viable. It's not till you try it that you notice huge gains.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#87
post #54

This is the coding exercise/homework interview. A bunch of place do this in some form or another, usually without paying the person, and as part of a series of interviews on an interview day. I myself don't like homework questions, mostly because I still have to do an onsite, and I only have so much time to do these things. They are usually much longer than 2 hours too. If you communicate upfront that it should only…

I agree, maybe I'm a poor programmer, but 2 hours seems incredibly unrealistic for:

a) Creating a frontend form to submit movies b) Creating the database to store movies c) The 'search to find the movies' feature

Maybe I could do it in two hours, but it'd be pretty bad, and there's no point showcasing poor quality code.

My favourite was when they asked me to produce examples of things I had coded. Like any other creative industry, a portfolio is normal.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#88
post #10

This system is interesting but has a crucial flaw: I legally can't take part. I have a job now, which claims ownership over any tech-related IP I create. There are processes for getting exceptions, but a) you won't get them for actual job-related things b) I'm not asking Google for an exception so I can interview somewhere else. This is true for nearly anyone with a standard SV job. So if you're willing to restrict y…

>> I have a job now, which claims ownership over any tech-related IP I create.

Is there an omitted qualifier to this, e.g. ...while on company time; for IP with sufficient correlation to your primary role?

I'm having a difficult time swallowing the legal enforceability of "all-day-everyday-any-tech-related-IP" outside of military personnel subject to the UCMJ. Would that suggest that you technically couldn't contribute to an open source project?

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#89

There's an inexplicably [dead] comment in reply to your comment here. I'm reposting it so more people can see it. @throwaway4job, you appear to be hellbanned for no reason I can discern. :( > throwaway4job 8 minutes ago [dead] [-] > This isn't a viable approach for much of the hiring pool, as a majority of working engineers have contracts which explicitly forbid work for contract for other employers. As such, if you…

My guess to reasoning is that they called a startup founder a sociopath who would kill people to make a profit.

That said, that was a completely defensible and evidence-based thing to say in context (the founder threw a fit about regulators who wanted to know what the chances are that people would die), so unless HN is cracking down on the casual use of "sociopath" by people who aren't making professional medical diagnoses (which, to be fair, I do find objectionable, but not to the point of hellbanning), it seems like it was for no sensible reason.

Post reply on HN