

Things you should know when interviewing for a programming job - amyshelton
http://www.crossbrowser.net/479/things-you-should-know-when-interviewing-for-a-programming-job/

======
icey
One of the best metrics I've found for determining the overall satisfaction
level of a department is turnover rate.

If you ask the interviewer about their turnover rate and they hedge, be
cautious. Sometimes they won't know what the turnover rate is because they're
too new, or don't pay attention to it, so you can ask about the average number
of years that the developers have been there (which they should know).

There are so many factors that figure in to developer happiness that it's hard
to build a good checklist of things to ask about. But if you look at the
evidence (how long do developers stay here?), it's very easy to tell if it's
going to be a good place to work.

Of course, this doesn't work when you're talking about getting a job at a
startup, but the hope there would be that you already know it's somewhere you
want to work; that it's not a job that someone referred you to just because
you need a job.

~~~
BadassFractal
I personally do not feel that question will help you too much. You will be
stuck within a team, say 5-10 people reporting to someone, and that is the
environment you truly care about, and it's something the recruiter will not
know much about. Those are the people you'll be sharing most of your time with
for years and it's truly the one area you have to get right. The satisfaction
level within the department is strongly secondary to that.

~~~
rpwilcox
Right, but if there's high turnover there's got to be an underlaying cause.
(Which maybe the business itself doesn't know).

Maybe they don't pay enough, or have too many deathmarch projects, or office
politics gets in the way too often, or maybe a few rounds of layoffs

Regardless, if a lot of people have left before you, there might be a reason
for that, or at least it will have a factor in your environment there.
(Example: A recent round of layoffs might mean a 3 person department is asked
to do the work once handled by a department of 10)

~~~
BadassFractal
All fair points!

What is the incentive of the recruiter to tell you the truth? What if he says:
"Everthing's great!!!", you can't really hold him accountable after you signed
up for the job. They're salesmen. Is the idea to look for subtle indications
of not everything being great?

~~~
cpeterso
Recruiters are salesmen, But the OP suggested asking the interviewer.
Developer interviews often have multiple rounds with different interviewers,
so you get a chance to ask the same question to multiple people. If their
answers don't match, beware! :)

------
Troll_Whisperer
This is absolutely wonderful timing for this thread to come up. I've recently
started at a start-up in Beijing and have been put in charge of making a
filtering system for technical applicants.

One thing I was never prepared for was the sheer number of people who just
_lie_ on their CVs! After somewhat reluctantly starting to ask senior app
developer and web developer applicants to write a fizzbuzz program, I was
shocked to see that less than half could. This is from a group of people who
claimed to be _experts_.

Since that discovery a couple of weeks ago, I've been building an automated
grading system similar to the great FB's old puzzlemaster app. That way I can
screen out those who can't do fizzbuzz and another trivial program or two
before wasting our one iPhone dev's time interviewing them.

Those who do at least decently do get a chance to interview, but I'm hoping to
add more puzzles to the auto-grader in the hopes of spotting applicants with
stronger skills than is clear from their interviews. Any suggestions?

~~~
agentultra
<http://codility.com>

And many, many more.

~~~
Troll_Whisperer
I'm sorry, maybe my comment was unclear. _I'm_ writing the tests. I was
looking for suggestions for programming questions (i.e. is giving them a
problem that requires implementing a binary search or a graph useful?).

That link is useless to me since the site is in English and nearly all my
applicants are Chinese who don't have the language skills to read it. Throwing
200 weak applicants at it would just be a waste of $600USD/month.

~~~
Natsu
It's not that hard to come up with programming questions. It's harder to come
up with relevant ones. What sort of algorithms do your devs actually use?

Do you need to know if they can write parameterized queries in SQL? Do you
need to know if they can do simple web crawling or scraping? String
manipulation? Or do they need to know how to do linked lists, hashes and
binary searches?

I think you'd do better if, rather than making them redo old CS assignments,
you focused on job-relevant tests.

~~~
chc
Do better at _what_? The kind of test we're talking about here is just a bozo
filter. It's designed to keep out the flagrantly awful candidates who can't
even write a simple program, not to test for actual job suitability.

~~~
Natsu
The original test is like that, but I don't think that's the question GGP was
asking.

------
agentultra
It also doesn't hurt to simply practice programming problems and revisit old
academic excercises.

Make some flash cards with datastructures on them and use them to try and
recall as many of their useful properties as you can (eg: Binary Heap, binary
tree with x constraints, O(n) search, O(log n) insert in worst case; etc).

The advice in the article about honestly answering, "I don't know," is key --
don't pretend to know. You'll get called out and blow the interview. Instead,
explain what you do know and think out loud when you walk through the problem
with them (or how you'd go about solving it).

One way I've practiced "thinking out loud" is to get a white board and pretend
you're a professor. Try to explain the solution to some problem you are
familiar with in layman's terms to your pretend audience -- but do it out
loud. Then find a problem online that you're not familiar with and do the same
thing. Pretend you're a professor or engineer or some sort of brilliant person
and walk through the problem with yourself -- out loud. Write diagrams on the
board, explain your every step to your pretend audience, and really get into
it. I found it helped me quite a bit and I frequently use the technique to
walk through problems I'm not familiar with in my own studies.

~~~
jasonlotito
> One way I've practiced "thinking out loud" is to get a white board and
> pretend you're a professor.

This.

I'd never done "whiteboard testing," and I still hate it, but a lot of people
use it apparently. I remember the first time having to do it, and I was so
focused on the white board, and having my back turned to the interviewer, and
just the odd sensation of everything (not to mention very little sleep the
night before) that I was drawing blanks on the most basic of questions.

~~~
lutorm
I guess here's one advantage of trying to get a job coming out of academia: We
do that kind of whiteboard discussions all the time. I'm actually surprised
that you wouldn't have done this ever at a normal job either. I mean, how do
you hash things out with your coworkers?

~~~
jasonlotito
There is a big difference between hashing things out with coworkers and trying
to write that will run without a typo. I have no problem using a white board,
and throwing up examples, etc. But actually writing out variable declarations,
assignments, etc?

------
synnik
Also, be aware that it is OK to bomb an interview. The point of interviewing
is to find a match. If you and the company do not have a cultural fit, it is
better to find out and both go your own ways. So I recommend above all to
simply be yourself.

------
GotToStartup
I don't know man, the interviewing process is just so broken. Maybe because
interviewing in general is so broken or maybe it's because software
development is such a new industry.

Either way, isn't it strange that the best advice for doing well at
interviewing is to practice. Practice so you become better at interviewing,
not necessarily better at your job.

~~~
droz
I think it's a byproduct of the education system. When you are young, you are
taught to do well on exams instead of having a deep understanding of the
material.

------
benjoffe
> Also, when they do ask you about how much money you want, give them a range
> or a baseline (ex: I had X at my previous job, so I expect at least X or
> from my research people doing this job receive between Y and Z, so I’d
> expect something in that range). Let them come up with a number.

I don't understand this advice, if I say I expect 'at least X', then it's me
coming up with the number, not them. I have always just said I'll comment on
what is offered.

~~~
ulf
Furthermore, if you say "at least X", then guess what: their offer will be "X"

~~~
icey
I have given people more than they've asked for a couple of times (usually if
they've asked for something that I know to be under market rate and I don't
want them jumping ship in a year). But yeah... as a hiring manager I want to
know what your expectation is because that's what I'm going to take into
consideration when I compare you against other people I've interviewed.

i.e. Dev A has everything but costs 20% more than Dev B, who I think can pick
up everything we need within a year's time. Or, Dev C has claimed to have done
all of these different things, but is asking for an amount that is
suspiciously low.

------
sedev
Interviewers who explicitly phrase the 'how would you move Mt. Fuji' or
'here's a development task outside of your stated competencies, how would you
do it?' as hypotheticals or thought exercises, could save a lot of heartbreak.
I can see the rationale behind those questions, but any experienced
interviewer should know how tense people get during an interview: allowing
interviewees to perceive those questions as being about the literal answer,
rather than about the process, is kind of a jerkface thing to do. Besides,
people who can't coherently explain their thought processes are going to bomb
on that question anyhow - have some courtesy and give a leg up to people who
are merely nervous. I'm grateful to the interviewers I've had in the past who
have come out and said "this question is about the process, not about the
result".

I think it's very important to reduce the tension level, because if you're
asking someone a question intended to show _how_ they think and reason,
especially with some level of creativity, you risk getting a useless answer if
they're tense and antsy. Nervousness and pressure often kill creative
thinking: this is well-established.

------
BadassFractal
Or interview at companies that aren't software giants that will actually spend
time getting to know you and your past work rather than processing thousands
of developers each year through standardized programming tests that do not
prove anything about your capabilities as a software engineer.

------
virmundi
I'm going to an interview this week. One thing I think that's missing in
topics like this is that you are going to work for a company. This means that
you need to look beyond the immediate position and take a large view to the
business. I'm going to ask questions like "Why did your last custom stop using
your product", "What is the company's vision for the next 3-5 years", "What
are your revenue streams and how stable are they".

Knowing what dev process they use, tools, etc are all really good questions.
But don't forget that the money they pay your salary with comes from
somewhere. Knowing this internal information is just as important as knowing
how Git works.

------
ice5nake
The bottom line, in the interview process you need to adapt to the people you
are talking to.

The possible pitfalls are endless for both the interviewer and the
interviewee.

And sometimes the interviewer will bomb the interview more than you. You don't
see people often write about making sure the person doing the interview is any
good at it.

Getting good people is really important. Possibly one of the most important
things you can do for a business.

------
known
I've never come across an _interviewer_ who is formally _trained_ to do the
interview.

------
peacemaker
With some of those "un-answerable" questions that come up in interviews I've
had good mileage from just turning them around back on the interviewer. After
all, a lot of the time these interviewers just ask the question because it's
part of the "process" or something without fully understanding the question
themselves. However, you have to read the situation well in order to get away
with this!

------
cpeterso
People are on their best behavior with they are being interviewed. My manager
suggested that if you notice any rude or peculiar behavior during the
interview, multiply it 100x and consider whether you would want to work with
_that_ person one year from now. I've interviewed people who would arrogant or
would talk over the interviewer. Needless to say, those hires did not work
out. <:)

------
singingwolfboy
Is it worth asking about the programming environment if you're already in the
office and can see evidence of it all around you?

~~~
amyshelton
I guess that depends on your powers of observation. But even if you trust in
your powers of observation, it is an excellent opportunity to compare what you
observe with what they say. If things don't mesh, you have to wonder.

~~~
jerryr
Agreed. And remember you're only seeing a little snapshot in time, so there
are probably quite a few questions you could ask regardless of your
observational powers.

Do you eat lunch together? Is dress always this casual? How often do you
refresh your equipment? How often do people work in groups vs solo? Do you
encourage working in pairs? How geographically distributed are project teams,
typically? Do people take personal calls at their desks? How do you manage
shared resources like conference rooms? At my last job, everyone stood up and
belted show tunes for a 1/2 hour at tea--do you have such a program?

------
brown9-2
This advice seems like it would be applicable for an interview for _any_ type
of job.

