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

101–110 of 517 posts

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

#101

Post by nolite »

zaroth wrote: post #78
throwaway4job wrote: post #59

Earlier quoted context omitted.

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.

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…

You perfectly verbalized what was bothering me about this reply

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

#102

Post by dclowd9901 »

peteretep wrote: post #71
redwards510 wrote: post #14

Earlier quoted context omitted.

I don't mind homework, but companies need to start specifying their salary range up front. I've been having a lot of time wasted lately by getting through Tech Interview #1 or Homework #1, only to find out their max salary is laughable for San Francisco. "You should just find that out upfront" I hear you saying. Well that is not always possible. Recruiters either don't know the range, or lie about not knowing, or you…

Recruiter here with a history of working as a developer > but companies need to start specifying their salary > range up front The costs outweigh the benefits for employers (encouraging existing employees to ask for more money, losing candidates who will accept significantly less but wouldn't apply at a lower range, etc) -- so don't hold your breath. > I've been having a lot of time wasted lately by > getting through…

"The costs outweigh the benefits for employers"

That's funny, I thought this was a employee's market... Better get with the program, bub.

I'm actually in favor of 100% transparent salaries. I've yet to hear a compelling argument against it that wasn't simply "it feels icky."

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

#103

Post by MAGZine »

peteretep wrote: post #71
redwards510 wrote: post #14

Earlier quoted context omitted.

I don't mind homework, but companies need to start specifying their salary range up front. I've been having a lot of time wasted lately by getting through Tech Interview #1 or Homework #1, only to find out their max salary is laughable for San Francisco. "You should just find that out upfront" I hear you saying. Well that is not always possible. Recruiters either don't know the range, or lie about not knowing, or you…

Recruiter here with a history of working as a developer > but companies need to start specifying their salary > range up front The costs outweigh the benefits for employers (encouraging existing employees to ask for more money, losing candidates who will accept significantly less but wouldn't apply at a lower range, etc) -- so don't hold your breath. > I've been having a lot of time wasted lately by > getting through…

> "I am interested in roles paying above my current salary of $xxx,xxx only, and am looking for an improvement on that to reflect my increased experience and the risk of moving roles"

Are you really advocating that people disclose their salary to a recruiter, voluntarily?

What terrible advice. "How to immediately throw away your best bargaining chip 101".

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

#104

Post by nolite »

pauljaworski wrote: post #21

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.

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 every two minutes asking "is it fixed yet?"

You damn well better be able to code under pressure... And like a freaking ninja

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

#106

Post by mjevans »

bigiain wrote: post #75
chubot wrote: post #39

Earlier quoted context omitted.

Do you think Google would sue you over 2 hours of coding? Technically, they might be able to, but anyone can sue you for anything. If you think they would, you're probably overvaluing what you can accomplish in 2 hours, and you're underestimating the cost of a lawsuit to them. I can't imagine a situation in which they would actually pay any of their legal staff to even look at something like this, given all the rest…

I dunno about Google, but I've got a friend who's legal advice was "Stop working on your phd immediately" when his lawyer read the new employment contract we was being asked to sign when his company got acquired by Oracle. It took months for him to get an extremely limited exemption to the standard contract to be allowed to publish his thesis according to his phd requirements...

That's just one more reason to not work at someplace as notoriously 'litigious' as Oracle.

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

#107

Post by inopinatus »

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.

IANAL but I took business law 101, which taught me that courts almost universally lean strongly towards the employee when considering restraint clauses.

Moreover, if you have a current employer that is sufficiently disrespectful of their employees that they'd even consider enforcing an anti-moonlighting clause in this circumstance, with the preposterous assertion that it qualifies as employment - run away now.

The law is not a programming language.

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

#108

Post by mjevans »

philipkglass wrote: post #58
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??…

I read the money/difficulty calibration as "pick a problem that you think would take someone about 2 hours to implement and offer $200 for completion." Not "offer $100 per hour and then cough up $1600 when the following Monday the candidate swears that they spent two full days on it."

A key point of the specification for the solution is that the produced work //is not// a product. You are using the exercise as a test.

Maybe it would be better to explicitly state that the results of the work are to be released under CC-BY?

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

#109

Post by snoman »

GrinningFool wrote: post #100
usloth_wandows wrote: post #66

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

Upvoting you to help prevent your comment from reaching oblivion - I don't agree with you, but I think what you said is a common belief. The thing is, it's a vastly different kind of pressure. When I am coding as part of a job - by myself or with others - there is no inner monologue in the corner of my brain doing something like this: "Could do that or... no damn, that's O(n^2), damn I'm taking too long that one look…

Have you done pair programming before? Especially as you become more senior, the pressure to not look like an idiot in front of junior devs adds up fast. You have to learn, quickly, how to get over that kind of inner monologue, and just get to work.

That kind of scenario happens to me daily.

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

#110

Post by tdeck »

Love the idea of paying people. That's great. However, consider the perspective of someone who already has a job in the industry. If every company did this, I wouldn't be able to interview at more than one per week. Not only that, but the Friday and Monday onsites mean I miss work on TWO separate days. This would be a non-starter for me if I had any decent pool of interest from other companies, although it's great for people trying to break into the industry.

Another problem, depending on your philosophy. Specifying the exact technologies someone has to use means that you've closed yourself off to generalists, unless they have time to learn a whole new stack that weekend. Not that it's rocket science to do so, but that turns a two hour project for me in say Angular into an eight hour project in your favored stack. I can always learn your stack on the job, as any good engineer can.

Post reply on HN