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

People suck at technical interviews (2014)

seldo.com

Post reply on HN
Print view View original

221–230 of 315 posts

Re: People suck at technical interviews (2014)

#221

Post by st3v3r »

LionessLover wrote: post #22
Maakuth wrote: post #17

Earlier quoted context omitted.

Everyone I know doing recruiting says that FizzBuzz reliably disqualifies surprisingly large fraction of candidates. Even half of them, even after prefiltering by education or relevant experience.

That is a useless statement unless they followed the rejected candidates for a few more years at least . Otherwise it's just a tautology: They suck because my favorite test says so (i.e. because I say so). Sure it weeds out "non-programmers" - any programming task (more than "Hello World") does. But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-…

I'm sorry, but I just cannot accept that anyone who has any decent skill at programming would fail fizzbuzz.

Re: People suck at technical interviews (2014)

#222

Post by heartsucker »

Chris2048 wrote: post #202
heartsucker wrote: post #125

Earlier quoted context omitted.

I've had the same experience. Someone listed 2 years Scala experience on a resume, but couldn't explain Unit, None, null, and Nothing to me. Or the guy this week who had several years of ops experience and when asked "how can you tell what indexes are being used in a SQL query" didn't even know about EXPLAIN. Basic technical interviews are a must, but someone people get hung up on "they couldn't explain a hash map im…

To be honest though, just because you can get by without knowing how hash maps are implemented, doesn't mean it isn't useful to know - and if another candidate does know, they would sooner hire them. Further, they may be looking for factors that correlates with other, hard-to-measure factors. Even such as reading a "common interview questions" book - it correlates with focused pragmatism...

I'm not saying it's not useful to know or that having that knowledge might make someone a better candidate, but it seems like that alone shouldn't be reason enough to reject someone.

And I disagree that looking up the answers to common interview questions is focused pragmatism. I don't bother, even with the knowledge that it would help me get a job. I spend my time working on side projects or learning practical things. I think I will never in my life have implement a hash map, and that knowing it's all O(1) operations is sufficient. But also I guess I don't want to work for a company that is interested in my ability to jump through hoops. (shrug)

Re: People suck at technical interviews (2014)

#223

Post by st3v3r »

MrLeftHand wrote: post #15

With one of many job applications I did, I received a small coding exercise before getting to the actual interview. It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa. Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code. What was the answer? Sorry that's no…

No, they clearly wanted to see you write code. They didn't want to see how well you could download a library. That's why they gave you the test in the first place.

Re: People suck at technical interviews (2014)

#224

Post by hanginghyena »

MrLeftHand wrote: post #88
hanginghyena wrote: post #76

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…

Potential Employee Perspective: they can't be serious!!! A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one. Maybe employers should stop trying to find the non-existing 'developer rock-star' and people would stop lying. The funny thing is that even the developers themselves start to behave like that when they are on the other end of the hiring (Been there, don…

So respond to that job spec with a resume which clearly highlights the 3-4 things you actually did master, with multiple specific project examples and real roles/jobs.

You may be pleasantly surprised.

Speaking for myself, I will gleefully hop over piles of candidates with a 1/4 page of alphabet soup on their CV trying to talk with the candidate who hammers Python, PHP, Javascript (etc) across a 5+ years of different projects. Even if I'm hiring for a slightly different technology, because I can be confident they actually know the trade.

Multiple skill-sets do add value if they are related and easily combined to deliver a larger solution. Eg. HTML + CSS + Javascript = Front End Web Dev + Python + SQL = Full Stack Web Developer. So I can staff that person in a larger role.

The spew of semi-related and adjacent buzzwords doesn't really help me feel comfortable with a candidate. And if I start asking you about them and learn all you did was read about them online (or used it once for a class), the rest of your resume goes into the danger zone real quick.

"I mastered X, Y, and Z and used them together to build " will get you further than you think. Even if the job doesn't require X, Y, and Z....

Re: People suck at technical interviews (2014)

#225

Post by hanginghyena »

arethuza wrote: post #113
MrLeftHand wrote: post #88

Earlier quoted context omitted.

Potential Employee Perspective: they can't be serious!!! A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one. Maybe employers should stop trying to find the non-existing 'developer rock-star' and people would stop lying. The funny thing is that even the developers themselves start to behave like that when they are on the other end of the hiring (Been there, don…

5 years of SQL experience and no idea of what a join is? Isn't that like saying 5 years of C/Java/C#/... experience and not knowing what assignment is?

THIS.

Yes, there are SQL statements without Joins. No, we don't usually run them in the reporting organization....

Re: People suck at technical interviews (2014)

#226

Post by stuffedBelly »

tayo42 wrote: post #167
mattzito wrote: post #103

Earlier quoted context omitted.

At a previous startup, we gave potential developers a very simple test: we had a file with a comma separated list of movie titles, release dates, etc. The candidate was expected to: - read that file in - store it in some sort of data structure - allow users to run commands to retrieve movie titles based on name, release year, etc. Command-line was totally fine, you had access to the Internet, and as much time as you…

How would you do this without basically writing your own database from scratch?

for interviews I'd say even straight dumping data into the file system and retrieving later when the user needs it would be a somewhat valid approach. It's more important that the candidate is able to explain the reason he choose this approach over holding everything in memory (writing/retrieval overhead vs. memory limitation, etc), given the data size/structure of the assignment.

If candidates reason well about design decisions of their implementation, perfect or not, it at least tells me they are reliable developers who do not jump into coding before thinking carefully.

Re: People suck at technical interviews (2014)

#227

Post by hanginghyena »

mattzito wrote: post #103
hanginghyena wrote: post #76

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…

At a previous startup, we gave potential developers a very simple test: we had a file with a comma separated list of movie titles, release dates, etc. The candidate was expected to: - read that file in - store it in some sort of data structure - allow users to run commands to retrieve movie titles based on name, release year, etc. Command-line was totally fine, you had access to the Internet, and as much time as you…

Brilliant!

I may wind up stealing this as an alternative test for more advanced programmers; everything here can be done using the Python Standard library.

And kudos to those of you who suggested in-memory storage vs. writing it out to a table.

Re: People suck at technical interviews (2014)

#228

Post by machogeek »

cmrdporcupine wrote: post #106

That companies now insist on running the Google-style whiteboard-algorithms-coding-skill-testing-question type of interview tells me that there is no shortage of programmers to hire. Because as far as I understand it we use that process at Google because we can afford a lot of false negatives because we are inundated with a lot of resumes. Smaller companies and startups surely are not, and finding candidates must be…

I would gather if companies like the ones you mentioned adopted new ways of interviewing, or at least randomized it in way that it couldn't be easily cloned, other companies would follow suit or adopt their own style. The challenge is that every companies wants the "best" engineers and believes they deserve it... So in their minds, they do what they think the "best" do.

I have heard more than a handful of CTO's and companies sling this expression around as if using this phrase put them in company with the likes of Elen Musk. It's a joke to me really. I look forward to the day one of these guys says, hey, lets be original.

Contrary to your point, I believe there is a shortage of qualified programmers... or at least senior ones that can solve hard problems independently. Smaller companies need devs that can solve problems independently, with minimal oversight. Copying Google and Facebook is what they think the path is to get there.

Re: People suck at technical interviews (2014)

#229

Post by Scarblac »

Ma8ee wrote: post #66
Scarblac wrote: post #23

Earlier quoted context omitted.

I disagree. You need to be able to find existing working solutions and use them, sure. But you also need to be able to do this kind of thing yourself if you can't find an existing solution, because that also happens all the time. It's that ability that they were testing. That's perfectly valid. They should however have told you that before the test.

> They should however have told you that before the test. He should have been able to figure that out before the test. It was a test of his problem solving abilities, not his Google-fu.

He did solve the problem.

Re: People suck at technical interviews (2014)

#230

Post by mattzito »

tayo42 wrote: post #167
mattzito wrote: post #103

Earlier quoted context omitted.

At a previous startup, we gave potential developers a very simple test: we had a file with a comma separated list of movie titles, release dates, etc. The candidate was expected to: - read that file in - store it in some sort of data structure - allow users to run commands to retrieve movie titles based on name, release year, etc. Command-line was totally fine, you had access to the Internet, and as much time as you…

How would you do this without basically writing your own database from scratch?

Well, as other posters have commented you sort of do, but since we let you use libraries and the like, you had lots of options:

- sqlite

- Storable (perl)

- serialize some other data structure to disk

- in-memory

I seem to recall one or two people over the years who wanted to install a relational database as part of the code to store stuff - we were fine with that as long as you then showed all the right behaviors for dealing with relational databases (using transactions, catching errors, etc.)

But most people read it in and store it in memory - there was only a few thousand rows.

Post reply on HN