

Ask HN: How do you pass the technical interview? - diminium

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."<p>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.<p>Does anyone have any advice?
======
vitovito
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....](http://www.randsinrepose.com/archives/2007/09/25/the_button.html)

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.

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

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

~~~
vitovito
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.

~~~
diminium
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.

~~~
vitovito
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.

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

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

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

