Ask HN: How do you pass the technical interview? | Hacker News Reader

Ask HN: How do you pass the technical interview?

4 pointsdiminium10 comments

I like looking at things tick from the inside. I like keeping up to date about the field. I like making things work. I still get stumped by the technical interview. I usually fail miserably. The interviewer usually ends up saying something like "If you don't get this simple thing, I don't believe you'll understand anything more complex."

I'm not really sure what more I can do. I just don't have the brainpower to keep everything in my brain at once. It's so bad that I don't even remember how my old programs work even though I'm pretty sure I'm the one who wrote it.

Does anyone have any advice?

View on HN

Depends on why you're failing. If you're misreading the people in the room, try this Rands article: http://www.randsinrepose.com/archives/2007/09/25/the_button....

But I wonder if it's not something else. The way you describe what you "like" is interesting, and then you write:

> It's so bad that I don't even remember how my old programs work even though I'm pretty sure I'm the one who wrote it.

Did you write your old programs?

I don't mean, did you assemble them, or did you get them working, or did you construct them. I mean, did you write them?

There is so much code out there today that it's hard to write a program without some personal discipline. It's very straightforward to find two or three things that are similar to what you want, and copy and paste one bit here and two bits there and make things fit and have a working program that does something.

But, copy-and-paste, or batteries-included, however you look at it, that's a different skill set than thinking through a problem critically and logically and algorithmically and writing a solution from scratch, and that's a different skill set than doing it in a preferred language in an idiomatic style without looking anything up, and that's a different skill set than doing it on a team with people other than you who have to understand it and deploy it in production and maintain it.

The last company I worked for, technical interviews were to determine three things:

1. Are you lying to us? Do you actually know all the things on your resume? We had a genuine 8, maybe even a 9, in JavaScript in-house, if you said you were an 8 or a 9, oh, man, you really got a grilling, and most people couldn't keep up. We had people that good in various subjects. Most people are 5s or 6es.

2. Where are your limits? Everyone has them. I'm a 7 in interaction design, say. I've been doing it for seven years. I know many of the things I'm not good at, but I also know how to correct for them. It's hard to throw me a curveball, but, strictly speaking, I also don't think I'll ever progress past a 7, because if I'm staying on top of my game, there's always something I won't know that I am also actively pursuing. We would press the interview until the person admitted they didn't know and explained how they'd figure it out, or they'd keep bullshitting us and they'd fail.

3. Where do you go deep? When hiring for our Java and Oracle developers and DBAs, we needed people who had gone deep into Java and Oracle stuff. Not, "I'm a good programmer because I have critical thinking and logic skills, and I'll look stuff up in the reference manual when I need to remember a function name," but "I've been working exclusively with Java or Oracle or whatever for ten years and I know function names and weird edge case bugs by heart and I wrote that book you have on your desk." When I was a developer, I was like that with semantic HTML and cross-browser issues, but I couldn't do that today. If you're a generalist and you're interviewing for a specialist role, we'd weed you out pretty quick.

If you're a generalist, and you're getting stumped, maybe it's because you're applying for specialist roles. Maybe your resume is a little over-confident and you talk a good game on the phone, which is why they're not weeding you out sooner. If that's the case, try vetting the jobs you're applying for better, rather than trying to game the interviews, too.

Could you be more specific about why you get stumped ? - is it that you don't remember APIs, syntax, etc. or is it that you stuggle with breaking down the problem and working out the logical flow of the code, or is it something else ?

Maybe if you gave some examples of questions that stumped you and the point at which you got stuck it would help us understand exactly what your issue it.

Here's one. "What is polymorphism?" Things go downhill after that. I know I'm going to be listening to a long lecture.

Are you self-taught? I'm pretty sure that's a pretty basic CS term. To not know it means you're going to have problems communicating.

This goes back to my original comment. You probably know what polymorphism is. You've probably used code that did it. You've probably written original code that exhibits it. And if someone explained it to you, you'd probably be like, oh, right, yeah, that thing, I did something like that over here in this code somewhere.

But, we have special words for things for a reason. Jargon increases the accuracy and efficiency of communication between specialists. You don't have to spend five minutes explaining the semantics of message passing, you can just say it's polymorphic.

Being able to write code for use by a team, and being able to communicate the value of that code, and the structure of that code, to that team, is a skill set completely separate from being able to cobble something together yourself.

This is what I mean by a long lecture :(

"Jargon increases the accuracy and efficiency of communication between specialists." I think this statement is too broad. This really depends if we're on the same page (i.e. think Java and Javascript). We could end up having a long conversation about something and end up with two ends if we're not careful.

If we've been doing the same thing and working together for many months on end, then I would say yes, jargon works as an efficient means of communication. If we've never met each other and you and me have 20 minutes (realistically 15) before the next interviewer takes me - then we're going to have a problem.

Maybe it's not that you're failing the technical part of the interview, but the cultural and interpersonal parts.

In your cited scenario, it's up to you to ask, "do you mean it generally, at the computer science, theoretical level, or specifically in language X, Y or Z?"

There's nothing wrong with asking for clarification. There's no game to win. There's just basic, professional, communication skills.

Talking and interviewing are skills. They are skills you can learn and practice. Getting defensive when someone is trying to help you is not going to help you.

You will be communicating in many, many different scenarios and with many, many different people who are at different levels of technical knowledge and interpersonal engagement, for the rest of your natural life. Being able to do so well is the most important skill in your professional existence. That's the whole thing. There isn't anything else if you don't have that.

Working on a team is very different from working alone specifically because there are other people involved. The social aspects of a professional relationship outweigh the technical ones by tonnes.

Pick up a copy of the book "Programming Interviews Exposed", it'll give you a good guide to the standard topics covered in programming interviews. Revise those and you'll do much better.

I know how you feel. I think it's kind of a combinations of things. I can MAKE things. I can do it quickly and make pretty cool products. Unfortunately, I do a lot of it by searching online. Even if I'm writing my own code and not copying from other sources, it's kind of in one ear and out the other. I used a PHP function yesterday to remove HTML entities. I'm sure its something like stripHtmlEntities or something (ah, it's "html_entity_decode"). That's exactly my point though... I needed to use it ONCE for some side project. Should I have that on my interview tomorrow, I would fuck it up, even though I know exactly how and when to use it.

Anyhow, I relate it to GPS in the car. I can drive somewhere 10 times following my GPS and not be able to get there the 11th time without it. However, if I wing it once and figure it out myself then I always remember it. The internet is that kind of safety net that stops me from retaining the information.

I have this weird issue with job interviews. It really, really weird because I get very nervous. My mind goes blank, and I can't even write FizzBuzz. Now, if I'm interviewing for a freelance contract, then I'm a Super Programmer, answerer[1] of all tough questions. I answer the most complex questions with ease, and write code on the spot without problems. Strange.

I got the "If you don't get this simple thing, I don't believe you'll understand anything more complex." line once. Turns out, I'm now building the platform that company will use to sell their products. Ha!

[1]Not a real word.

The technical interview is not a quiz that you should pass with some tricks. Because than you might find you will have a job you can't do. Practice your memory if you can't remember things but usually questions in interviews are not something you must remember but you should solve with reasoning and obviously skills.

Reply on news.ycombinator.com