I, like others stated above, tend to perform much better in my own space and time than under eyes on a whiteboard..
A Method I’ve Used to Eliminate Bad Tech Hires
221–230 of 517 posts
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#222Earlier quoted context omitted.
> If hiring a freelancer to do a little thing tends to generate all sorts of nightmarish legal liabilities, your company is either a government contractor or it has even bigger structural problems than hiring. It might not be an issue for your company, but your candidate might have a non-compete (or other clause) preventing them from accepting compensation or even performing work for another company at all. Things ge…
Any company trying to enforce such a non-compete against someone who just earned $200 would spend a lot more than that in legal fees. This feels like legal paranoia to me.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#223Re: A Method I’ve Used to Eliminate Bad Tech Hires
#224Earlier quoted context omitted.
This works, but make sure they spend the 2 hours in your office and not 12 hours at home solving a 2 hour problem.. The other problem is that when you pay them you generate all sorts of nightmaris legal liabilities.
What's the legal liability ? It's not illegal to do a small project for someone and get paid for it. If the interviewee is on a H1B or some visa like that then I can see some issues.
But probably only 10-20% of people will have set that up, and for people who don't have an ABN, you have to basically fill out all the forms you would to make them an employee (you need their tax file number, have to submit a form to the tax office, have to get their superannuation details so you can pay them the mandatory 9% additional retirement savings on top of what you pay them, etc.)...
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#225Earlier 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.
You're getting hammered for this, but for some jobs you're absolutely right. If you can't handle being put on the spot for a simple interview question, how are you going to go when a production line is down and it's costing your client $100k/hr, and the foreman's standing looking over your shoulder wanting to know when it'll be working? Not all jobs give you all the time in the world on a test server without interrup…
If there's ever going to be a situation where something costs $100k/hour if it's offline then you have 5 test servers and 2 or 3 load-balanced production servers so a failure doesn't take you offline, and you've written procedures and processes to handle critical problems long before they happen.
You definitely don't try to hotfix things while the foreman complains. That will make things worse.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#226Earlier quoted context omitted.
That only makes sense if you're talking about people who are unemployed. As someone who is already employed full-time, I simply don't have the time to solve your problems for free just to see if you'd like to invite me over for an interview. I avoid these problems like the plague and very much prefer to whiteboard. If you pay me consultant rates, I can more easily justify the effort.
>> much prefer to whiteboard Who would have thought? Maybe - just maybe - not everyone has the same strengths and weaknesses. The real answer here is obvious: present the interviewee with options. Forcing all potential hires to whiteboard is a terrible idea. Forcing all potential hires to do a take-home project is a terrible idea. It's extremely short-sighted and a little pompous to assume that any single interview f…
Whiteboarding is a poor reflection of what people do day-to-day, and can be misleading if a candidate practices interview technique over coding experience. In other words, just because someone can regurgitate an algorithm on command, doesn't mean they'll be a good developer.
If all you want to optimise for is finding people who make a good first impression, by all means carry on with whiteboarding. However, if you want to find good developers then there is a one-size-fits-all solution, and that's to see how they develop code in the real world, which is exactly what the 'weekend project + appraisal' approach is a great fit for.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#227Earlier quoted context omitted.
This works, but make sure they spend the 2 hours in your office and not 12 hours at home solving a 2 hour problem.. The other problem is that when you pay them you generate all sorts of nightmaris legal liabilities.
Absolutely agree with the sentiment here. I have used this technique for a couple of years now, except that I kept the task to 20 minutes (and didn't pay people, since it's a short amount of time). To save dragging people into an office for that time period, I set up a custom git server that marks the timestamps of their pulls and pushes. The instructions for the task are contained in the README of the repo, so as so…
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#228Re: A Method I’ve Used to Eliminate Bad Tech Hires
#229Re: A Method I’ve Used to Eliminate Bad Tech Hires
#230Earlier quoted context omitted.
This works, but make sure they spend the 2 hours in your office and not 12 hours at home solving a 2 hour problem.. The other problem is that when you pay them you generate all sorts of nightmaris legal liabilities.
> This works, but make sure they spend the 2 hours in your office and not 12 hours at home solving a 2 hour problem.. This goes against the core message of the article. The candidate is supposed to think about a problem on their own, and propose a well-reflected solution on Monday. That's pretty much the opposite of "sit down in this noisy corner in an unknown environment and give us something in two hours". > The ot…