People suck at technical interviews • Hacker News Board

Re: People suck at technical interviews

#41

Post by jghn » Wed, Aug 27, 2014, 4:55 PM UTC

aliston wrote: post #2

I think there are some good points here, but I would argue that a lot of these are essentially points for hiring more junior engineers. There are cases where hiring for what someone already knows DOES matter. I have come across too many codebases that were clearly written by folks who were in the "get stuff done" mentality. Frankly, when you're learning a new technology in addition to trying to do your job, your code…

IMO this is a red herring. Even ignoring shifts in language and such, I'd imagine/hope that just about everyone would cringe a bit if they looked back at code they wrote some time in the past. It's natural - we're constantly learning and constantly improving.

I've changed languages multiple times in my career and yeah sure, one isn't writing idiomatic code right away but with a little breadth of knowledge and armed with modern tools such as stackoverflow it's really not a long transition period. If you add in a strong team and a strong culture of code reviews, the really egregiously non-idiomatic code will never make it in the codebase anyways (not to mention, the newbie will learn along the way).

Re: People suck at technical interviews

#42

Post by spdy » Wed, Aug 27, 2014, 4:56 PM UTC

buckbova wrote: post #30

tptacek wrote: post #24

Earlier quoted context omitted.

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.

I would rather hire the strong developer that can code without autocomplete and write without spellcheck.

Why? Because he is good at memorizing things? That does not make the strongest developer.

Re: People suck at technical interviews

#43

Post by mikeleeorg » Wed, Aug 27, 2014, 4:56 PM UTC

fnbr wrote: post #25

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…

As a junior developer, I find myself confused by your comment. It seems as if a large proportion of the posts on HN claim that, when looking to hire someone, they focus on problem solving abilities and and culture fit. However, in May when I was interviewing with companies (including YC backed startups), almost every company focused on quizzing me about trivia [1]. I was actually given a paper quiz by one of the comp…

I was treated with respect throughout the whole process, and the interview was very well done, with challenging questions that forced me to think, and didn't rely on language trivia. I would recommend the company to any of my friends, whereas I can't say that about almost any other company I interviewed with.

This is a really important point to remember for interviewers. The interview process isn't just to help you find good candidates, it can be a great branding/marketing vehicle as well. I've gotten many good people from former candidates who enjoyed our process and spoke highly of our team.

I wouldn't have just stopped replying to emails though. An interviewer should always reply, even to politely decline. And it can help to add a reason why you are declining a candidate too, since it can help them improve and perhaps return for another interview in the future (I've hired a few people that I originally passed on too).

Re: People suck at technical interviews

#44

Post by applecore » Wed, Aug 27, 2014, 4:57 PM UTC

tptacek wrote: 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…

> You aren't interviewing people to determine how good they are at interviewing, because interviewing doesn't generate money for your company.

Depends. At most companies, how you handle a simple interview is still relevant if it's for a revenue generating or client facing role (e.g., sales, marketing, and project management).

Granted, most technical roles aren't generating revenue or in contact with clients, so this isn't nearly as important.

Re: People suck at technical interviews

#45

Post by ionwake » Wed, Aug 27, 2014, 4:59 PM UTC

This is the most god damn cathartic thread I have read on this site after taking 1.5 years out to work on my own stuff and having failed 4 interviews getting back into the workforce, with the most random god damn shit technical tests.

Re: People suck at technical interviews

#46

Post by lostcolony » Wed, Aug 27, 2014, 5:03 PM UTC

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 their results with that, and I ended up taking a job before the in person interview, but I enjoyed the screener a lot.

Re: People suck at technical interviews

#47

Post by cjslep » Wed, Aug 27, 2014, 5:06 PM UTC

For my first job out of uni, I was asked to write pseudocode on a whiteboard to solve a simple scripting problem (call an executable repeatedly, changing the command line args). My background is nuclear engineering, and I was interviewing at a cloud/networking business, so I was already slightly outside my experience comfort zone[0]. I was explaining my thought process while writing on the whiteboard, trying my best to be transparent about how I was thinking, when the interviewer interrupted me.

"What is that?" he asked, pointing at the whiteboard.

"...pseudocode?" I replied, hesitantly, frantically looking for some mistake where he was pointing.

"That's not pseudocode..." he said as he started to berate me for not writing bash.

After that (I did not get an offer), every interview I went to when someone asked me to write pseudocode I'd always clarify "Is there any particular language you want me to use?" because I never want to relive that experience again.

[0] I had previous experience interning at Cisco.

Re: People suck at technical interviews

#48

Post by bmj » Wed, Aug 27, 2014, 5:06 PM UTC

applecore wrote: post #44

tptacek wrote: 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…

> You aren't interviewing people to determine how good they are at interviewing, because interviewing doesn't generate money for your company. Depends. At most companies, how you handle a simple interview is still relevant if it's for a revenue generating or client facing role (e.g., sales, marketing, and project management). Granted, most technical roles aren't generating revenue or in contact with clients, so this…

most technical roles aren't generating revenue

Wait, what? The products I build don't generate revenue for my employer?

Re: People suck at technical interviews

#49

Post by Apocryphon » Wed, Aug 27, 2014, 5:08 PM UTC

tptacek wrote: post #32

buckbova wrote: post #30

Earlier quoted context omitted.

I would rather hire the strong developer that can code without autocomplete and write without spellcheck.

That'll come in handy when the inevitable days-long autocomplete and spellcheck outage strikes.

Or if the firm only uses Emacs.

Re: People suck at technical interviews

#50

Post by tptacek » Wed, Aug 27, 2014, 5:08 PM UTC

Apocryphon wrote: post #49

tptacek wrote: post #32

Earlier quoted context omitted.

That'll come in handy when the inevitable days-long autocomplete and spellcheck outage strikes.

Or if the firm only uses Emacs.

You use Emacs without autocomplete? That's not snark: I'm just here to tell you that Emacs has fantastic autocomplete and you should definitely look into it.