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

Destroy all hiring processes

b-list.org

Post reply on HN
Print view View original

51–60 of 104 posts

Re: Destroy all hiring processes

#51

Post by morgante »

dustywusty wrote: post #9

As both an interviewer and interviewee at Weebly, I'm pretty confident in saying I prefer our approach of the trial week. It really gives a great opportunity for the candidate to show off their skills without the on-the-spot pressure of a coding interview. A great side-effect is the candidate gets to determine if they like the team, and vice versa. I honestly wouldn't work somewhere else where I couldn't come in for…

Instead of repetitively saying that you went through this same gauntlet yourself, how about an argument for how you think this is possibly a valid strategy for attracting good already-employed developers?

As I see it, there are 2 huge barriers to me ever doing a trial week while currently employed:

1. If it doesn't work out, I've just burned 1/4 of my vacation time for the year. That's a pretty massive ask for a company to make. I could do a bunch of math with expected values, but I'm sure it would work out to Weebly having to have insanely great compensation (>$300k) for me to do it.

2. Even if it does work out with Weebly, it makes it impossible for me to concurrently solicit and evaluate multiple offers, which I absolutely do when looking for a new position.

How do you overcome those problems which make it very unlikely that 99% of employed developers will do your process?

Of course, it could also be that this is a brilliantly designed strategy for weeding out expensive employees by focusing on the unemployed and unsavvy.

Re: Destroy all hiring processes

#52

Post by gqvijay »

teen wrote: post #11

this article is awful. it cites a single bad coding interview as a problem with all coding interviews. as someone who gives tons of code interviews, they are absolutely invaluable, and are a strong indicator in weeding out people who can't write code. you can't blame bad interviewers for the entire process not working.

Slippery slope fallacy...You are incredibly oversimplifying what he is saying. Sure, he is generalizing but he isn't citing a single coding interview to judge the entire process.

Having said that, I actually agree with him because I've learned that it's not always simple as who can't write code. I would much rather assess a candidates' ability to learn (sharpness) than the current skill-set.

Re: Destroy all hiring processes

#53

Post by xacaxulu »

nickpsecurity wrote: post #44
dustywusty wrote: post #25

Earlier quoted context omitted.

I took a week off at my previous job to trial at Weebly. My previous job had a very strict vacation policy, but I knew the importance of what I was doing. Weebly has an unlimited vacation policy, so, it worked out pretty well.

You've mentioned this twice. Yet, it means nothing for vast majority of people in the workplace. The majority have to be at work programming instead of interviewing for programming positions. They neither have unlimited vacation time nor a 100% guarantee using a vacation for some interviews will go anywhere. If anything, the OP's post shows quite the opposite for them in common case. So, how does a trial week work fo…

EVERY job switch has inherent risks. It's unreasonable to expect otherwise. No one can help that and OPs situation wasn't crazy. He/She took a risk and it paid off. The downside is just a lost week of PTO? Not too crazy and anyone with a full-time job and some PTO could do this. I'd even get 'really sick' if I had too.

Re: Destroy all hiring processes

#54

Post by morgante »

ubernostrum wrote: post #36
gfodor wrote: post #22

"People who have a master’s degree in CS but seemingly can’t code their way out of a paper bag probably actually aren’t bad; more likely they had an education which de-emphasized practical hands-on programming in favor of heavy theory. People who post “please give me the code” questions on mailing lists and forums probably actually aren’t bad; more likely they had an education which was based around memorizing and re…

For much the same reason that someone who has no CS background can productively do a short coding bootcamp and be employable, someone who has a theory-heavy and practice-light CS background can almost certainly pick up practical skills quickly. It's more of an educated vs. educable thing, and anyone who's demonstrated that they're educable is probably worth at least looking into a bit more even if they don't come wit…

> For much the same reason that someone who has no CS background can productively do a short coding bootcamp and be employable, someone who has a theory-heavy and practice-light CS background can almost certainly pick up practical skills quickly.

I don't think they're equivalent at all.

The truck driver simply never had the opportunity or exposure to programming. He didn't know what it was like and hence couldn't do it.

The theory student did have exposure but was either incapable or uninterested in pursuing it. Even in the most theory-heavy of programs, you program a little. The kids who actually understand and like the programming aspect latch onto it and continue to learn and grow, ending up employable. The kids who, having been exposed to programming and realized that it's not for them, never learn any more and continue to flail around in masters programs teaching mathematics in the guise of CS.

Re: Destroy all hiring processes

#55

Post by 1stranger »

thaumasiotes wrote: post #49
dx211 wrote: post #23

A couple of years back, I was hiring some vendor developers for my team, and since I had some flexibility in the interviews that wouldn't be allowed for full-time employees, I tried an experiment: For one of the vendor candidates, I told him a day ahead of time that I'd be asking him to implement System.Collections.Hashtable in C#, with behavior equivalent to the one in .Net. The day of the interview came, and he whi…

I recently interviewed with a company that had advertised (in my paraphrase) "we've noticed that a lot of perfectly good developers do poorly in interviews for reasons that appear to be unrelated to job performance. So you can now interview with us by completing a project on your own time, and during the interview we'll talk about that". My project was a regex matcher. I ended up getting the following feedback: > We…

Wow, that really sucks. So they basically took the old process and just added more to it.

Re: Destroy all hiring processes

#56

Post by fishtoaster »

flippyhead wrote: post #20

It's funny, I've tried tons of different approaches to solving this problem and the only thing I now do is spend about 30 minutes with someone then decide to hire or not (usually I'm able to express this on the spot to whomever I'm interviewing). For better or worse, my instincts about who is smart, honest and kind seem at least as good (and often better) than any other approach we've tried.

I'm curious how you validate that approach. I'm not saying you're wrong– just that I don't know if you'd be able to tell if you're wrong.

Do you measure the performance of people hired through that method, and have you done so for a long period with a significant sample size? Do you manage to measure your false-negative rate (by somehow following up on candidates you passed on)?

Re: Destroy all hiring processes

#58

Post by flippyhead »

fishtoaster wrote: post #56
flippyhead wrote: post #20

It's funny, I've tried tons of different approaches to solving this problem and the only thing I now do is spend about 30 minutes with someone then decide to hire or not (usually I'm able to express this on the spot to whomever I'm interviewing). For better or worse, my instincts about who is smart, honest and kind seem at least as good (and often better) than any other approach we've tried.

I'm curious how you validate that approach. I'm not saying you're wrong– just that I don't know if you'd be able to tell if you're wrong. Do you measure the performance of people hired through that method, and have you done so for a long period with a significant sample size? Do you manage to measure your false-negative rate (by somehow following up on candidates you passed on)?

Well, the false-negative rate is something we never did even when we tried all kinds of other "standard" interview approaches. If you had a solution for that it'd be useful generally I expect. I'm only make anecdotal comparisons to the quality of persons hired by all other approaches vs. me just using the massive pattern matcher in my head. And to be sure, my company is small and it's my company so the ultimate determinant of hiring quality is really just me. I'm not sure this approach would work for medium+ organizations.

Re: Destroy all hiring processes

#59

Post by nickpsecurity »

xacaxulu wrote: post #53
nickpsecurity wrote: post #44

Earlier quoted context omitted.

You've mentioned this twice. Yet, it means nothing for vast majority of people in the workplace. The majority have to be at work programming instead of interviewing for programming positions. They neither have unlimited vacation time nor a 100% guarantee using a vacation for some interviews will go anywhere. If anything, the OP's post shows quite the opposite for them in common case. So, how does a trial week work fo…

EVERY job switch has inherent risks. It's unreasonable to expect otherwise. No one can help that and OPs situation wasn't crazy. He/She took a risk and it paid off. The downside is just a lost week of PTO? Not too crazy and anyone with a full-time job and some PTO could do this. I'd even get 'really sick' if I had too.

It's true that every job has risks. Where do you see me (or OP) say otherwise? The question is should every candidate give up a whole week of his or her time knowing it will get most people nowhere. That method's benefit is almost entirely rigged for the hiring party with huge potential for waste for other party in any environment with multiple, decent candidates. A few anecdotes that worked out don't change that.

So, the question is: "Should employers put this kind of burden on every candidate or try a method which demonstrates skill with less time?" I push for the latter.

Re: Destroy all hiring processes

#60

Post by kabdib »

morgante wrote: post #51
dustywusty wrote: post #9

As both an interviewer and interviewee at Weebly, I'm pretty confident in saying I prefer our approach of the trial week. It really gives a great opportunity for the candidate to show off their skills without the on-the-spot pressure of a coding interview. A great side-effect is the candidate gets to determine if they like the team, and vice versa. I honestly wouldn't work somewhere else where I couldn't come in for…

Instead of repetitively saying that you went through this same gauntlet yourself, how about an argument for how you think this is possibly a valid strategy for attracting good already-employed developers? As I see it, there are 2 huge barriers to me ever doing a trial week while currently employed: 1. If it doesn't work out, I've just burned 1/4 of my vacation time for the year. That's a pretty massive ask for a comp…

> Of course, it could also be that this is a brilliantly designed strategy for weeding out expensive employees by focusing on the unemployed and unsavvy.

This is the result, intended or not.

The problem is, the good people usually don't need a job. So the more of a gauntlet you make your hiring process, the less likely it is you'll get one of those already-employed, perfectly happen and great employees. You're selecting the people who couldn't get jobs at your competitors (modulo the false-negative rejects).

Post reply on HN