Live data from Hacker News

People suck at technical interviews (2014)

seldo.com

181–190 of 315 posts

Re: People suck at technical interviews (2014)

#181

Earlier quoted context omitted.

I hear you. I'm terrified by the kinds of interviews that want programming trivia. In the last three years I've never had to code a binary search tree. But I should be able to show you I'm very comfortable with Python.

As an interviewer, I don't ask this question but if I did then you could impress me by asking what a binary search tree is, then I would tell you, then you explain or write how you would do it. Most of these interview questions aren't designed to be trivia. It's designed because your job IS implementation of technical and business problems.

That's usually not how it works though. You're more likely to be laughed out of the room for asking such a silly question, despite the fact the (presumably technical) interviewer could do no better without the teacher's copy in front of them.

An aside, but I think interviews like this should allow Internet connections. Give the candidate a minute to look something up and digest it in their own way. It should be obvious whether they'll get the concept or just recite the Wikipedia definition. Just as important is how they do their research, and how they draw connections between foreign and familiar concepts given a blueprint of the former.

Re: People suck at technical interviews (2014)

#182

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?

After interviewing thousands of candidates over the years, I say anything is possible. One candidate I recall was 24+ years of development experience mostly consulting in firmware. He graduated from a top school and was referred by our VP of ASIC engineering. Yet he struggled at the most basic C pointer question. He tried everything in the interview to prevent us from asking any coding questions.

Re: People suck at technical interviews (2014)

#183
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…

I had a pretty interesting experience with this.

We were doing a bunch of interviews and decided to try out FizzBuzz. I wasn't doing this round of interviews, but things ended up a bit confused with timings and I had a 30-40 minute very casual chat with each candidate prior to the actual interview.

In each of those I ended up probing a bit on technical stuff and everyone seemed to have a decent base level of competence. But they all went to pieces over fizzbuzz in the interview.

The one I actually saw, I had had a fairly in depth conversation about what it actually means to use "ref" and "val" in C#, but then watched the same guy freeze and barely scrape through fizz buzz.

My conclusion is that some people just can't write code in that kind of environment. What makes it tricky is some people (myself included) find it easy or even fun - maybe I can write fizz buzz in a single LINQ statement...Those people can assume that everyone not like them can't code.

Re: People suck at technical interviews (2014)

#184

Earlier quoted context omitted.

I hear you. I'm terrified by the kinds of interviews that want programming trivia. In the last three years I've never had to code a binary search tree. But I should be able to show you I'm very comfortable with Python.

As an interviewer, I don't ask this question but if I did then you could impress me by asking what a binary search tree is, then I would tell you, then you explain or write how you would do it. Most of these interview questions aren't designed to be trivia. It's designed because your job IS implementation of technical and business problems.

They might not be trivia, but they're not presented in the same manner as someone would be doing on the job and/or the candidate isn't given the same access to tools they normally have when working and/or there's an 'on the spot' requirement to answer the question.

I don't store everything in my head anymore. I have a general understanding of the concept and a mental pointer in the form of the search term to put in google to refresh how to implement the thing.

I have to implement 10-20 concepts across 5-10 languages or APIs or technologies every single day usually, my brain doesn't work like a database where every record that's inserted is there permanently until I update or delete it. The stuff I'm not using regularly gets fuzzier and fuzzier and goes back to "general concept mode" if I'm not actively using it.

So when someone asks me to write a full iOS app during an interview when I've been making Microsoft business apps for the past year, even though I've written and released multiple full iOS apps at previous jobs, I can't just sit down and produce a perfectly working app like a robot, especially if I didn't have much time to prepare for the interview (that recruiter contacted me three days earlier and didn't tell me he set up an interview until 8pm the night before).

With technical questions it's even worse, because I could have been spending days and days refreshing my knowledge but you happen to choose one of the things I didn't think to refresh my brain on. And so I waffle on the answer and you go "oooh, looks like he doesn't know anything". No, I've got a full decade of making apps and software, in lead roles, in multiple industries with a bunch of different technologies. I know plenty. I just didn't have that question fresh in my head.

Then you pass, and lose out on someone you would have benefited from greatly in favor of the recent grad student that hasn't made anything but toy programs yet got tested on all those concepts within the past six months so it's fresh in their heads.

Re: People suck at technical interviews (2014)

#185

Earlier quoted context omitted.

* It's a great predictor for "can this person actually program, well, at all?".* How do you know, have you hired many who had trouble with the Fizzbuzz? Or are you just guessing? (I don't know either; there's a lot of missing data in interviews)

It's genuinely surprising what people don't know. "If I roll this d6, what will the average be over time?" I've asked this to loads of supposed graduates, and apart from the odd one who made the "WTF are these monkeys hiring me for" face, a lot of people can't figure it out from first principles. But a lot of people choke on it. Also I've had people choke on very basic general knowledge like "think of a large emergin…

"If I roll this d6, what will the average be over time?"

I'll be honest, that's a really dumb question for testing programming skill.

Re: People suck at technical interviews (2014)

#186
post #167

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?

Admittedly a database would make the querying more efficient (this is actually probably a good use case for Mongo), but you could just keep a dictionary for each query-able field if you want better than O(n).

Only once they ask for efficient Levenstein-distance-supporting search do you need to use any brainpower.

N.b. if you choose to parse CSV from scratch, make sure to handle commas in quoted text as well as escaped quotes. The better approach is to grab a library or code snippet and call it a day.

Re: People suck at technical interviews (2014)

#187
post #171

When I interview, I try to find out what the person is good at. Everyone who comes to interview is good at something (even if it's just good at getting interviews). Sometimes their skill-set overlaps with what we need, sometimes it doesn't. But the focus is figuring out what they are good at, rather than an abstract test.

Are you hiring? I've had a pretty miserable week of interviewing. Either I'm not the right fit or the potential employer is less than ideal.

Right now I'm looking for a job, not hiring haha. The table is always spinning.

Re: People suck at technical interviews (2014)

#188

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,…

I have a portfolio (it's a bit dated now, though, and only includes the games I've worked on). It's always clear in interviews that my interviewers never bothered to look at it, though.

Still get the pop quiz interviews almost every time (with or without coding) and it's pretty clear my chances of getting an offer is at least 90% based on how well I do on their pop quizzes.

Re: People suck at technical interviews (2014)

#189

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…

Agree with you MrLefHand, But would it not be responsibility of sql programmer to keep himself update? even if it is not possible in company. Like we never get to touch AD in any company because most of them already have it setup but we still go and test in VM with eval editions and such?

Sometimes you don't know what you don't know. I was completely torn apart the first time I was interviewed for a Scala position, because the guy didn't believe I could possibly have spent three months doing Scala professionally and didn't know basic List methods like fold (we'd been avoiding using Scala collections because we knew the migration was coming, and had just been writing Scala with the Java collections).

Re: People suck at technical interviews (2014)

#190

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…

>made some equivalents that allowed me to demonstrate my skill in a similar way (analogous to writing some code in a personal project).

Except that doesn't work in programming. I can't take the core bits and re-release them in my own projects. In fact that's literally what I'm prohibited from doing.

While in photography you can make the same photo with different people, in programming you absolutely cannot simply rewrite the same code.

Post reply on HN