A Method I’ve Used to Eliminate Bad Tech Hires • Hacker News Board

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

#441

Post by st3v3r » Thu, Nov 10, 2016, 6:15 PM UTC

marcosdumay wrote: post #320

vhab wrote: post #213

Earlier 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…

Then the candidate says something like "Well, you know, I can't take any payment before I'm out of this job. Can't I just do it for "free", and payment come as a bonus on hiring?"

I wouldn't do that. But then, I don't work for free.

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

#442

Post by linkregister » Thu, Nov 10, 2016, 6:17 PM UTC

paxy wrote: 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??…

Since this would be a 1099 contractor relationship and not an employee relationship, would there be any issue for Mattermark in this case? All they need is a TIN for their 1099 filing; it's up to the visa holder to know whether they are permitted to do contracting work.

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

#443

Post by st3v3r » Thu, Nov 10, 2016, 6:17 PM UTC

throwaway4job wrote: post #59

zachd1_618 wrote: post #49

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.

Non-competes are worthless clauses that should never have existed in the first place. I am perfectly ok with someone ignoring that blatantly anti-employee clause.

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

#444

Post by st3v3r » Thu, Nov 10, 2016, 6:18 PM UTC

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.

You are an edge case. There should be a workaround for you, but just because something doesn't work for you doesn't mean it doesn't work in general.

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

#445

Post by st3v3r » Thu, Nov 10, 2016, 6:23 PM UTC

kriro wrote: post #354

rizzom5000 wrote: post #98

Earlier 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.

I hear this argument quite often but my reaction tends to be... ...as someone that's fully employed I'm probably only looking at jobs I'm really interested in. I don't mind doing some free work for stuff I'm interested in. I also enjoy doing small unpaid side projects or programming puzzles in my free time...basically the same concept. That being said, my guess is (ignoring legal implications) paying 200$ or whatever…

Even if I'm interested in it, I'm not interested in doing free work for a for-profit company.

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

#446

Post by MorePowerToYou » Thu, Nov 10, 2016, 6:24 PM UTC

This method is great. It's worked for me when seeking new jobs.

Regarding the "algorithms trivia via whiteboard" style interviews: I think this type of interview is, unfortunately, the best large companies can do given their constraints. These constraints include hiring lots of new graduates, interviewing pipelines that include technically illiterate recruiters and engineers who lack the executive function to accurately assess candidates' viability. Lastly, the people involved in hiring at large companies are clueless about what the new hire will actually work on. It seems so obvious that tailoring the interviewing process to the actual fucking work that the person will be doing is a good approach. Once again, the contraints in a large company prevent this from happening in general.

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

#447

Post by duderific » Thu, Nov 10, 2016, 6:25 PM UTC

mi100hael wrote: post #391

For example, I may say please use functional reactive principals in JS to solve this problem, but the decision of using Kefir, Bacon, or RX is left up to them. These days I'm utterly unable to tell whether someone talking about JS is being serious or if it's parody.

No, this is real...however, using reactive principals in JS is a bit esoteric and definitely not something that needs to be covered in an interview (IMHO). At my company when it comes to JS interviews we are more interested in proper separation of concerns, understanding scope, using proper data structures...you know, the basics.

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

#448

Post by ebrenes » Thu, Nov 10, 2016, 6:29 PM UTC

geebee wrote: post #436

I'm coming late to this. I've been through two take-home projects. Both of them resulted in a no-hire, and each has refined what I'm willing to do and what I'm not willing to do. The first one was a pretty egregious experience, honestly. I never spoke with anyone other than a recruiter. The first was a 2 hour Java test. The next was a take-home that I was supposed to spend 5-7 hours on. I did it and sent it in. I kne…

I'd probably follow up on talking with your buddy. It's often invaluable to get an outsider's feedback on how others look at our code.

From what you typed, it seems like there wasn't a lot of communication prior to doing the coding exercise. I'm also not aware if you had channels to ask questions or discuss technical design options. If available, those are often "part of the test", to see if you make use of such resources.

When I'm reviewing code in such scenarios I'm often looking for other indicators aside from the code's correctness. Things like: naming conventions, structure of the code, patterns used, how over-engineered it is. Just as important is seeing if the candidate picked up on less explicit instructions or hints in the coding exercise. Finally, I look for code that follows the conventional patterns and standards for that programming language; I expect a candidate to discuss with me the deviation from those standards prior to handing in the code.

Anyways, I wouldn't completely give up. This might be an opportunity to grow and learn, but you'll never know unless you follow through on asking your buddy. Likewise, I've seen people here on HN volunteer to review code and provide feedback.

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

#449

Post by st3v3r » Thu, Nov 10, 2016, 6:29 PM UTC

TeMPOraL wrote: post #255

rizzom5000 wrote: post #98

Earlier 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.

> 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. That means you don't care enough about changing jobs. There are people who will happily do that "interview" for free even when being employed full-time. The only relevant question for the company is whether there are enough qualified candidates will…

That couldn't be more wrong if you tried. Not to mention, you're assuming that people need the job. It's the other way around. The company needs the engineers. Much more than the engineers need the jobs.

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

#450

Post by MorePowerToYou » Thu, Nov 10, 2016, 6:30 PM UTC

shandor wrote: post #233

This seems like a pretty popular take on the interview process here on HN. However, there's one pretty glaring flaw that I've never seen discussed: if the interviewee can take the problem home, what prevents them setting up a hackathon with their friends at their place, and making the interview problem a team effort? A couple of knowledgeable friends can do wonders, and if you also prep with them a little you can pro…

ELI5: you discuss the solution with the person, too. If they can't accurately describe it, they fail. They either have poor communication skills, don't understand what they wrote, or didn't write what they submitted. Those are all easy fails.