Live data from Hacker News

People suck at technical interviews (2014)

seldo.com

91–100 of 315 posts

Re: People suck at technical interviews (2014)

#91

The problem with his interviews is that it's even more easily gamed. It doesn't really take a genius to go through their employment history and memorize blurbs that show learning technologies, applying it successfully while being humble and nice for one day.

If an interview like that can be gamed by "memorizing blurbs" then it wasn't done correctly. A properly conducted interview will see the interviewer tugging at threads to go deeper. At some point they will crack because memorization won't be enough. Unless of course they are anpathological liar, but those are rare enough that I would ignore the posssibility at the interview stage.

You're right, I exaggerated but I don't think this is a hard game. People spend several months right now on studying interviews. The topics are wide and scope enormous, hence so many complaints; some companies test you on languages, others on algorithms, data structures, dynamic programming, bit manipulations, SQL queries, scalability, unix internals, I could go on and on. On the other hand, there's only so many paths these past history conversations can go, and you know where they can poke at.

Re: People suck at technical interviews (2014)

#92
post #10

Earlier quoted context omitted.

Yes, I find it ironical that I was way better at coding tests 15 years ago straight out of University. Nowadays I think longer and write less code. It works better.

One great example is Haseeb, who spent two years of all his life programming. He now commands a $250k salary (which, I say more power to him for exploiting our current interview system). I don't doubt that Haseeb is an excellent programmer. But not everyone has two years to devote to mastering the interview system like him, and there are plenty of skills you won't get just by doing competitive programming. http://has…

That was a very fascinating read, and completely illusion-shattering regarding the skill tech companies have in giving offers to good candidates. Social proof provided 90% of his increase in market value. I am not doubting that he is a very skilled developer, but this was certainly not the key reason why he got such a good offer :)

Re: People suck at technical interviews (2014)

#93

Hiring Manager Perspective: Everyone lies, sorry. As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them. My technical isn't complicated. A very basic SQL assignment (delivered to an audience which claims to know SQL) that is followed by a few broader database design / data process QA questions. En…

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 conversation you can learn a lot. How do you do async programming (answer you structure the code to make it easy for it to scale)? What experience do you have with RDBMSs? (we're looking for higher level answers). What's the difference between jquery and prototype? How do you deal with conflict? What's the most important thing about coding style? And you let the conversation flow depending on what they say and how they answer the questions.

Re: People suck at technical interviews (2014)

#94

Hiring Manager Perspective: Everyone lies, sorry. As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them. My technical isn't complicated. A very basic SQL assignment (delivered to an audience which claims to know SQL) that is followed by a few broader database design / data process QA questions. En…

I've been on the interviewer side in the past when this was the setup:

People are given a basic coding challenge. On the level of "parse roman numerals" or similar with some tests, standard kind of basic things that rosetta code will list implementations of in every possible language. The code was to be written in any language the person wanted. This was not timed, and was to be done at home.

50%, easily, didn't work. Many did not compile, or were totally incomplete. One was a broken implementation in C# submitted as a single function pasted inside a word document.

Only one person out of I think 20 sent a zipped copy of all the code, a short instruction of how to actually run it, and included some tests.

After that, I started to understand just why these kind of little programming tasks were given.

> And don't get me started about Python. Lest I bring up the Google-Motorola "I LUV Python heart heart heart" guy who didn't understand the difference between a list & dict.

Hah. I've had someone who didn't know the difference between local and global variables trying to come in as a fairly high rate contractor.

Re: People suck at technical interviews (2014)

#95

Hiring Manager Perspective: Everyone lies, sorry. As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them. My technical isn't complicated. A very basic SQL assignment (delivered to an audience which claims to know SQL) that is followed by a few broader database design / data process QA questions. En…

> in fact, my SVP asked for a copy of the report it generates when he saw the problem on my whiteboard

That's one of the most inadvertently funny things I've read on news.yc in a long time!

Re: People suck at technical interviews (2014)

#96

Earlier quoted context omitted.

That is actually a really great point. Its like hiring a writer based on their grammar. A writer could have perfect grammar but their books are boring as hell. Or even hiring a writer for adhering to the techniques of connoisseurs. The book "Ready Player One" was heavily criticized as amateur work (it was, after all, the author's very first book), but it nonetheless was hugely successful (and even has a movie in the…

Would you hire a writer with bad grammar?

As an example of a brilliant book with awful grammar, there's Heinlein's The Moon is a Harsh Mistress.

Re: People suck at technical interviews (2014)

#97

Earlier quoted context omitted.

Could you make a Photography portfolio without any photographs? You're allowed to include sketches, because you have time to make those for personal projects. But no photographs because they're all proprietary.

This analogy makes no sense. I often encountered situations where clients wanted to keep photos 'private'. I couldn't use them in my portfolio. To deal with that I took my camera and lenses (analogous to a computer) and made some equivalents that allowed me to demonstrate my skill in a similar way (analogous to writing some code in a personal project). Suggesting you should sketch something to show your photo making…

Think of "the photographs" in the analogy as the code that a full-time developer with a wife, kids, and non-coding hobbies has produced for his/her employer over the last five years. This person may produce a script or a basic website for a portfolio, but those 40+ hours a week spent coding at a full time job is where all of the real problems get solved.

Re: People suck at technical interviews (2014)

#98

Hiring Manager Perspective: Everyone lies, sorry. As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them. My technical isn't complicated. A very basic SQL assignment (delivered to an audience which claims to know SQL) that is followed by a few broader database design / data process QA questions. En…

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.

Re: People suck at technical interviews (2014)

#99
Some people are just bad at giving interviews. If someone is so bad at interviewing they will eliminate a candidate because they slipped up a little with a programming teaser, they're still going to be bad at interviewing if they try another technique.

I'm completely happy doing programming puzzles in interviews myself as I've worked with people that claim to be experts in something when they aren't and some people exaggerate to the point of lying on CVs. As long as you don't penalise a candidate too much for not getting perfect answers I don't see the issue.

Re: People suck at technical interviews (2014)

#100

Earlier quoted context omitted.

This analogy makes no sense. I often encountered situations where clients wanted to keep photos 'private'. I couldn't use them in my portfolio. To deal with that I took my camera and lenses (analogous to a computer) and made some equivalents that allowed me to demonstrate my skill in a similar way (analogous to writing some code in a personal project). Suggesting you should sketch something to show your photo making…

Think of "the photographs" in the analogy as the code that a full-time developer with a wife, kids, and non-coding hobbies has produced for his/her employer over the last five years. This person may produce a script or a basic website for a portfolio, but those 40+ hours a week spent coding at a full time job is where all of the real problems get solved.

> This person may produce a script or a basic website for a portfolio, but those 40+ hours a week spent coding at a full time job is where all of the real problems get solved.

That's it right there. That's the bit that makes the difference. It speaks to an attitude of 'I'm doing it, I don't need to prove it'. It's wrapped up in 'I'm doing it and I'm too busy to prove it because I should have a life and other people should just recognise my ability so I don't have to sacrifice my lifestyle to put the effort in to get the job I want"...but it really comes down to thinking I shouldn't have to show it because I'm doing it.

There's no can't show it inherent in your original statement. There's a large dollop of don't want but no can't.

You can find ways to prove you ability, to use work you do day to day, to make high quality personal projects or contribute to those that are already running (beauty of programming is it can be easier to collaborate like this and still show your skill).

It can be done. Plenty of people in all industries work one job and study, prepare or work towards another all whilst supporting families and trying to have a life.

Programmers aren't special snowflakes, they've got to work just as hard at selling themselves as all other people in the creative industries do. That's why I think programmers really need to grasp that they actually are creatives and adopt an attitude that deals with all the burdens that moniker brings with it.

Post reply on HN