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

The Terrible Technical Interview

techcrunch.com

Post reply on HN
Print view View original

11–20 of 236 posts

Re: The Terrible Technical Interview

#11

Post by ditonal »

AWolfAtTheDoor wrote: post #9
ditonal wrote: post #4

In my experience, a lot of companies are combining _all_ these things. So you're expected to do a phone interview, a test project/coding test, a whiteboard test, and the management brown-nosing at the end of it where you get to pitch that you've studied a hard technical skill your whole career just because you're so passionate about getting woken up at 3AM on PagerDuty to build _their_ vision, and definitely not beca…

I will express agreement to pretty much all of this. A major issue, though, is one that lingers is referred to in the article: "Now, this does require one huge prerequisite: every candidate must have a side project that they wrote, all by themselves, to serve as their calling card. I don’t think that’s unreasonable. In fact, I think you can very happily filter out anyone who doesn’t have such a calling card. (And les…

Sure. In general, I am not against tough interviews. I just think that if you have elite hiring standards, you better be an elite company making elite offers. But you can't say "we only hire the best of the best!" and then comp negotiation rolls around and you say "well, this is market salary, but since we're a startup....".

I think some of these average companies should recognize themselves for what they are and be more accepting of average candidates. Give some new people in the industry a chance, train some entry-level people, especially if the work you're doing is not really cutting edge tech but just web apps or data analysis stuff that bright but not world-class people can learn with practice.

Also, companies should just focus more on candidate experience. I have interviewed and been rejected by Facebook a few years back. They did expect me to jump through hoops, but in general, they had a few original questions, I felt like they had a great candidate experience with polite recruiters, they put me up in a nice hotel and expensed it instantly, and I knew that if I did get through those hoops they were going to pay me a lot of money. I didn't get it, but I felt fine afterwards. I'm angry at all the average companies that don't do any of that but think they're entitled to put you through the same grinder. My only big criticism of companies like Facebook is they should give more feedback so you feel like you got something to improve upon. Also, I know Zuckerberg campaigns hard for H1Bs, but when Facebook is paying people what they're paying, I assume he genuinely does want to find the world's best and is not just trying to undercut labor. Although most H1Bs are in fact about undercutting labor, and the simple solution is to change it to an auction rather than a lottery and give them more time to look for new jobs before they have to leave. (note, I do not work for Facebook, I interviewed there once and got rejected but had a massively more positive experience with them than most companies. Google is also an excellent company to interview for, I'm sure there are some others but not many).

Re: The Terrible Technical Interview

#12

Post by philbo »

StevePerkins wrote: post #6

I do almost all of the technical phone screens for my company. The process starts with a "where-do-you-see-yourself-in-5-years" personality screen, with an H.R. drone or outside recruiter. It moves on me, and then on to a brief "homework" coding exercise that we ask people to write and submit. If we like their code sample, then they come in for the panel of "whiteboard-exercise" people who conduct the face to face ro…

Although I believe everything you say, I'd like to provide a counterpoint.

I think I'm a pretty good programmer and I've got a reasonable body of work on GitHub to back it up, but I've often failed technical interviews because I go to pieces under the pressure and my brain just stops working. I've been a dev for > 15 years but if anything I've got worse at interviewing over time. I only apply for positions that I genuinely think I'd be good at, but the technical interview gives the impression that I'm a clueless idiot. From my (admittedly selfish) point of view, the approach proposed in the article seems much better than the process you describe here.

Re: The Terrible Technical Interview

#13

Post by pandaman »

Almost everywhere I went on interviews the questions were about the very basic things. The things you'd knew if you did what you claimed you did on your resume. E.g. if you are a 3d graphics programmer with 10 years of experience you know what cross product is. If you had been shipping multiple 1M+ LOC projects in C++ you know what the word "virtual" mean and other popular syntax as well.

The places that asked me things I did not know probably had been looking for somebody with different experience than I had so it's fine with me too, even though it would be better if they evaluated my experience from my resume.

So I don't see the author's problem. If the questions on the interview are too hard - you are probably applying at above your level or in the wrong field. I will most definitely not spend my time working on some programming test or do some side project for "show-and-tell" to please you.

Heck, he is appealing to other professions allegedly not doing interviews, yet it's even harder to imagine them doing things he suggests. What kind of side project a doctor will have? A civil engineer? A manager? A pilot? A chef? A lawyer?

Re: The Terrible Technical Interview

#14

Post by jaredmcdonald »

> It is time for engineers–especially excellent engineers for whom demand is high–to start to flatly refuse to do whiteboard interviews.

This might be a viable strategy for people who have a well-established career/credentials/references (etc), but for junior-level candidates still trying to prove themselves (such as myself) I can't see this working out too well.

Re: The Terrible Technical Interview

#15

Post by parennoob »

StevePerkins wrote: post #6

I do almost all of the technical phone screens for my company. The process starts with a "where-do-you-see-yourself-in-5-years" personality screen, with an H.R. drone or outside recruiter. It moves on me, and then on to a brief "homework" coding exercise that we ask people to write and submit. If we like their code sample, then they come in for the panel of "whiteboard-exercise" people who conduct the face to face ro…

As a self-taught person beginning to write software who is not in SF, your description of someone who cannot explain the advantages of the MVC pattern makes me incredibly nervous. I don't really know the MVC pattern in detail, or what its advantages are. I do know about Big O complexity, data structures, loops, registers, as well as logic gates, and the basic structure of computer processors. I can code small programs in Python and Java, and have written some basic Flask apps.

Am I totally unfit for developing software?

If not, What is the correct answer that will prevent me from getting COMPLETELY EXPOSED (in your words) if you ask me this MVC question in an interview?

Re: The Terrible Technical Interview

#16

Post by steveax »

RogerL wrote: post #3
nperez wrote: post #2

If your only goal is to measure the ability to code, then doing a whiteboard interview isn't the best way to do that IMO. But what about positions where you will be expected to give presentations, do pair-programming, or mentor junior developers? I think whiteboard interviews can be a measure of your ability to take technical concepts and illustrate/explain them clearly to a team. I used to really hate whiteboards, b…

If you want to measure giving a public presentation....have them give a public presentation. If you want to measure their ability to pair program ... pair program with them. If you want to measure their ability to mentor ... have them teach you something they know. I want to know how you do X, and measuring X is easy, so please do Y as a proxy is never a good approach. I have never, in my 25+ year career, ever had to…

If you're whiteboarding with a simple pass/fail mentality, I'd say you're doing it wrong. A good whiteboarding exercise lets you see how a candidate explores a problem. Do they ask insightful questions? How do they break a problem down? Do they bluff when faced with something they don't know?

These are behavioral attributes that are important - much more important than a simple binary test.

Re: The Terrible Technical Interview

#17

Post by foz »

In my organization, we start by looking at what the candidate has actually done. We ask for a github profile, and any side projects they might have worked on. If the CV and body of work look interesting, we go on to a phone screen - general questions, clarifying points on the CV, explaining the job, answering questions.

For the on-site interview, we ask candidates to bring their laptop. We advise them to use a typical, comfortable development environment. We've seen candidates struggle with the latest Ubuntu, installed that morning to impress us. So we don't want that.

During the hands-on interviews, we ask to see a side project, or any code they are mostly responsible for, and familiar with. We ask them to explain code, maybe change something, refactor a test, etc.

What we don't tell candidates is that this part of the interview is also about how they use their tools. It's important to see how good they are with their editor, command-line tools, can they type well, do they get easily distracted, and so on.

One of the most effective interviews we do is for project planning. A problem is explained in detail and the candidate is asked to design a solution. Not in code, but to talk it through in detail, drawing or writing docs/stories if needed. This phase helps show us how they break down a project, ask questions, negotiate features, and look for opportunities to reduce complexity. Bonus points for making a pen-and-paper wireframe or throwaway prototype.

What we refuse to do is the "puzzle" problems, whiteboard code (which makes no sense), or tricky technical questions. We instead want to find people that use best practices, don't re-invent the wheel, tackle problems pragmatically, and are good with their tools.

Over time, this approach seems to work well. However, we also discovered that we have to re-train and test our own interviewers. Without that step, the process can change unexpectedly, become inconsistent, or unfair. Don't just assume your staff is interviewing well - take time to check it out and help them get better.

Re: The Terrible Technical Interview

#18

Post by ditonal »

StevePerkins wrote: post #6

I do almost all of the technical phone screens for my company. The process starts with a "where-do-you-see-yourself-in-5-years" personality screen, with an H.R. drone or outside recruiter. It moves on me, and then on to a brief "homework" coding exercise that we ask people to write and submit. If we like their code sample, then they come in for the panel of "whiteboard-exercise" people who conduct the face to face ro…

Strongly but respectfully disagree, see my comment which is sitting at the bottom because it ruffled some feathers.

Re: The Terrible Technical Interview

#19

Post by imsofuture »

RogerL wrote: post #3
nperez wrote: post #2

If your only goal is to measure the ability to code, then doing a whiteboard interview isn't the best way to do that IMO. But what about positions where you will be expected to give presentations, do pair-programming, or mentor junior developers? I think whiteboard interviews can be a measure of your ability to take technical concepts and illustrate/explain them clearly to a team. I used to really hate whiteboards, b…

If you want to measure giving a public presentation....have them give a public presentation. If you want to measure their ability to pair program ... pair program with them. If you want to measure their ability to mentor ... have them teach you something they know. I want to know how you do X, and measuring X is easy, so please do Y as a proxy is never a good approach. I have never, in my 25+ year career, ever had to…

You're right, I've never whiteboarded a problem where the other person knows the answer. A thousand times have I sat down in front of a whiteboard with coworkers looking to solve a problem. That's how I interview too.

Re: The Terrible Technical Interview

#20

Post by StevePerkins »

parennoob wrote: post #15
StevePerkins wrote: post #6

I do almost all of the technical phone screens for my company. The process starts with a "where-do-you-see-yourself-in-5-years" personality screen, with an H.R. drone or outside recruiter. It moves on me, and then on to a brief "homework" coding exercise that we ask people to write and submit. If we like their code sample, then they come in for the panel of "whiteboard-exercise" people who conduct the face to face ro…

As a self-taught person beginning to write software who is not in SF, your description of someone who cannot explain the advantages of the MVC pattern makes me incredibly nervous. I don't really know the MVC pattern in detail, or what its advantages are. I do know about Big O complexity, data structures, loops, registers, as well as logic gates, and the basic structure of computer processors. I can code small program…

As a complete beginner? No, I wouldn't call you totally unfit for developing software. I'd call you entry-level, but that's totally okay (as long as your applying for entry-level jobs and have realistic salary expectations). I didn't specify this in my comment above, but I've never really had to interview for entry-level req's. The positions that I described involved candidates with years of experience... so the fact that THEY don't have a clue about the basic design of virtually every web framework for the past two decades (i.e. MVC) is a glaring red flag.

To be honest, I'm not entirely sure that the MVC example would be a good question to ask to a younger candidate. If you had been around during the early days of web development (i.e. CGI scripts based on Perl or raw PHP, or Java where all of your logic is crammed into a JSP page), then you could say all sorts of things about the shift toward MVC being the norm. However, if you came along after that shift, and every web framework you've ever seen has been some variation on MVC principles, then it's a bit like asking a fish to describe water.

Anyway, if you're just getting started in the field, and haven't had much interview experience yet, then try not to let it get to you. Interviewing involves a TON of rejection, and that never really stops. If interviews ever start feeling easy, then it means you're selling yourself short... and you should be interviewing for more senior positions with higher salaries.

To get started though, I would suggest simply doing a Google search on "programmer interview questions", or something more specific to your background (e.g. "java interview questions"). This is exactly what the majority of your lazy interviewers are doing to come up with their questions anyway. As you encounter questions that you can't answer, then look them up and read about it (e.g. http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93cont...).

Post reply on HN