Live data from Hacker News

People suck at technical interviews

seldo.com

121–130 of 177 posts

Re: People suck at technical interviews

#121
post #64

Earlier quoted context omitted.

That kind of question can actually be useful as a proxy for experience with the language, and whether you're the type of person who digs into understanding your tools. If you say "I'm a rockstar Javascript dev", it's very hard to prove it; but if you've never been bitten by some of Javascript's type conversions, and/or have never really looked into some of its intricacies on your own, you probably aren't. It's just o…

I find it hard to believe anyone has spent a bunch of time writing js and never been bitten by a type conversion. Am I wildly off base? I do data science, but everyone who writes R has been bitten by it's scoping rules, which are definitely not mainstream. Everyone I know who writes java or python has been bitten at least once by the pass object references by value (is there a better name for this?) function argument…

pass object references by value (is their a better name for this?)

Barbara Liskov used "call by sharing", aka "call by object-sharing" or "call by object". http://stackoverflow.com/questions/40480/is-java-pass-by-ref...

Re: People suck at technical interviews

#122
post #20

This is a really excellent post. It talks about a bunch of things that are hobby-horses of mine (I help run recruiting for a large software security firm), and I find myself agreeing with more of it than I disagree with. I would go a little further than Laurie does. I think several of the goals he sets up for his process are not in reality achievable in an interview process. Starting axiom: job interviews are among t…

> job interviews are among the most hostile experiences professionals endure in our industry I don't find being questioned during an interview hostile, although I do feel I need to be prepared to be tested. The most bothersome part for me is companies asking for me to list several references, often specifically asking for previous managers. I am usually given a standard application form to write their names, phone nu…

[deleted]

Re: People suck at technical interviews

#123
post #20

This is a really excellent post. It talks about a bunch of things that are hobby-horses of mine (I help run recruiting for a large software security firm), and I find myself agreeing with more of it than I disagree with. I would go a little further than Laurie does. I think several of the goals he sets up for his process are not in reality achievable in an interview process. Starting axiom: job interviews are among t…

> job interviews are among the most hostile experiences professionals endure in our industry I don't find being questioned during an interview hostile, although I do feel I need to be prepared to be tested. The most bothersome part for me is companies asking for me to list several references, often specifically asking for previous managers. I am usually given a standard application form to write their names, phone nu…

There are hostile interviews, but not all interviews are. I'll borrow from Michael Church [1] in describing what I consider a hostile interview. A hostile interview is any interview in which the interviewers are actively trying to remove the candidate from the pool. This can be a very subtle thing; as an interviewer, you have to ask yourself: Am I asking questions in order to attempt to weed out this candidate? Does this question have a right and wrong answer? And if so, what does it mean if they get it wrong? Did I simply discover a limit of their knowledge, or is it more ominous?

An important point is that you can be quite friendly and amenable, while still asking hostile questions intended to directly weed out candidates, as opposed to plumbing the depth and breadth of their knowledge and experiences.

[1] http://michaelochurch.wordpress.com/2014/07/13/how-the-other...

Re: People suck at technical interviews

#124
post #64

Earlier quoted context omitted.

I find it hard to believe anyone has spent a bunch of time writing js and never been bitten by a type conversion. Am I wildly off base? I do data science, but everyone who writes R has been bitten by it's scoping rules, which are definitely not mainstream. Everyone I know who writes java or python has been bitten at least once by the pass object references by value (is there a better name for this?) function argument…

Not at all off base. Which is the reason I would be deeply annoyed by the 4 == '4' question. The technical answer is it evaluates to true, but the real answer is "any code that requires all readers to have intimate knowledge of Javascript type conversion rules to read and understand is horrific code."

I'm with @lostcolony: if I were interviewing and a candidate said "don't do that, it's unpredictable, do this instead" it's a great answer.

Re: People suck at technical interviews

#125
post #52
post #21

Earlier quoted context omitted.

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.

Unless that person does a better job at helping the firm make money in which case you might be the one "at odds with the best interests of the firm".

Re: People suck at technical interviews

#126
post #121
post #64

Earlier quoted context omitted.

I find it hard to believe anyone has spent a bunch of time writing js and never been bitten by a type conversion. Am I wildly off base? I do data science, but everyone who writes R has been bitten by it's scoping rules, which are definitely not mainstream. Everyone I know who writes java or python has been bitten at least once by the pass object references by value (is there a better name for this?) function argument…

pass object references by value (is their a better name for this?) Barbara Liskov used "call by sharing", aka "call by object-sharing" or "call by object". http://stackoverflow.com/questions/40480/is-java-pass-by-ref...

thank you! I really like that

Re: People suck at technical interviews

#127

Earlier quoted context omitted.

I've often wondered whether for technical roles involving little or no client interaction[1], negatively-weighting skill at answering very pat interview questions (like where they want to be in five years, what they liked most about their degree course or why they're passionate about writing server side code for an ad platform) relative to their overall performance might actually be a useful, if very counter-intuitiv…

I think that falling into the trap of treating social skills and technical ability as a trade-off is a mistake. It's a hackneyed stereotype that I don't think has ever been true--but I'd imagine it has sometimes led to people expressly trying to seem socially abnormal in order to fit the idea of someone technically adept. I recall an anecdote about how a younger mathematician at a top research institution took up run…

I think he might be on to something

not be people with crap social skills are better than people with good social skill

but rather, people with crap social skills are easier for your competors to miss

good tech skill + good social skill = good and expensive

good tech skill + poor social skill = (I'll let everyone make up their own mind about how good they'll fit) definately less expensive though

any trait you overfit for is something you giving up other traits for somewhere else

Re: People suck at technical interviews

#128
post #24

> I used to ask people to write code in interviews. This is terrible. Bull! Last time I interviewed someone, they looked good on paper and decent on the phone. When it got down to solving a _simple_ problem on the whiteboard, he totally flopped. This is a totally realistic situation; we get together at least weekly and hammer out a solution on the whiteboard. Nerves could be an issue, but a good candidate should be a…

He didn't say coding was bad. He said coding on a whiteboard is bad. And, if you evaluated 100 strong developers by comparing their performance at a terminal and a whiteboard, my guess is that you'd quickly see that he's absolutely right about that --- not only would everyone outperform the whiteboard with a terminal, but that the whiteboard deficit would be highly irregular, defying any attempt to "handicap" for it.

Thanks for articulating this. I'm going through the interview process again now so this is especially resounding to me.

Re: People suck at technical interviews

#129

Oh how I agree with this post. And I've been the asshole on the hiring end before - but I (hope) have learned my lesson. I recently interviewed with a consultancy (role was UK-based) that is desperate (quite literally) to hire experienced developers in the technical area I have experience in. I came highly recommended by a recent senior hire of theirs (he had been my manager). The technical filter question in the fac…

> A recursive solution springs to mind, but I can recall implementing recursive solutions in production code only a few tens of times over a ten year career.

If you are not comfortable with recursion, just remember: Recursion is really just a free stack. To use your example:

Whenever you see an opening brace, push onto the stack. (Or, make a recursive call, which goes onto the call stack...)

Whenever you see a closing brace, pop off the stack. (Or, return from the recursive call, which then pops off the call stack...)

If the stack isn't empty at end of input, then there are mismatched opening braces. If you ever try to pop from an empty stack, then there are mismatched closing braces.

Re: People suck at technical interviews

#130
post #120
post #73

Having just had a 3h long technical interview for Google Deepmind, I cannot agree more with a lot of points raised in this post. Deepmind being a machine learning/statistics/maths/computer science fuelled company, it made sense for the interview process to follow this simple organisation. I was however very disappointed by the questions asked for each part. Not a single one of the ~100 questions asked during these 3h…

Do you think mathematicians start over from learning how to count everytime they encounter a new problem? That's different from looking up the 10th digit of pi: that's encyclopedic. Knowing what a classifier is is simply more than encyclopedic knowledge that you should probably know before joining an AI company.

As I said before, yes these are very basic questions... and I'm not complaining that the questions were too hard or anything, I'm saying that finding someone who will be able to answer 100% of these "definition" questions will not tell you anything about how competent that person is...

Making them face a simple stats/CS/maths/ML problem and see if he/she is able to come up with the relevant concepts is far more interesting.

Post reply on HN