Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Method I’ve Used to Eliminate Bad Tech Hires

mattermark.com

Post reply on HN
Print view View original

341–350 of 517 posts

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

#341

Post by zaroth »

zzzcpan wrote: post #84
zaroth wrote: 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.

I think it's different from an exam because the candidate is working on their own laptop, with their own tools, with full access to Google, StackOverflow, etc.

If for some reason they don't have a portable dev environment I guess we could provide it but that does hamper the process somewhat because it's not really "in their element" anymore.

I don't know how you really prepare for such an interview, other than actually having the portable dev environment and being well rested.

The only thing we use the whiteboard for is understanding the problem statement and sketching out the steps to creating the solution, as in, things a whiteboard is actually meant to be used for.

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

#342

Post by jon-wood »

eranation wrote: post #33

This is great, except the over the weekend part. I have a wife and kids, I rather be with them than solve (even paid) challenges. I rather take half a day off, solve it right there in the environment and team that will potential work with you. I would encourage candidates to also reach out with questions during the challenge and see how they communicate ideas and react to suggestions. Other than that, completely agre…

I'll second that. When interviewing for jobs recently the sheer volume of tasks being handed out to prove I can program was a real problem - I work five days a week, my wife works Saturdays and I look after our son. That leaves an hour here or there available in the evenings (when I'll do a bad job because its 10:30pm), or taking a chunk of time out of the only real time we get together as a family.

If you apply for say 4 jobs and they all want 2 hour work samples you've just taken on an entire extra work day to apply for jobs. I can't even just take a day off work and batch them because of the way applying for jobs works.

Honestly, I don't know the right answer. From the other side of the table I like this approach because it lets me assess how someone thinks about solving problems and writing code, but its just reinforcing a culture where only young people without any real responsibilities outside of work can get into the industry.

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

#343

Post by zaroth »

mcpherrinm wrote: post #169
zaroth wrote: post #78

Earlier quoted context omitted.

IANAL, but that's not what this is. "Work for contract for other employers" could literally mean I can't help my neighbor mow his lawn in exchange for a beer. In this case what it really means is a non-trivial amount of work done for meaningful profit. If I fix a friends computer in exchange for a nice meal, I am using my relevant skills to perform work, but I'm not actually violating a contract forbidding outside wo…

I fear deportation, being unable to ever enter - never mind work in this country again. You can call that a red flag, but it is the reality I live in. Maybe most of your candidates don't have that problem, but I would definitely be eliminated.

I mean, you could always just ask that the payment be donated to a charity instead, right?

But since almost everything we do is in some way technically illegal, it is important for everyone to be able to function under that premise.

I mean, just to cut the check technically the employer would need a W-9, a work for hire contract, and who knows what else. Let's call the lawyer and spend $5k deciding whether we can do this, and then decide 6 months later it's too risky.... Or, we do it, get better hires, execute on our plans better, meet revenue targets, and succeed in the market, by not following all the rules, just the rules that matter.

Knowing the rules to follow and the rules to forget is the hardest part, but a crucial skill in life and business. The more you push the envelope, the faster you can run, and the more likely you are to combust. See Zenefits...

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

#344

Post by erikb »

ahh wrote: 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…

Look, every time you do something that may piss of someone, like having a job and also applying to other jobs, you need to bend one law or the other. Like you are probably not allowed to take sick days for a job application appointment at another company, but you can't take all your holidays either.

There are laws that are really there to be followed correctly, like the ones about theft, murder, etc. But there are laws that basically just enable people who you piss off to get back at you. And the latter ones are a risk you must take when you want to improve your life.

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

#345

Post by jon-wood »

codeulike wrote: post #271
deepaksurti wrote: post #269

>> They refuse to do the project because “someone will hire me without it”. This is wrong in certain cases. The candidate may have significant contribution to an open source project or may have shipped an open source project as an owner. Why should that candidate not refuse? You already have the code in front of you. If you as an employer cannot take the time out to go through that and evaluate what you would otherwi…

But the method proposed is only 20% about code. It's mostly about seeing how someone approaches a piece of work and discusses a solution in a meeting. You can't get that from browsing GitHub.

You can from browsing GitHub, reading the code, and then asking how the code came to be as it is. Talk through why they went with the particular structure they chose, talk about the research which resulted in the UI, ask why they chose functional testing but not unit testing, think of a new feature that would be interesting and talk over how they'd approach adding it.

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

#346

Post by 67726e »

totalZero wrote: post #112
67726e wrote: post #67

Earlier quoted context omitted.

I can't code with people staring at me, talking to me, asking me questions. If you can more power to you, but if that reflects the nature of the job then they can take that one and shove it. It simply doesn't reflect reality.

How about when you're alone, it's 3am, you haven't slept much in the past three days, and you have a 10am deadline to meet?

A) Been there, done that, told my boss to fuck off. I've been on week long coding binges where I maybe got a cumulative 10 hours of sleep. This is a fundamentally different kind of pressure on yourself than having someone watching over your should or giving you a stare down on Skype while badgering you the whole time.

B) If you're working a job like this you're working a shitty job and ought to quit. Unless you're maybe hacking the Gibson to stop some oil tankers from going belly up there is hardly a reason in our industry for this kind of shit.

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

#347

Post by jon-wood »

Gustomaximus wrote: post #32

Payment option is really good points. With take home problems, there is risk their brilliant buddy helps them out, and teaches them about the solution to help them talk about it. For this I feel its best to do any tests onsite.

Is this really a thing, or are you just optimising for a problem that could potentially happen? Maybe I'm just being naive, but I'd like to think if someone did that I'd quite quickly realise either at interview or on hiring them that they're not actually capable of doing the job by themselves.

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

#349

Post by flurdy »

blowski wrote: post #240
stillworks wrote: post #235

Earlier quoted context omitted.

I don't care about getting paid. I don't care if I am doing it at home or in the interviewer's premises. Don't let me connect to internet. I'll also leave my phone with you just to make sure I don't have access to the internet. I don't mind taking the time away from current employment to go through the process. BUT PLEASE LEAVE ME ALONE THOUGH WHILE I AM AT IT. FOR GOD'S SAKE DON"T SIT NEXT TO ME AND TALK TO ME OR EX…

Sounds like I'm completely the opposite of you! I'm fine with someone sitting next to me - I love pair programming. But cutting off internet access means no StackOverflow, no online documentation. The test should be very similar to normal working conditions.

Agree. Pairing up during the onsite follow up interview whilst you describe and extend your sample app is essential part of my recruitment preferences.

That is how I expect people to work once they are hired so I expect candidates to be comfortable with it. Many are not, including me 10 years ago. But most are these days.

I don't expect them to solve the problem perfectly during that time, or even at all. The important bit is to test how they try to solve it, and how they communicate during it. Using Dash, google, SO, etc if fine, asking for help is fine. Essentially portray how they would work if hired.

Many times this has quickly highlighted complete blaggers, or cowboys that should be rejected, or people caught like rabbit in head lights that are not right for us now (but maybe later).

Adding a requirement that completely blows most people's initial domain model is good way to see how people respond, even if the requirement is essentially impossible.

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

#350

Post by jon-wood »

avodonosov wrote: post #118

How to invent an interesting problem which can be solved in 2 hours, which can not be found in the Internet and would allow candidate to demonstrate something? And you need to produce such problems relatively often, right?

Ideally you only produce one good one, which allows you to benchmark answers against previous ones. The other important thing is that you should do the task as well - that both ensures it is actually doable in the allotted time, and gives you an initial benchmark of what you're hoping for.
Post reply on HN