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

171–180 of 517 posts

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

#171

Post by nchuhoai »

I really like this, and have been trying to implement this at my company. One thing we are struggling with is to find the right challenge/project, in my case for the frontend. Two issues:

1. What is a reasonably sized project? I.e. often times two hours is not enough to produce something of substance/complexity, yet asking the applicant to do more becomes prohibitive. 2. I see a bunch of people asking candidates to do greenfield applications, while virtually all work most future workers will do is refactor and maintain. The latter however requires additional time investment to get to know an existing system/codebase.

How are you guys handling those issues, and trade-off time complexity against insight value?

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

#172

Post by blazespin »

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

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

#173

Post by ethbro »

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?

That is a thing that happens, yes.

If that happens consistently for months at a time, then as said the PM is severely fucking up. And if that wasn't communicated as an expectation before compensation was negotiated, then the company is probably fucking up.

As the quip goes "If a race doesn't have an end, then it's a death march."

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

#174

Post by BigJono »

tdeck wrote: post #110

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

I feel like it's in the best interest of the employer to leave the choice of tools fairly open and see what the potential employee elects to use. For the example given in the article (a basic web application), I'd be very interested in whether the interviewee decides to go with a heavy stack, does it completely in vanilla JS, or something in-between.

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

#175

Post by peteretep »

photogrammetry wrote: post #168
peteretep wrote: post #130

Earlier quoted context omitted.

> Are you really advocating that people disclose their > salary to a recruiter Yes > What terrible advice No > "How to immediately throw away your best bargaining > chip 101" If they're an internal recruiter, they have a banding you can be paid in, and they don't really care where you fall in it. Decisions above that salary banding will need to be referred to the person whose budget you are. If they're an external re…

Do you mind not using multiline code block quotes that split sentences in half? Not only is it obnoxious to read on mobile, as horizontal scrolling is necessary, but it also fundamentally doesn't make sense as you should be able to copy/paste whole sentences. One might expect that as a recruiter/(ex-?)developer you'd realize how painful it is when you use this formatting.

Looks much better to me, including on mobile, and is the first complaint in the 2,020 days my account has been active here, whatever "one might expect". Additionally, it will look entirely natural to any of us who used email before it was mostly HTML.

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

#176

Post by majormajor »

MAGZine wrote: post #103
peteretep wrote: post #71

Earlier quoted context omitted.

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

What changes if you drop just a handful of words so it starts "I am interested in roles paying above $xxx,xxx only"?

That might be my salary. It might be my floor for moving to a new, more expensive, area. It might be what I think my current salary should be.

Depending on how things like bonuses are done, base salary alone isn't super relevant anyway. There's a potentially very big difference between a company that says "we give bonuses of up to 20k per year" and "our bonus target for good performers at this level is 25%."

Maybe 9 times out of 10 the recruiter says "sorry, that's not going to happen." But you only want to find the ones who say "we can work with that" anyway.

This may not be the best way to absolutely maximize your total, but if you pick the right floor, you can save a lot of time up front. And the way to really maximize your offer isn't to hide your current salary, anyway. It's to take that first offer to another other company you're interviewing with, and see if they can beat it. That's your best bargaining chip.

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

#177

Post by peteretep »

quickben wrote: post #164
peteretep wrote: post #130

Earlier quoted context omitted.

> Are you really advocating that people disclose their > salary to a recruiter Yes > What terrible advice No > "How to immediately throw away your best bargaining > chip 101" If they're an internal recruiter, they have a banding you can be paid in, and they don't really care where you fall in it. Decisions above that salary banding will need to be referred to the person whose budget you are. If they're an external re…

And if they are an actual external company and not external recruiter?

I'm not entirely sure what you mean, but are you sure you don't mean an internal recruiter?

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

#178

Post by ethbro »

closeparen wrote: post #119
taneq wrote: post #111

Earlier quoted context omitted.

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…

In my experience, high-pressure "fix it now" scenarios are about leaning on what you know about the system, interpreting metrics and log messages, understanding how it's going wrong, and deploying a (usually very simple) fix. Sometimes just blindly hitting the "rollback" button as a first step fixes it, too. Performing well in this kind of scenario is much less about algorithms and data structures, and much more abou…

Both of you have points, but I absolutely agree with this. Outside of "Healthcare.gov goes live tomorrow and turns out it's completely broken" scenarios I've never seen something that would require a ground-up design and build of a system under emergency production time constraints.

System knowledge and knowing which one bolt to replace or turn is almost always more effective.

PS: Not to mention, if we're getting into algorithmic complexity levels of engineering on a monkey patch to a production system, then so many alarm bells are already ringing.

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

#179

Post by peteretep »

greglindahl wrote: post #165
peteretep wrote: post #130

Earlier quoted context omitted.

> Are you really advocating that people disclose their > salary to a recruiter Yes > What terrible advice No > "How to immediately throw away your best bargaining > chip 101" If they're an internal recruiter, they have a banding you can be paid in, and they don't really care where you fall in it. Decisions above that salary banding will need to be referred to the person whose budget you are. If they're an external re…

External recruiters get paid more for getting more candidates hired with the least effort per candidate -- they are not interested in spending a lot of time getting 10% more salary for a candidate, instead of getting another hire done.

Most external recruiters don't make much more than a couple of placements a month, so they are absolutely incentivized to amp their commission up as much as possible without losing the sale. Was this not the case when you were working as a recruiter?

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

#180

Post by ghaff »

majormajor wrote: post #166
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.

I don't understand the paid part at all. If I'm working full time, $200 isn't going to swing me one way or the other on deciding if I want to do your homework assignment. And if you come up with a ten-hour problem, then we're talking more of a chunk of cash, but you're also asking me to burn a lot of free time. I'd much rather travel and meet you in person and do stuff there, but if you don't have the budget for it,…

>I don't understand the paid part at all.

There's a concept around a lot of preliminary engagements between two entities called "skin in the game." The idea is that when something is completely free the other party will take advantage of it without any real serious intent to follow through on anything.

Mostly this seems a reaction to the homework-type assignments where candidates are expected to spend a lot of time on some interview assignment with very little real cost to the company--which raises the possibility that it's effectively a cattle call.

Post reply on HN