Live data from Hacker News

The Hiring Post

sockpuppet.org

251–260 of 266 posts

Re: The Hiring Post

#251
post #250

Earlier quoted context omitted.

I can relate to this comment and the others that replied to my original. I guess my overall view is that far too much time is wasted and it is mostly preventable. As a senior developer I have a detailed LinkedIn profile, a few recommendations, some side businesses and startups I have been involved in, a portfolio website showing off websites and apps I've built, a tech focused blog, a GitHub and a Stack Overflow. Rig…

Yeah. My favorite method, really, on both ends of the fence? Just hire the person and start them working, for pay, with the understanding that this is still an evaluation type deal. If it doesn't work out? if I'm the one being evaluated, at least I got paid for the time. If I'm doing the evaluating, seeing some one actually work is a way better indicator of, well, how well they work than anything else. The problem wi…

This can work well if the person currently functions as a freelance consultant or is unemployed but has worked as a consultant in the past. Also, ideally you have a specific small project for them to work on. Finally, you have to be able to pay them the market rate. If all of that fits (rare) then it's a great choice.

Re: The Hiring Post

#252
post #191

Earlier quoted context omitted.

Let me first start by saying that I, too, dislike the prevailing interview process for software development jobs. While I agreed with many of your points, I could not stop thinking what a huge time burden of implementing something like what you propose, at scale. For a growing company with several work streams and projects hungry for talent, the interview approach you posit would never work. Another thing that came t…

Actually, go look for the 'tokenadult comments on work-sample tests to learn that this approach has been known for something like half a century to outperform interviews.

Here: https://news.ycombinator.com/item?id=4613543

Re: The Hiring Post

#253
post #250

Earlier quoted context omitted.

Yeah. My favorite method, really, on both ends of the fence? Just hire the person and start them working, for pay, with the understanding that this is still an evaluation type deal. If it doesn't work out? if I'm the one being evaluated, at least I got paid for the time. If I'm doing the evaluating, seeing some one actually work is a way better indicator of, well, how well they work than anything else. The problem wi…

This can work well if the person currently functions as a freelance consultant or is unemployed but has worked as a consultant in the past. Also, ideally you have a specific small project for them to work on. Finally, you have to be able to pay them the market rate. If all of that fits (rare) then it's a great choice.

> This can work well if the person currently functions as a freelance consultant or is unemployed but has worked as a consultant in the past.

Sure, that's a lot like what I was getting at with the whole valuing stability thing. It can also work if the person being hired is having a hard time finding a job.

>Also, ideally you have a specific small project for them to work on.

Actually giving them a project, you know, meeting the legal definition for "contractors" is super rare, at least on the middle where I work. I do see it happen, but it's usually those "10x" programmers who get those jobs. Or it's jobs working for poor companies that pay very little.

In the middle, you find people like me, usually working through corporations (or in my case, whole chains of corporations) that end up paying the contractor on a W2... the idea being that the irs is less likely to reclassify the kid if someone is paying payroll taxes somewhere - because the work does not make the legal definition of contractor.

As an aside, I think most of this shell game isn't about legal liability; it's about making it clear to the other employees who is a temp and who isn't. From a legal perspective, compared to what you pay a body shop, firing someone just isn't that expensive. My belief is that the major cost in firing someone that is performing okay is in morale of your remaining employees. firing your contractors first allows you to have the flexibility to fire someone without making your full time folk feel like they might be next.

>Finally, you have to be able to pay them the market rate. If all of that fits (rare) then it's a great choice.

See, it's not rare, and it happens at all pay grades. Different pay grades have different rituals and ways of arranging things, though. Right now I'm working as a "contractor" - I'm going through some shady body shop, but I actually sit at a desk in the office and eat the free food with the employees. They pay okay, and the expectation they set was that I'll be a contractor for a year, I mean, assuming things work out, and then if we like oneanother, they'll hire me full time at the end of the year.

That kind of arrangement is really common in this industry when the economy is good. They need people now, and I can be a person now, and if they like me, well, that's an easy hire. If they don't like me, or if market conditions change before the year is out, they can let me go without damaging employee morale as much as firing a full-timer. (similar arrangements, with less emphasis on you becoming a full-timer at the end are common when the economy is bad.)

I like it 'cause I'm going through a company that I mostly own, and it gets a bunch of money corp to corp which I can use to pay my people to see if my business can get off the ground, (it pays me, too, on a W2, and buys me mediocre health insurance) and if at the end of the year, it does take off, well, I quit, and hey I was a contractor, right? that was the deal. and if my business doesn't take off, I've got a foot in the door at a decent big company where I might want to actually work for a few years, you know, put something on my resume besides abject failure.

But, as far as I can tell, this arrangement is super common. Actually going through a corporation you own part of is less common, but not unheard of.

Re: The Hiring Post

#254
post #190
post #43

We went through the phase when we gave candidates a problem and let them work on it remotely. It was in an embedded C shop that did a lot of kernel work. Basically, we'd give a short programming task (say, to write an intrusive AVL tree container in C) and 24 hours. Guess what? HALF of candidates cheated. Meaning that when the got called for an in-person interview, they stumbled to explain how "their" code worked. To…

Embedded C and AVL trees? Really? Could you explain how an AVL tree would be used in an embedded context?

It's a C test.

Re: The Hiring Post

#255

Earlier quoted context omitted.

I honestly believe that the recruiting/hiring market is ripe to be flipped on it's head for these reasons. I just can't think of any way to do it that can scale though. There are the hired.com models where independent experts thoroughly vet the candidate, but that involves a lot of manual interaction.

My big problem with Hired.com and similar sites is that there's no incentive for anyone to be honest. I have no incentive to say "not interested" to anyone, and they have no incentive to back up the salary they post. It's the equivalent of the "always swipe right" strategy on Tinder -- it's in your best interest to say "maybe" or "interested" to everything, because otherwise you don't know if you're missing out on op…

Resale is incentive to be honest - i.e. you place a good candidate, they hiring company will come back to you.

Hired.com will turn away people they don't think of as good candidates, but usually after people manually review their profile.

Re: The Hiring Post

#256

Earlier quoted context omitted.

My big problem with Hired.com and similar sites is that there's no incentive for anyone to be honest. I have no incentive to say "not interested" to anyone, and they have no incentive to back up the salary they post. It's the equivalent of the "always swipe right" strategy on Tinder -- it's in your best interest to say "maybe" or "interested" to everything, because otherwise you don't know if you're missing out on op…

Resale is incentive to be honest - i.e. you place a good candidate, they hiring company will come back to you. Hired.com will turn away people they don't think of as good candidates, but usually after people manually review their profile.

Yeah, but I think the resale factor is exaggerated. If they send you a "good" candidate, you might go back to them, but they're just finding the first "good" candidate they can rather than finding the "best".

I wonder if The Secretary Problem could be used to calculate data points for whether a candidate is good or not. http://en.wikipedia.org/wiki/Secretary_problem

Re: The Hiring Post

#257

Thank you, tptacek, for writing this post. You have identified several important problems with interviewing and laid out the fundamentals for a reasonable alternative to the standard software interview. It makes me sad that I will probably never see a single one of your suggestions implemented by any potential employer that might want to hire me, specifically. This is because there is one more major problem that you…

[edit] This seemed inappropriate so I changed it The only reason I ever designed a hiring pipeline is because I was asked to be one of the people in the interview pool. Me (and others in the pool) decided we were doing a bad job and started iterating on the problem (much like we would for software). Management was thrilled with both the initiative and the results. That was years ago and working on hiring pipelines ha…

I have never been hired by any employer that uses a hiring process that would reject me as an applicant. There's a bias embedded in there, I think--one that may also occur in other people.

I also encounter the problems endemic in the hiring process far more often at other companies than I do in my own. The reason why I start interviewing elsewhere is often because my current company has stopped hiring (or started firing). I have occasionally tried giving those other companies feedback, but the response has always been, without a single exception, "We know what we're doing; don't tell me how to do my job."

I have neither lever nor fulcrum for this problem. My frustration is not without reasonable cause.

Re: The Hiring Post

#258
post #73

There are a lot of 'hiring is broken' posts and this is a decent one, but I don't think I'm alone in feeling that none of them convincingly identify the problem, let alone solve it.[1] So I'll do that here. Hiring isn't broken because people use the wrong interview questions. It's broken because firms are engaging in a zero-sum battle for talent. But if what you're doing is worth a damn, it should be worth a damn whe…

>Where are the apps that are even half as feature-rich as a typical Windows application from the '90s?

I hear you. One reason for this is scalability. You can build richer web apps if you aren't shooting for scale.

I worked on two startups with conventional LAMP stacks and heavy user sessions before joining Yahoo. At Yahoo there was really no session object[1], due to scalability. A few cookies could be set to customize behavior, but adding new cookies was seriously frowned upon. This made me appreciate sessions as a means to adding in nice little features.

In principle you can solve that by storing the session in a scalable key-value store, providing the latency is low enough.

[1]Generalization only valid for the properties I was exposed to at Yahoo.

Re: The Hiring Post

#259

Earlier quoted context omitted.

[edit] This seemed inappropriate so I changed it The only reason I ever designed a hiring pipeline is because I was asked to be one of the people in the interview pool. Me (and others in the pool) decided we were doing a bad job and started iterating on the problem (much like we would for software). Management was thrilled with both the initiative and the results. That was years ago and working on hiring pipelines ha…

I have never been hired by any employer that uses a hiring process that would reject me as an applicant. There's a bias embedded in there, I think--one that may also occur in other people. I also encounter the problems endemic in the hiring process far more often at other companies than I do in my own. The reason why I start interviewing elsewhere is often because my current company has stopped hiring (or started fir…

> It makes me sad that I will probably never see a single one of your suggestions implemented by any potential employer that might want to hire me

I was implying that you could see this at your current/next employer by implementing it there. If you fix it there before the time comes to move on you personally may not reap the benefit but someone else might and the lessons learned by you and your colleagues get spread further out. If nothing else, you learn how to maneuver hiring pipelines quite well by designing them.

> The people creating the interview protocols do not solve their problems like software professionals.

As soon as you are asked to become part of the hiring pipeline whether it be resume sorting, phone screening or interviewing, you become one of the people creating the interview protocols. You can apply whatever tools in your arsenal to fixing it. I have found using standard software development methodologies to be very compelling and useful in this context.

> The reason why I start interviewing elsewhere is often because my current company has stopped hiring (or started firing).

This is a problem that is more worrisome than involving yourself or not in designing hiring pipelines. It implies a reactive approach to your career, and that is likely to lead to suboptimal results, and can be actively detrimental to your job prospects in bad job markets. I would look to the root cause of that behavior and see if it lends any insights.

Re: The Hiring Post

#260

I found it a funny coincidence that the current top two links (this and a comment on the Holman post[1]) take opposing viewpoints on programmers as soldiers: "Infantry are what most people are." and some are "Commandos" vs Tom's "Engineering teams are not infantry squads. They aren’t selected for their ability to perform under unnatural stress." [1]: https://news.ycombinator.com/reply?id=9159398

This is great! As a former commando turned programmer I've long been wondering how best to express the commando mindset in programmers terms. The 4 elements of the command spirit are

Courage

Determination

Unselfishness

Cheerfulness in the face of adversity

These sure come in handy in some programming environemnts :-)

Post reply on HN