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

131–140 of 315 posts

Re: People suck at technical interviews (2014)

#131

Post by lordnacho »

ktRolster wrote: post #8
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…

* 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 emerging economy in Asia".

Maybe it's nerves, maybe it's thinking too much about a simple problem.

With coding, perhaps the surprise comes from the fact that a FizzBuzz test would seem like quite a powerful test. If you can't do it, you know you can't do it. There's no doubt that you're not a programmer if you can't solve FizzBuzz and its ilk. So why do people apply, knowing they will be tested? That's the real question.

I guess the answer is you learn where you're at when someone asks you something you can't answer. Sometimes it's not where you thought.

Re: People suck at technical interviews (2014)

#132

Post by joshyeager »

MrLeftHand wrote: post #119
arethuza wrote: post #113

Earlier quoted context omitted.

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?

I don't thinks so. You don't have to use join, but you might end up with loads of queries instead of having just one, but the end result will be the same set of data.

But if you have loads of queries and do the "join" in your application code, you will suffer serious performance problems with any reasonable data set. If a programmer is going to be writing SQL for anything larger than a toy problem, they have to know how to use JOIN.

Re: People suck at technical interviews (2014)

#133

Post by dllthomas »

pjmorris wrote: post #128
MrLeftHand wrote: post #119

Earlier quoted context omitted.

I don't thinks so. You don't have to use join, but you might end up with loads of queries instead of having just one, but the end result will be the same set of data.

Arguably that's one year of SQL experience repeated five times.

Or one week of SQL experience repeated 250 times...

Re: People suck at technical interviews (2014)

#134

Post by PuffinBlue »

oblio wrote: post #116
PuffinBlue wrote: post #100

Earlier quoted context omitted.

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

Can you have a decent, up to date, programming portfolio without investing tons of time in it? Photography is IMO a flawed comparison since it's much easier and less time consuming to have some nice looking photos than it is to set up an equivalent software project. More than that, the photos you took in 2010 are likely to still be relevant in 2016, for the average user. However, for programming, your PHP4 project fr…

> Can you have a decent, up to date, programming portfolio without investing tons of time in it?

Why wouldn't you invest time in it? It's investing in yourself and could get you your next pay rise. It's not wasted time.

We're back to the point I made above about putting the effort in.

> Photography is IMO a flawed comparison since it's much easier and less time consuming to have some nice looking photos

Sure, as I already said it's not a perfect comparison, it's there to illustrate a point.

And I reject your second point very strongly. Even something simple like a single headshot can take hours of planning and setup. Something like a documentary project might take months or even years to complete.

Something like a commercial shoot might take a team of 20 a week to complete and cost hundreds of thousands of dollars - how do you get to put that sort of work in your portfolio? Sometimes you work for free, sometimes you create a whole shoot yourself at great cost. You work for it essentially. That's how.

And a single photo might be no more the 'whole' than a single file might be the 'whole' programme for instance.

Anyway, the exact vagaries of the industry aren't important, it's the assertion that programming is a creative discipline that is important.

> More than that, the photos you took in 2010 are likely to still be relevant in 2016, for the average user. However, for programming, your PHP4 project from 2010 might not cut it in 2016 when you're supposed to join a Scala project.

Possibly, but a portfolio isn't trying to sell a product it's selling 'you'. Stuff that goes in the portfolio shows how you do what you do, gives a window on how you work, how you approach a problem, how you solve it.

Many photographers will create 'behind the scenes' shoots and videos to show how they work and show clients how they solve problems for instance.

These can be independent of the exact example and just because a programming language might change you can still use an older project to show your skill and approach to a particular type of problem.

Anyway, I've laboured the point long enough, feel free to grab the last word but I think I've outlined my point well enough to be understood.

Re: People suck at technical interviews (2014)

#135

Post by kragen »

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…

My first tech job assignment required SQL. I didn't know it, didn't claim I knew it, got the job, read the O'Reilly book on SQL on the plane on my way to California. I learned about joins (although maybe not the JOIN keyword).

This was about the time MySQL came out, and years before Postgres added SQL support, so at the time your rather pathetic argument might have had merit, because there wasn't actually a way to get hands-on experience with SQL without a pricey license for proprietary software.

I still don't think it's reasonable to claim that you have "SQL experience" if you haven't touched joins. That's like saying you have JavaScript experience but don't know how to define a function.

Now, though, Skype and every browser embed SQLite. If you don't know enough SQL to do a join, it's because you lack intellectual curiosity. Don't blame your employer.

When I was hiring people, I wanted people who could do the job, not people who would lie that they could, then blame my company.

Re: People suck at technical interviews (2014)

#136

Post by kragen »

ozim wrote: post #44
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,…

There are also different types of programmers. Some will do well with portfolio like web developers. But how you would approach creating portfolio as embedded dev? When you work on proprietary stuff and github repo does not really show that you do well with hardware, because customer might not have time/knowledge to run this stuff to check if it is actually working.

I think http://rossumblog.com/ is a fairly impressive portfolio of embedded development.

I've only done very small embedded projects, like http://canonical.org/kragen/light_sensing/ and https://github.com/kragen/ar_bytebeat.

Re: People suck at technical interviews (2014)

#137

Post by _asummers »

maxerickson wrote: post #121
_asummers wrote: post #98

Earlier quoted context omitted.

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.

This question would throw me for a loop because I don't have anything I think of as my least favorite language. I could pretend that Python was my favorite language, but that's more that I'm comfortable with it than any sort of actual feeling that I should prefer it over others. That is, I use it out of inertia and familiarity, not out of some sense that I've found something.

See, but that's a reasonable answer. I might take that and pivot to like "if you had to design an ideal language, drawing from the strengths of the ones you've worked with, what would you think most important?". The idea is to get you talking about things you've worked with to show familiarity and critical thought about your tools.

Re: People suck at technical interviews (2014)

#138

Post by ChemicalWarfare »

My fav way of interviewing and being interviewed is a quick assignment (nothing major like some companies want you to build an api, crud UI to drive it and then push it out to heroku for them to look at) - either at home or just leave the candidate alone in the conf room for an hour.

After that if they pass - few questions about their code, maybe drill down into some areas depending on the answers etc.

Alternatively, if someone has a project on their github profile using the tech you're looking for - few questions about that project can typically give you a go/no-go right away.

Re: People suck at technical interviews (2014)

#139

Post by kragen »

mtreis86 wrote: post #122
MrLeftHand wrote: post #54

Earlier quoted context omitted.

Me to supposed mechanic: "Can you fix my car?" Mechanic: "Yes, of course!" - he gets up and collects loads of bits and pieces, metal bars and stuff, then starts to hammer away to create a car part. Me: "What the hell are you doing?" Mechanic: "I'm building the part for your car." Me: "Don't you have a spare or something?" Mechanic: "Well I don't, but there are spares I could order." Me: "Then do it man, order one." M…

What if that shop builds race cars and trophy trucks? Are you okay with the part being replaced being of higher quality and finish than the original? What about some advanced alloy that would not have been financially do-able for a manufacturer to use? When hiring someone with "fabrication skills" into a machine shop, you certainly don't expect them to order a part during the interview when you just asked them to mak…

I'm going to hazard a guess that you don't have any manufacturing experience due to shibboleths: you said "fabrication" but you meant turning, not sheet-metal bending. Did I guess right?

This is a common interview tactic: trying to figure out if someone belongs to a group known to have particular skills by their choice of words or similar.

Re: People suck at technical interviews (2014)

#140

Post by saiya-jin »

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…

> Everyone lies, sorry.

I have an issue with this - i don't lie. Not in CV, not in interviews. We're not managers, we cannot talk our way out of tasks given to us, and most of us who are worth at least a pinch of salt are not desperate to get job X.

But I understand that if your experience is as it is, this is probably correct approach.

Post reply on HN