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

People suck at technical interviews

seldo.com

Post reply on HN
Print view View original

51–60 of 177 posts

Re: People suck at technical interviews

#51

Post by greyskull »

lostcolony wrote: post #46
greyskull wrote: post #15

I'm just about to finish a B.S. in CS, so I've recently been on the other side of the table. I like to think I'm "aware" enough to give good feedback about my experiences. I've interviewed with two of the large "top" companies. They were two very different experiences. One decided to have me do multiple interviews, with whiteboard coding. The first interviewer was my favorite, because we got to talk about the design…

My favorite interview, ever, was a phone screen. Untimed. They gave me a weekend to solve two not really difficult problems, with well defined interfaces. The catch was to write it in a production ready style. That is, do everything I would do for actual production code. Documentation, test suites, write the code to be as elegant as possible, while failing as cleanly as possible if invariants failed. I have no idea t…

I'd probably fail that from lack of experience, but it does seem to be a great approach for someone a bit more seasoned. That shows a lot more about someone's software engineering capabilities than short tricky problems.

Re: People suck at technical interviews

#52

Post by jawns »

tptacek wrote: post #21
Jemaclus wrote: post #3

My primary criteria when interviewing junior candidates are: 1) Do you have basic problem solving skills? 2) Can you communicate clearly? 3) Do I want to sit next to you for the next 6 months or longer? If you don't know Ruby, I can teach you. If you don't know Elasticsearch, I can teach you. What I can't and don't have time to teach you is how to solve a problem on your own without me holding your hand, and I especi…

Criteria #3 is toxic. It's one of those things people adopt with the best intentions, but (a) is often at odds with the best interests of the firm and (b) provides an enormous amount of cover for prejudices and, more perniciously, cognitive biases. When you're interviewing a candidate, assume your brain is trying to trip you up (it is!). Build a hiring process that treats your intuition as an adversary and eliminates…

I largely agree with B but I'm not so sure about A -- particularly since hiring someone whom you don't want to be around is likely to affect your performance, which is likely also at odds with the best interests of the firm.

Re: People suck at technical interviews

#53

Post by hackinthebochs »

bcantrill wrote: post #40

I think a more apt title is "technical interviews suck", and speaking personally, I have entirely given up on them. (I would say that I gave up on them after two decades, but the truth is that I gave up on them a decade ago -- and I really tried hard in that first decade to develop the perfect technical interview.) My belief has become that the only way to hire the traits that I'm looking for (high technical ability,…

Homework is great, but only if a job offer is guaranteed if submitting a sufficient project. It is hubris to think someone will care enough about your company to spend 8 hours of their time for the small chance to be hired. Presumably you are giving the same assignment to a handful of other candidates. You are simply outsourcing much of the investment of hiring to the candidates. This is simply unethical (one of many tests for ethics is "if everyone did X, would the scenario be tenable"--in this case the answer is obviously no).

Re: People suck at technical interviews

#54

Post by Peroni »

tptacek wrote: post #21
Jemaclus wrote: post #3

My primary criteria when interviewing junior candidates are: 1) Do you have basic problem solving skills? 2) Can you communicate clearly? 3) Do I want to sit next to you for the next 6 months or longer? If you don't know Ruby, I can teach you. If you don't know Elasticsearch, I can teach you. What I can't and don't have time to teach you is how to solve a problem on your own without me holding your hand, and I especi…

Criteria #3 is toxic. It's one of those things people adopt with the best intentions, but (a) is often at odds with the best interests of the firm and (b) provides an enormous amount of cover for prejudices and, more perniciously, cognitive biases. When you're interviewing a candidate, assume your brain is trying to trip you up (it is!). Build a hiring process that treats your intuition as an adversary and eliminates…

Criteria #3 is toxic.

Nonsense. It's as toxic as screening a resume.

On one hand you have people with immense industry experience (such as yourself) advocating to drop the "do I actually like this person" approach and on the other hand you have people who also have immense industry experience advocating that culture fit should be one of the most important criteria.

I'd be interested in hearing your thoughts on eliminating prejudice (both intentional and unintentional) and cognitive biases whilst at the same time, ascertaining whether or not someone would be comfortable within your companies established culture and also contribute positively to said culture.

Re: People suck at technical interviews

#55

Post by lnanek2 »

> The famous fizzbuzz test simply asks "are you aware of the modulo operator?

No it doesn't. It could be implemented with counters you reset when needed. Didn't really read any further, I don't think this person should really be giving technical interviews anyway.

Re: People suck at technical interviews

#56

Post by darklajid »

The other side to that story: I'm scared like shit whenever (and that's often enough) I consider applying for a new thing. And back out, don't even try.

Most of the reasons are listed in the article, but let's be honest: I'd face most of these things.. So the pipe dream atm is to find some time for personal projects, foss contributions and .. use that to get to more reasonable opportunities. Reaching ten years with this company here, these interview stories might keep me here for another decade.

Re: People suck at technical interviews

#57

Post by watwut »

russelluresti wrote: post #23

I'm not sure I agree with the "team fit" thing. I get his point - most people don't understand what team fit is or can't separate it from personal bias. But here's my counter-argument. Every company and team has different core values. "Team fit" means matching company and team values. For example, I work on educational software for teacher and students. My definition of "team fit" (for this particular team/company) i…

Most people are fully able to work in both 100% done and release flawed but soon scenarios. Most people simply adjust to company they work in just fine. Almost all are also can work in both team and lone gunman settings - although they will have preference there.

Unless you are very careful, you can select out very good candidates basically based on how companies they previously worked in performed in those scenarios.

Re: People suck at technical interviews

#58

Post by btipling »

I've been interviewed by seldo before, when he was at awe.sm. It was a good technical interview. His questions were relevant and forced me to think. I like interviews in which I walk away learning something and I definitely did learn something in this case.

As for interviewing, I cringe when I think about the poor questions I have asked and the poor decisions I have made, and I try to learn from them. We ended up not hiring qualified people because of bad interviews, although that wasn't obvious to us at the time.

I was thinking for a future interview the candidate and I would try to learn some new technology and try to build something together during the interview or talk about it at least.

Re: People suck at technical interviews

#59

Post by TallGuyShort »

otakucode wrote: post #19
TallGuyShort wrote: post #9

>> Somebody who can intelligently discuss technology >> Somebody who knows what they don't know I believe in these principles especially. Most of my interview questions are vague (and I tell the candidate this up-front, and explain why). For instance, I'll ask them to explain how they would debug a very slow cluster, or to explain everything happens between me hitting the keys 'google.com' to me viewing the web page.…

Oh god, a question like the Google one would have me not knowing what to say... I mean, to give a reasonably complete answer would take hours and hours! What do you do if someone really goes into detail and can't even get to the part where the packet leaves the local network in a practical amount of time? Is that viewed as inappropriate overkill or a poor understanding of the question?

I wouldn't fault anyone for being able to go into so much breadth and depth that we ran out of time. I would suggest they just dive into the part they think if most interesting, or the part most relevant to the position. When we're out of time, we're out of time, but the point is just to stimulate enough technical conversation for me to evaluate the candidates knowledge, passion, communication skills, strengths, interests, etc.

edit: For instance, I actually got this question asked to me in an interview and adopted the practice several years later. It was scheduled for an hour, they asked me this immediately, and I was talking for most of the hour. I got through the whole process but didn't go into as much detail as I could've along the way. Several times I was stopped and asked to clarify some details, some of which I didn't know. That was that, and the interviewer just said "very good" and left. Looking back, I think he was doing the exact same thing I do now - giving me the freedom to show off what I knew, seeing if I would be honest when I reached my limit, and probing a bit to see if I could communicate about interesting problems.

Re: People suck at technical interviews

#60

Post by Ryel »

I've interviewed with dozens and dozens of startups in NYC. I'm an entry level Front-End Dev with passion for a lot of things I (in hindsight) probably should have gone to college for. For example, my current side-project is a completely client-side image metadata reader/writer that has forced me to learn new things like parsing Binary, Endianness, Meta and a lot of things about organizing JS because I've never built this large of a project completely by myself even though it is very, very small. A weekend project for most of you.

Throughout all of my interviews I've noticed one common trait.

Either I do exceptionally well on the personal questions during the interview, or I do really well on the technical questions. There is no in-between.

Most of my interviews could be broken up into 2 sections. The first section is usually where they open up and try to make things more comfortable. Asking me where I'm from, how long I've been writing code, what kind of side-projects I'm working on, etc...

The second part of the interview is when they try to figure out how much I know. Usually we start off by just talking about technology and this is where they try to figure out if I'm BS'ing my way through things. If you can maintain a fluent conversation about technology; you're good-to-go. After that they will generally try to slip in a few questions, usually about event delegation in Javascript.

The problem for me comes from when we switch from personal questions to technical ones, or vice-versa. I will pass either one with flying colors but I will rarely, if ever, pass both. If that particular day I can't sell my personal story very well, I do very well on the technical questions. If I do well on the personal questions, I do terrible on the technical questions. I believe there is a vast cognitive gap when you go from an emotional conversation talking about significant things in your past (like side-projects, old employers, hometown, etc..) and then jump to such rigid topics like code where there is no emotion, it's purely analytical thinking.

What I would prefer is for a company to pay me $100 to come into the office and work a half day. If I can keep up, I get the job.

Post reply on HN