
Technical Interviews at a Startup - tomblomfield
http://tomblomfield.com/post/15459124407/technical-interviews
======
revorad
I interviewed with Tom's startup last week. I was impressed by the business
logic questions. If you're looking for a job in London, you should apply
there. They are a great bunch of hackers working on very interesting stuff.

------
jt2190
Part of me always balks when a company recommends using GitHub to share code
with them. Don't get me wrong, I love GitHub, but posting code using a GitHub
free account means you must also open source it. Or perhaps the project you
contributed to doesn't host their source with GitHub.

I'd prefer it if they'd just say, "send us a sample of your work, or a link to
your source online."

~~~
xxqs
if the software is non-open-source, sending a sample may violate NDA and
licensing.

in regards to Github, if Git is used already in the company's development
process, the candidate would need to show that he or she is familiar with Git.
Then Github is the first destination to show that. On the other hand, of
course there are plenty of other Git hosting opportunities -- sourceforge, for
example.

~~~
pault
Don't forget bitbucket. They allow unlimited free private repos (limited by
space and users).

~~~
xxqs
thanks for pointing to bitbucket, I didn't know they offer private repos for
free.

at the moment I rent a minimalist VPS for about $35 a year and use gitolite to
organise my private repos. Works perfectly so far :)

------
therandomguy
Good post. Personally I would refuse to share my past code. Honest question:
Would you be willing to share your code with the interviewee so that try can
determine if they want to join you?

~~~
tomblomfield
We'd absolutely be happy to share (parts) our code, and often do.

I've heard other companies give prospective employees a week-long project on a
consultancy basis - I think this is a great method of determining if there's a
mutual fit. Unfortunately, it's a bit unrealistic to expect most candidates to
be able to drop current commitments for a week.

------
tomblomfield
OP here. I'd love to how other startups run technical interviews -
particularly when you're interviewing for roles that are outside your area of
expertise.

~~~
xxqs
I think the best would be to find a consultant with the required expertise to
run such interviews.

I've been at two on-site interviews at Google, and that was the most exciting
experience, especially the first time. Now I know how proper technical
interviews should be done. In general, I realized how much more I'm able to
do, compared to what I was doing at my place of work.

The general approach is to figure out how the candidate is able to think in a
structured and analytical way. It doesn't matter if the candidate doesn't know
something -- much more important is to see how he or she is developing the
answers during the interview. Of course, the questions should also allow such
freedom.

Also useful, is not to ask for definitions of something, but for difference:
how A differs from B and why? Then you clearly see if the candidate
understands what's behind it, even if they have forgotten some little details.

~~~
tomblomfield
I'm always wary of consultants - we've had some really bad experiences using
recruitment consultants.

I absolutely agree that the main aim of an interview is to determine if a
candidate is able to think in a structured and analytical way. I'm much more
interested in talking about situations when you might choose UDP over TCP,
rather than being able to recite the details of a particular HTTP
specification

~~~
aen1
Sadly enough, I've been ask the UDP/TCP question many times, so I have a good
answer, though I have never studied either in depth. So, in theory that would
be a great question. But, it is asked too often to really be of any use.

~~~
xxqs
actually a great interview question is what happens when you click a link in
the browser. All the steps down to how deep you understand it: through the
kernel calls, DNS packets, ARP, Ethernet frames, IP routing, TCP
acknowledgements, HTTP headers, MIME types, and so on.

~~~
aen1
How is that good? It's all memorization

~~~
xxqs
nope, this is all about understanding the logic and how the system components
interact with each other.

Besides, you can dig deeper in any direction, depending on the candidate
profile. For a network engineer, understanding on the packet level is
important. For a web programmer, the interaction between server and client is
important (HTTP headers, MIME types etc, webserver scalability etc.). For a
sysadmin, understanding of processes and interaction of applications and OS is
important. All those can be derived just from a simple question -- what
happens when you click on a link

~~~
tomblomfield
I agree - you can memorise answers on a fairly generic level, but digging
deeper in a relevant area, or talking about edge cases, exposes whether a
person really understands what's going on.

~~~
xxqs
besides, how can one memorize if the questions are unknown?

