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??…
A Method I’ve Used to Eliminate Bad Tech Hires
141–150 of 517 posts
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#142First, this model alone doesn't scale. Big companies interview hundreds of candidates every week. It's not possible to design and evaluate a weekend project for each one of them. This doesn't mean that they can't have projects, but early filters are needed. That leads to the classic phone and F2F interviews to rule out those who can't code. If you freeze in one of those because of the pressure, you're out.
Second, for simple developer positions, such weekend projects might be very good. But if you are trying to hire a senior developer who is going to solve problems at big scale, then the ability to create a simple movie catalog doesn't tell you anything. And there are no big scale weekend projects. You have to ask about algorithms, data structures and other CS topics. These things are important!
Bottom line, this is a nice hiring technique suitable for small companies at a small scale. But it might not be that useful for big companies.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#143Earlier quoted context omitted.
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
#144This 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.
I've been in situations together with clients deploying a product, them presenting it for their managers, orpreparing for a big demonstration, and something goes wrong due to some unforeseen environmental factor you couldn't have imagined or predicted, and breaks in a way you don't expect, despite the weeks of testing you've done. You've got your main client staring over your shoulder, arms crossed saying fix it, and…
Being able to 'code under the pressure of a deadline' is very different from 'solving a tricky problem with someone staring right at you'
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#145Earlier quoted context omitted.
I've been in situations together with clients deploying a product, them presenting it for their managers, orpreparing for a big demonstration, and something goes wrong due to some unforeseen environmental factor you couldn't have imagined or predicted, and breaks in a way you don't expect, despite the weeks of testing you've done. You've got your main client staring over your shoulder, arms crossed saying fix it, and…
Most tech jobs aren't like that. If the job you're hiring for is one of the few that involves high-pressure coding in front of strangers, then by all means test for that.
Coding under pressure is quite different from coding on a white-board in an interview, often on an arcane CS problem.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#146There'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 dia…
When a banned account's comment gets vouched for and rescued, we look at the account history and unban it if we see that we banned it unnecessarily (we try not to do that but it happens) or if the commenter has reformed. Alternatively, there may be a good reason for the account to stay banned, but if it posts good comments, HN users will vouch for and unkill those. This system has proven to work well, even better than we hoped when we introduced it.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#147Re: A Method I’ve Used to Eliminate Bad Tech Hires
#148Re: A Method I’ve Used to Eliminate Bad Tech Hires
#149Earlier quoted context omitted.
> 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. By that interpretation, you can never legally take part in a whiteboard coding session during an interview either since the code you whiteboarded also belongs to your current employer. There is such a thing as being too literal.
The problem would be the payment. That turns it into a paid gig and leaves a paper trail. A solution might be to allow the candidate to forgo payment in lieu of the interviewer making a donation (in the interviewer's name) to a charity of the candidate's choosing, so the candidate never sees any compensation.
In this case, the hiring company just seems to want to say "This isn't an actual problem we have, but we use it as a problem set, and you should be paid for your time" because this goes above and beyond an in-person interview.
Your (existing) employer (in California) wouldn't begrudge you for taking part in a user-research survey that resulted in a $100 Amazon gift card. This could be done the same way, the difference is that you're writing code (which is what you do for a living).
Again, I am not a lawyer ;).
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#150This 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??…
Let me answer that with an example. In my previous job, I had to implement a simple username/password based authentication API in the first interview. The problem was explained to me. A two page document with a written specification of the problem was also provided to me. After I read the document, I was asked how long I would need to solve the problem. I asked for 40 minutes. Then the interviewer left me alone in the room with a laptop. After 40 minutes, the interviewer returned and went over the entire code I had written, discussed the API design decisions I had taken such as the corner cases that were handled or not handled, exceptions that were thrown, how empty or null usernames or passwords were handled, what error messages were generated, how concurrency was handled, what performance problems could occur if thousands of requests invoke the API per second per thread, how the password was secured, etc.
After I got the job, I learnt that my colleagues had also gone through a similar coding interview with different problems of similar size and scope. Some people asked for 30 minutes while some asked for 90 minutes. Therefore, I believe that it is possible to have a tiny 30 minute to 90 minute project that lets a candidate demonstrate his or her software engineering skills.
I felt this method was very effective because it evaluated a couple of key skills that were important to do the work that we were doing there: time and effort estimation, API design, writing clean and correct code, robust error handling, and design decisions from performance and security perspective.
I didn't get paid for that 40 minutes but it was part of their half a day onsite interview process, so I did not have to spend any extra time apart from the time I had already scheduled for visiting their office. Also, they did provide me free lunch, snacks and drinks, so I didn't complain. I wish more employers did this.