Destroy all hiring processes • Hacker News Board

Re: Destroy all hiring processes

#61

Post by fishtoaster » Tue, Oct 20, 2015, 1:08 AM UTC

I'm of the opinion that pretty much every interview technique has at least some tradeoffs. Too many false positives, too many false negatives, selecting for or against certain groups, etc.

At my current company, we don't do any phone-coding or whiteboard-coding, for which I am very thankful (for the reasons the article laid out).

We do do a take-home dev test (4-6 hours). This has the benefits of being low-pressure, repeatable, and similar to the real work we do. It has the tradeoff that we might miss out of great devs who don't have the time to do it. We're working on shortening it to offset that.

We also do a bit of paired programming on-site (using the candidates computer and dev environment of choice). This has a distinct tradeoff, since it can be a bit high-pressure. We try to do everything we can to ease candidates, but I haven't found anything else that works well for getting a feel for what it's like to work with someone in a technical capacity.

Every interviewing technique has issues, and I think phone and whiteboard coding are among the worst still actively used (now that brainteasers are mostly dead). I think what we have is the least-bad, but we're still iterating on it (and hopefully always will be).

Re: Destroy all hiring processes

#62

Post by soham » Tue, Oct 20, 2015, 1:18 AM UTC

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…

Well said.

That's exactly why it pays to prepare for coding interviews. If companies are not going to be thoughtful about interviewing, candidates can either reject those companies, or prepare for those interviews. My belief is that if more candidates are professionally prepared with those closed-ended questions, this will eventually force companies to be more thoughtful.

[Us: http://interviewkickstart.com]

Re: Destroy all hiring processes

#63

Post by mrep » Tue, Oct 20, 2015, 1:23 AM UTC

supercanuck wrote: post #30

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…

I'm just kind of flabbergasted that someone with 6 years of matriculation from Computer Science Program has resulted in the equivalent of a truck driver spending four weeks on Code Academy. It just doesn't jive... >I have a philosophy degree, by the way. Not to be smug about it, but several very good people I know and respect in the software field came to it from that background. Ahh... now it makes sense...

I believe he is referring to people who got there bachelors in a different major, and then got their masters in CS.

Re: Destroy all hiring processes

#64

Post by IndianAstronaut » Tue, Oct 20, 2015, 1:32 AM UTC

davnicwil wrote: post #40

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…

Brilliantly put. When I'm giving interviews I really like it when a candidate posed with a fairly complicated problem or design question pauses and actually thinks, then says something like "..well, I don't really know, I'd probably want to think about it more, but here's an idea" before putting forward their likely non-optimal but totally plausible and on-the-right-track design or solution that they thought of on th…

I recently interviewed at Facebook and they seem to want the shoot from the hip type person who is extremely confident (borderline arrogant) about their answers. Theh drill and drill amd expect rapid fire responses.

Re: Destroy all hiring processes

#65

Post by berntb » Tue, Oct 20, 2015, 1:36 AM UTC

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…

Some people just can't learn the programming part.

I studied (and helped with labs a few times) two of these. Mathematics and theory was fine, but the rest not. Weird, I wouldn't have believed it was possible after years of university, if I hadn't seen it.

One became a teacher, I don't know about the other. He might have become a quite good entrepreneur. Seriously.

The point is, it is possible one of these are the next person with a theory heavy background you interview... (But ok, we all know that too well even with little experience of hiring. :-( )

Re: Destroy all hiring processes

#66

Post by Terr_ » Tue, Oct 20, 2015, 1:39 AM UTC

blizkreeg wrote: post #3

> Even among the most common demographics for developers (American, male, white, skewing young and middle-class background), we are absolutely abysmal at this.. How does nationality, gender, race, age, and income level have _anything_ to do with this at all ?

He's emphasizing how determining whether a candidate is good or not is hideously inaccurate and frustrating for everyone involved... Even without barriers of language, ethnicity, culture, age, or discrimination-of-same.

Re: Destroy all hiring processes

#67

Post by IndianAstronaut » Tue, Oct 20, 2015, 1:39 AM UTC

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…

I did something similar with another company wherei did remote part time work for 2 months to see if they would like me and vice versa.

Didn't end up working out so I was glad it was only part time and I didn't make the jump. If I made the jump directly, I likely wouod have been laid off and unemployed.

Re: Destroy all hiring processes

#68

Post by aggieben » Tue, Oct 20, 2015, 2:01 AM UTC

ubernostrum wrote: post #45

aggieben wrote: post #37

> a belief that memorizing a bunch of that stuff and being an automaton who spits back the correct algorithm name and a pseudocode implementation is all there is to programming. Because what companies really want is to hire a Fisher-Price See-‘n-Say toy, right? I get the overall rant. I understand the frustrations - but this is wrong-headed. If you can't see the value of understanding algorithms - learning both how t…

It's more that there's a lot of cargo-culting and "Google did this, so it must be good" flying around, and a lot of really bad CS programs which revolve more around the Feynman-rant memorize-and-regurgitate style than actually understanding performance characteristics. Which in turn produces interview processes that really are of the See-'n-Say variety. Though to be honest, for a lot of what I do my working set in me…

Fair enough, but then you should explain that what you're against is mindless regurgitation, not good CS education (which again, has algorithms at its core, but goes far beyond that).

Re: Destroy all hiring processes

#69

Post by raygull » Tue, Oct 20, 2015, 2:08 AM UTC

I've been interviewing recently and it does suck just as described here, so I'm glad somebody called out these issues.

One company I talked to was like a caricature of the bad startup interview: we have a billionaire founder, we have wine on tap, a totally disorganized 4-hour series of discussions where the first person just sat down and started quizzing me with hardly an introduction, and I had to ask the second interviewer how many people I'd be talking to, technical questions ranging from the simple to somewhat difficult (using paper and pencil), with less and less time for each because they couldn't follow their own schedule, followed by an interview with an arrogant, hypercaffeinated CTO, consisting of two brain teaser questions and a series of elevator pitches, all in a tiny glass room near the back storage area, devoid of oxygen. And the following week I found out, sorry, they'd cut funding for the position the day before I came in.

Re: Destroy all hiring processes

#70

Post by eveningcoffee » Tue, Oct 20, 2015, 2:11 AM UTC

msoad wrote: post #16

I'm working on open source stuff for two years now. Everything I do is public for everyone to see. Including my responses to bug reports and design documents. Yet I get the same algo/ds puzzle questions that you should've solved before in order to solve it in an interview setup. Google reached to me and said based on my profile I can skip the phone interview but I'm so afraid of the interview that I postponed it mult…

* Google asks questions like pots of gold[1] where it's really impossible to solve it on a whiteboard if it's your first time seeing the problem. *

Ok, so here is an anecdotal sample. I have not seen this problem before.

After reading the problem description I tried one round of the game on the paper (actually in the text editor) to get the feeling of the game play and then it took me about few minutes to come up with one possible solution and then after a little bit of thinking with a more optimal one.

So not impossible (but I was in comfort of my home).

I actually think that this is a rather classical CS problem that does not require some thinking about more abstract mathematical corner cases.

I give an example of the later one.

You have an array or numbers [1 - n], that is not sorted. One of the numbers got changed to 0. Given an array after the change return the changed number in linear time.

Assume the some array but two of the numbers got changed to 0. Given an array after the change return the changed numbers in linear time.