People suck at technical interviews (2014) • Hacker News Board

Re: People suck at technical interviews (2014)

#311

Post by morgante » Sun, Jun 12, 2016, 5:20 PM UTC

dfabulich wrote: post #21

skrebbel wrote: post #2

In all honesty, I'm not sure the author did a lot of interviewing. For example, > The famous fizzbuzz test simply asks "are you aware of the modulo operator?" Wait, what? No, it asks "can you write a for loop without breaking a sweat?". There's a rightfully vivid debate going on about the virtue of asking algorithmic questions in interviews, but fizzbuzz is hardly algorithmic. I'd wager that virtually all programmers…

>> The famous fizzbuzz test simply asks "are you aware of the modulo operator?" > Wait, what? No, it asks "can you write a for loop without breaking a sweat?". There are notorious cases where senior engineers with years of actual honest coding experience "fail" fizzbuzz. IMO, That happens in two ways: 1) Not knowing (forgotten?) what a modulus operator is, and trying to code one up from scratch with a for loop. This…

> Coding modulus from scratch with just + - / * is a fun little challenge in its own right, but it'll probably take you longer than 10 minutes to write it correctly and solve fizzbuzz with it.

I've seen numerous people fail on FizzBuzz despite supposedly being senior engineers.

None of them failed because they didn't know the modulo operator. For one thing, it's actually pretty easy to solve even without modulo.

If someone doesn't know modulo, I'll happily explain it.

More commonly, people struggle with even basic things like setting up a loop at all.

Re: People suck at technical interviews (2014)

#312

Post by odonnellryan » Mon, Jun 13, 2016, 11:03 PM UTC

up_and_up wrote: post #238

odonnellryan wrote: post #234

Earlier quoted context omitted.

> Time investment: 10 mins to review the code I never think this is fair. Why is it fair for the candidate to spend a day working on a project (which you will do for even simple projects, if you actually want to get hired) when it takes you ten minutes to review the code? > The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well…

> I never think this is fair. The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one. > You don't know anything about them by reading this project. You actually know quite a bit about them after a phone sc…

> The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one.

Mostly, you're determining who had more time to spend on the project.

> You actually know quite a bit about them after a phone screen plus this project. If they cant come up with a decent solution to a small and simple project then they are not advanced in the process.

You're adding another thing to rule candidates out but not in. The problem with exclusion is it becomes more and more likely to rule out good candidates.

Re: People suck at technical interviews (2014)

#313

Post by deminature » Wed, Jun 15, 2016, 2:35 AM UTC

PuffinBlue wrote: post #26

There needs to be a bit of a shift in understanding what 'category' of worker a programmer 'is', both by companies and more importantly by (some) individuals themselves. Programming is both technical and artistic. It's a creative endeavour that relies on technical skill to complete. The best analogy to another profession would be to those in the 'technical arts', those like photography, joinery, painting, sculpture,…

Having been through interview processes at big tech companies recently, I invested some time in preparing a portfolio to try and improve my chances of success. What I encountered was that nobody is really interested in your portfolio (or even your resumé really). I appreciate your advice that a portfolio should improve your chances, but nobody from any of the companies looked at it. I'm not sure it's a good investment of time, considering how little importance is attributed to it.

Re: People suck at technical interviews (2014)

#314

Post by singingfish » Sun, Jun 19, 2016, 10:00 AM UTC

_asummers wrote: post #98

singingfish wrote: post #93

Earlier quoted context omitted.

I've recently got into the interviewing for devs game. Now we're a perl fairly specialised shop, and we only hire experienced people so that makes things relatively easy (candidates need to demonstrate a depth of knowledge, and . The pool of people around is relatively shallow too. We don't actually need to ask people technically detailed questions about specific algorithms. We have a conversation. From that conversa…

One of my favorite questions is asking people their least favorite and favorite languages then asking people to give one of their favorite features in the least favorite language, and least favorite features in their favorite language. Shows that they've actually spent time thinking about their tools. You get a surprising amount of insight from it, depending on the answer.

Yes that's a good question, I wouldn't like to have that without notice in an interview :)

Re: People suck at technical interviews (2014)

#315

Post by singingfish » Sun, Jun 19, 2016, 10:02 AM UTC

lmm wrote: post #196

singingfish wrote: post #93

Earlier quoted context omitted.

I've recently got into the interviewing for devs game. Now we're a perl fairly specialised shop, and we only hire experienced people so that makes things relatively easy (candidates need to demonstrate a depth of knowledge, and . The pool of people around is relatively shallow too. We don't actually need to ask people technically detailed questions about specific algorithms. We have a conversation. From that conversa…

Doesn't that risk hiring someone who says the right high-level things (maybe they've read some books) but can't actually do anything at the concrete implementation level?

Yes this is true. But I'd be hoping they'd also have something on github or the cpan, or other places to show their general thought processes. Or at minimum a credible recent employer and references to back it up.