Live data from Hacker News

People suck at technical interviews (2014)

seldo.com

51–60 of 315 posts

Re: People suck at technical interviews (2014)

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

>> 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 are notorious cases where senior engineers with years of actual honest coding experience "fail" fizzbuzz. IMO, That happens in two ways: 1) Not knowing (forgotten?) what a modulus operator is, and trying to code one up from scratch with a for loop. This…

#2 happened to me: I wrote the straightforward implementation in a few seconds, and then struggled and tied myself up trying to eliminate the duplication, making it worse and worse, until I started panicking. Luckily the interviewer understood what was happening and changed subject.

Re: People suck at technical interviews (2014)

#52
post #24

Earlier quoted context omitted.

Please read my most recent two blog entries on http://www.voxelquest.com where I talk about the current state of things. :) I have pinged my network, and am very grateful for all the job offers that have come of it. However, at least half those offers have come with technical interviews that basically ignore my work experience, or in one case the recruiter could not even determine why my experience was relevant (even…

It speaks for broken hiring when even skillers like you can't get a job. I always thought I just wasn't as good as I think when I didn't get a job, but I know your work and it is amazing, so hiring companies just don't know what they doing anymore

Hiring right now is a shitshow of old wives' tales, cargo-culted practices from big name tech companies, shady recruiters, mismatched incentives, interviewers who have no experience or training in interviewing, gimmicky apps trying to somehow gamify technical interviewing and endless whining back and forth on HN and Medium.

I'm sure a lot of developers who are currently employed are put off applying elsewhere because the whole process has become so demanding and unpleasant and disrespectful.

One company I applied to for example asked to do a take-home test, maybe 2 hours. I did the test, only to be told it was the first stage of a long and gruelling process involving a further 8 hour take-home project (unpaid, of course) followed my several rounds of technical and non-technical interviews. I immediately withdrew my application. When would I have the time to do 8 hours - it was timed for some bizarre reason, so it had to be done in a single block of time - on a project? Maybe for my own projects, sure, but that's my spare time.

Interviewers and recruiters are, after all, being paid to sit there, while interviewees are - unless they're unemployed - taking precious time off to travel, maybe stay overnight in a hotel, sit through hours of gruelling interviews and tests, all for a job that may or may not offer anything much better than what they've already got. And yet the penny hasn't yet dropped that maybe your shitty process is the reason you haven't found anyone yet?

I'm not sure what the solution is, but I'm convinced that it wasn't this bad 5 or 10 years ago - maybe if you were interviewing at Google or Microsoft, but not if you were applying for a bog standard dev role at a startup or SME.

Re: People suck at technical interviews (2014)

#53

Earlier quoted context omitted.

Did you actually think they wanted a roman-numeral converter? It should be obvious that the roman-numeral converter was a proxy to see how well you could reason through solving a programming problem. Surely you knew that was what they were after. That you seem incredulous that they didn't accept your clearly low-utility response is baffling. Now, if you were signalling to them that googling a solution is the extent o…

A solution is a solution. Proving that you can search for a solution and use it is a positive thing. There are loads of people who can't do even that. It wasn't like copy-paste. You still have to understand how to write the code that uses the API, you still have to get the input from the console and write the output to it. And if I follow your trail of thought, then I hope you're not using stackoverflow when you do y…

Me to supposed mechanic: "Can you repair my car?"

Mechanic: gets out the yellow pages and calls a real mechanic.

Me: ok I'll hire that guy you just called

They're not hiring someone to search. They're hiring someone to code. You proved you could search but not that you could code

Re: People suck at technical interviews (2014)

#54

Earlier quoted context omitted.

A solution is a solution. Proving that you can search for a solution and use it is a positive thing. There are loads of people who can't do even that. It wasn't like copy-paste. You still have to understand how to write the code that uses the API, you still have to get the input from the console and write the output to it. And if I follow your trail of thought, then I hope you're not using stackoverflow when you do y…

Me to supposed mechanic: "Can you repair my car?" Mechanic: gets out the yellow pages and calls a real mechanic. Me: ok I'll hire that guy you just called They're not hiring someone to search. They're hiring someone to code. You proved you could search but not that you could code

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."

Mechanic: "Nah, I like to build everything by myself."

Anyway, using an API doesn't mean you don't have to code.

I was wrong, I learned, next time will be different.

Re: People suck at technical interviews (2014)

#55

Earlier quoted context omitted.

You really didn't know what they wanted? You think they wanted you to find a library that did it?

He's a developer, not a telepath. In tests like this you make it clear what's allowed - "use the standard library, no external dependencies" etc. Because in a normal working situation, his solution is perfectly valid. If I were interviewing him it certainly wouldn't be a dealbreaker. I'd probably want to discuss more about pros and cons of in-house vs using libraries, because you tend to find out more about the skill…

In an interview you are trying to show that you understand the problem. Not just get the right answer.

Re: People suck at technical interviews (2014)

#56
post #44

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.

A portfolio isn't something you just have and it does all the work for you. It's a living and evolving thing that is there to show that you can solve problems.

A portfolio says "I encountered X problem and here's what I did about it to make this other thing and therefore solved X problem."

A web dev is a very easy job to create a portfolio for because the product can be your portfolio but when I say 'portfolio' I'm not talking about a GitHub repo of some code you've written, I'm talking about something bigger than that.

I'm talking about having examples of your code, things you've made, perhaps technical writing, perhaps a personal project, perhaps video or other 'evidence' of the programmers work/approach. If that involves making a personal embedded hardware project to show your approach then that's what's needed.

Perhaps another important attitude change needs to be established...

In a creative technical art you are not really selling your 'product' to customers. You are selling yourself. You're selling your ability to solve problems and it's incumbent on the individual to prove their ability. Web devs aren't 'selling' their previously created websites, they're 'selling' their ability to create those past projects.

It's a crucial distinction and programmers would do well to adopt this distinction - they're not 'selling' their GitHub repo for instance, they're using that as an example of how they (their mind?) work to solve problems.

For sure there will be times you work on proprietary/secret stuff or on systems of such scale you can't possibly make an equivalent scale of personal project.

But you can demonstrate your ability and sell yourself, and that's really the key to it all. You have to get to the point in a creative career where you realise you aren't just selling your final product, you're selling yourself, your approach and your way of solving a problem.

Finding a way to do that is how you get the job ahead of someone else.

Re: People suck at technical interviews (2014)

#57

Earlier quoted context omitted.

If they had a killer hook, yes. An editor can always review and fix the grammar. :) A coding analogy: A compiler or debugger can catch bugs. If they can't form a competent sentence, they probably would fail to write a convincing hook. But some margin of error is acceptable.

Is the "technical" part really analogous to grammar? I don't think many interviewers care about that. They don't care about missed semi-colons. They want to see that you know how to solve a problem. And a github portfolio is not going to give them that. As an aside, I think debugging is hard even with a debugger.

I disagree. A github portfolio combined with time spent via screenshare reviewing and discussing some of that work is far superior to a technical quiz IMHO.

Re: People suck at technical interviews (2014)

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

Wow. I used to know Haseeb during his poker days 8-10 years ago, when he was still playing for dimes/quarters and we were all still using MSN. Can't believe I'm hearing his name again in this context, I had no idea he got into software.

He's probably a bad example to make your point with. Haseeb had some moral failings, but he is truly on another level in terms of intellect/drive/vision, and the interviewers at Airbnb probably didn't have a hard time recognizing that.

I can't stress enough how smart that guy is. He leaves an impression.

Re: People suck at technical interviews (2014)

#59

Earlier quoted context omitted.

If they had a killer hook, yes. An editor can always review and fix the grammar. :) A coding analogy: A compiler or debugger can catch bugs. If they can't form a competent sentence, they probably would fail to write a convincing hook. But some margin of error is acceptable.

Is the "technical" part really analogous to grammar? I don't think many interviewers care about that. They don't care about missed semi-colons. They want to see that you know how to solve a problem. And a github portfolio is not going to give them that. As an aside, I think debugging is hard even with a debugger.

Thats true, probably a poor analogy, but the overall point is that:

Determining a programmer's worth probably takes at least a month in my experience. Maybe even two months. I almost got fired within the first month of my first job, but quickly ramped up and turned around to be the highest value-adding employee by virtue of completing the highest paying contracts at a fast pace (the company was later acquired).

Most companies can't spend a month, but a day long take-home test is a great alternative.

There are so many facets to a programmer's worth, and so many ways to miss them or ask the wrong questions, that I just don't believe in short, high-pressure interviews. Take home tests have been highly successful in my experience (and a few others, from what I have heard).

Re: People suck at technical interviews (2014)

#60
> Don't hire for a fancy degree.

There are some companied coming to my college for hiring. The first criteria they put was 70% aggregate marks (60% for some companies).

I have seen people who doesn’t know how to write even a small program getting hired, while people with good programming skills are not even eligible to attend the interview.

Going through 200-300 candidates in an interview might be a tedious job, I am not sure. What other choice do they have?

Post reply on HN