

Ask YC: Interview at Startup -- What to expect? - dmpayton

Hello,<p>I'm a 20 year-old web developer with a wife and a baby on the way. I have an interview at a startup on Monday, Dec 17, and have a few questions for the startup community.<p>First, the position is for a PHP developer. While I started out in PHP and worked in it for several years, I haven't touched it since March when I switched to Python, and I've grown a bit rusty. Can you recommend any specific area that I should brush up on?<p>Secondly, what sort of questions should I expect to be thrown at me? I'm not really expecting too much about programming in general, as they're going to have me write some code, but what other kinds of questions might I get asked?<p>Finally, what questions should I throw back at them? I've read that interviews are just as much for the potential employee as the company, and there's the obvious asking about salary, benefits, programming environment, desktop setup... But is there anything I should make sure to ask?<p>A bit about the company: "Galaxy IT, Inc. is working on a web application that will take your current addiction of wasting time online, and your real-world need to get things done, and make it possible for you to do both at once."<p>Their website is <a href="http://www.galaxyit.com" rel="nofollow">http://www.galaxyit.com</a><p>I apologize for the short time-frame between this post and my interview date. They asked me to interview on Tuesday, and since then I've frantically been trying to get things prepared. I only just now thought about asking news.YC. If you can't tell, I'm quite nervous about the interview. What they're working on sounds really neat, and the pay is much more than I'm making now (and with the baby coming, it'll really help). I really want to make a good impression on them.<p>Thank you.
======
brianr
This past summer I did a couple interviews for a position that sounds similar
to this one. If the interviewer is like me, these tips will be helpful:

-Do some of the Project Euler problems: <http://projecteuler.net/index.php?section=problems> . Think about how you could optimize your solutions. -Read/skim through the 'language reference' section (<http://www.php.net/manual/en/langref.php>) of the PHP manual, paying particular attention to the PHP5 section on classes/objects.

-Familiarize yourself with a couple of the popular PHP5 frameworks (cake, symfony, codeigniter), just do get a general idea of how object-oriented web applications are done. If you have time, play around with one of the sample apps or build something simple (i.e. a blog).

-Make sure you're comfortable with all the relevant PHP and SQL vocabulary--not just the definition, but also the application.

Specifically, here are some questions from my usual set of technical
questions: -Explain the difference between private, public, and protected, and
give an example where each is useful. -Explain the difference between an
abstract class and an interface, and when each is useful. -Explain the
difference between an inner join and an outer join. -What is the difference
between GET and POST? -In as much detail as you can, explain what happens
between the time when you type "<http://www.google.com>" into your address bar
and press enter, and the time when Google's homepage appears on your screen.
(Looking for basic knowledge of DNS, routing, TCP/IP, and more specific
knowledge about the HTTP protocol)

-(Given a small db written on the whiteboard,) write a handful of SQL queries (testing knowledge of joins, group by, having, subselects)

-Two PHP coding questions, one solved by writing a recursive function and one to write a basic class for string-processing.

I'd also ask a few questions about HTML, CSS, and Javascript.

Hope this helps, and good luck!

------
nostrademons
(Wow, I think I wrote a comment too long for news.YC to process. I'm going to
break it up and post it as replies to itself.)

It varies a lot depending on your hiring circumstances. I was hired on the
spot, before the interview, because it was for an internship and I came highly
recommended by a friend of the chief architect. Then when I applied to the
same company for a full-time position, I had an offer on-the-spot based on my
internship. OTOH, when we hired a more senior guy, he went through about 6
rounds of interviews over 3-4 months, including programming tests and full
interviews with the rest of the staff.

Here's what I looked for when I was interviewing candidates who had no prior
relationship with the company. (And keep in mind that I'm far from the best
interviewer, and more experienced interviewers may have more creative
questions):

Expect questions about each prior project that you've listed on your resume.
The resume tells me what you've been involved with; during the interview, I'm
going to want to find out:

1.) What precisely was your involvement? Did you write small submodules while
someone else stitched them together, or did you come up with the whole
architecture? Maintenance or new development? Did you have "people yell at
you" responsibility?

2.) What technologies did you use (if not listed on your resume)? This
includes things like your IDE, source code management system, and bugtracker.
This actually wouldn't affect my "hire or don't hire" decision much (though I
want to see that you at least know what IDEs, source control, and bugtracking
are), but I want to know the information so that if you are hired you can get
up to speed as quickly as possible.

3.) What challenges and dead-ends did you face, and how did you resolve them?

4.) Did it enter production, and how did customers respond to it?

5.) Was it a team or individual project? Many interviewees assume that the
right answer is "team" and try to make some of their solo efforts sound like
team projects ("Well, I had my friend helping, and there were these
classmates..."), but really I like to see _both_. There are aspects to solo
projects that are in some ways harder than group efforts. (And of course, the
point is to see what you've really done and not what you think the interviewer
wants to hear you've done...)

~~~
nostrademons
I always have applicants write code on a whiteboard. I usually pick a simple
coding problem, like something that'd be an intro computer science problem or
code kata. (I tried using psykotic's Left Factoring Regular Expressions
problem off programming Reddit once, but it was wildly inappropriate for the
caliber of applicants we were getting.) If you're hiring for a database design
position, I might have you design a database schema instead. I'm looking for:

1.) I don't care about syntax errors. It's trivially easy to forget a
semicolon or parentheses on a whiteboard and doesn't reflect poorly on you if
you do (usually I'll just write them in at the end).

2.) I do care about how fast you can remember language keywords and commonly
used library functions. This is usually a good proxy for experience with the
language, because after any significant development these tend to get "burned
in" and you can write them out instinctively. Someone who doesn't remember the
syntax for a foreach loop in PHP probably hasn't programmed PHP in a while.

3.) You can make all the mistakes you want, but I'm looking at how quickly you
realize they are mistakes. It's a very bad habit to write something out, look
at it, realize it's wrong, and then rewrite the whole thing. (Okay, that's
basically what I've been doing with my startup for the last month, but at
least it's wrong on an architectural level, in ways that we couldn't have
foreseen a month ago.) It's a good habit to write things down and immediately
correct them if they're wrong.

4.) If you come up with the textbook algorithm immediately, it shows me that
you've had this problem in class and actually remember what you learned there
(I may have you do another problem then). If you come up with the textbook
algorithm eventually, it shows me that you're good at thinking things through
and analyzing a problem. This is probably the best situation hiring-wise. If
you come up with a completely out-of-the-box solution that works and doesn't
have any obvious fencepost or performance problems, it shows you're a creative
thinker. This is also speaks well about you as a candidate. If you struggle
and come up with something completely wrong, I'll probably prod you with
questions about its behavior; this is not a good situation, but I'll look more
favorably upon someone who finishes and gets the correct answer eventually
than someone who gives up and says "I don't know."

5.) I like it when people use library functions rather than reinventing the
wheel (particularly if they are library functions I don't know myself; though
I will check and learn them myself after the interview to make sure you aren't
bullshitting me ;-)). If I ask someone to write a sorting algorithm and they
put down "sort()", they get points for their cheekiness, though I'll have them
do another problem or add some specific requirement that makes the library
useless.

6.) It's good to talk through what you're doing, for the same reasons teachers
ask you to show your work. It lets you get partial credit for right-thinking
but wrong-writing. And if your thinking is off but you say it aloud, I'm more
likely to ask prodding questions to make you rethink; I look at this more
favorably than if you got to the end, pronounced it done, and it was wrong.
You're also more likely to catch the error yourself, and correcting yourself
is actually a net positive.

~~~
nostrademons
My first few interviews, I asked "language trivia" questions, usually about
simple standard library calls or concurrency issues (I assume they know the
basic syntax, and if they don't I can catch it when they write code). I moved
away from these in my later interviews, though, because I found they didn't
really tell me anything interesting. The standard libs in most languages are
too big for anyone to know them all, so this is really testing how well their
experience matches up with yours, and that's not often that relevant for the
job.

I'm going to ask why you want the job. The reason for this is that I've found
passion is the best predictor of job performance (remember the senior software
engineer who went through 3-4 months of interviews? he turned out to be a much
better programmer than me, at least at this particular job, because he cared
about the project so much more). Don't bullshit me with vague answers; you're
not really doing yourself any favors if you apply for a job you don't really
want. But if you really want to work at a company because you believe in what
they're doing, say that - your passion comes through how you speak and not
necessarily what you say.

I don't ask this myself, but many people who have interviewed me have: "How
comfortable are you playing many different roles?" In startups, you'll be
doing this a lot - the job you're hired for is probably not what you'll be
doing in six months. Be sure you're comfortable with this before applying.

I also look for evidence that the candidate has done some research about us in
their answers (and questions!) throughout the interview. It's a big plus if
you don't just want _a_ job, but want _this_ job.

~~~
nostrademons
As for questions you should ask of the employer:

1.) Be sure to ask what specific tasks you will be doing. If it's a startup,
they're going to say "We can't know that, because there's lots of things to do
and we all play multiple roles." Acknowledge that and press them on what
you'll be doing within the first month of hiring (or start with that version
of the question).

The reason for this (aside from it speaking well about your engagement, and
weeding out companies where the daily work will suck) is that an inability to
figure out what a new employee should be doing is a _huge_ negative predictor
of management skill. I took a job like this; it worked out great for the first
8 months or so, when I took his lack of direction as a signal to pick out
tasks that would be good for the organization and do them. It turned bad when
he decided to actually tell me to do something and then couldn't provide clear
direction about what it was I was supposed to do, nor discretion to let me
make the decision myself.

2.) Ask about the business model, growth rates, sources of revenue, and
profitability of the startup. You'll want to know this, but it's somewhat
difficult to interpret it. When I first started looking for startup jobs, I
cared mostly about profitability, which was a mistake.

Basically, a "startup" as it's normally discussed on this site is a business
that's growing really fast. Like, a few hundred % a year (in other words, it
has to be more than doubling each year). Very few early-stage small businesses
actually meet this criteria; I've never worked at one, though I've been at one
or two where the market could've supported that if we'd gotten our act
together and shipped product.

Profitability basically only has a bearing on whether you are likely to lose
your job through no fault of your own. If the company is profitable and you
are productive, you're very unlikely to get laid off. If the company is not
profitable, everything is a race against running out of money. If you join an
unprofitable company, be sure you find out their burn rate, runway, and
expected break-even point. Make sure there's an adequate safety margin between
the break-even point and runway; things tend to go wrong in startups, and
everything takes twice as long as you expect. Otherwise, expect your job to be
toast at the end of the runway.

On a similar note, find out where the revenue is coming from. A company that
gets $4M in revenue from 100,000 customers is a lot a more stable than one
that gets $4M from 4 customers. Consulting companies are even less stable:
consulting revenues tend to shrink dramatically in recessions. A profitable
consulting company is not a startup in the sense of this site: it can't scale
at the growth rates of a typical startup, and if it wants to turn into a
product company, it'll basically have to start from square one.

3.) Make sure you meet all your prospective coworkers. You'll be working with
these people a lot; make sure they are people you can work with. Many startups
have an employee-veto hiring policy anyway; if any employee doesn't like the
new candidate, it's a no-hire. (This is why I was doing interviews, BTW.)

4.) Ask if any employees have left recently, and why. Some turnover - perhaps
10%/year, or one employee in a firm of 10 - is natural. However, if the whole
project team quit, that's a bad sign.

5.) Ask about exit strategies and where the founders see the company going
over the years. There's no right answer here, but there are things to be aware
of. For example, option-holding employees tend get screwed in an acquisition.
Many companies will either convert options to options in the acquirer or let
employees buy in before the acquisition, but there's no requirement that they
do so. And in many cases, your stock grants are small enough that it doesn't
matter much anyway. The only early employee I know of that got rich off a
startup was a VP in a company that went IPO; most made between $3k-10k. (This
is under Massachusetts culture/laws; things may be different in California or
other states.)

If the founder intends to keep the company private and grow the business
organically, stock grants are effectively worthless. There's no liquidity; you
can't sell them. Go for a fat salary in that case.

6.) At the very end, ask about salary/benefits/stock. These things do matter,
you just don't want to seem too eager about them. Companies will expect you to
ask at some point, they just don't expect it to be the first thing you care
about.

------
staunch
Might be useful to check out some of the PHP code your interviewer has written
himself.

<http://code.google.com/u/irma.olguin.jr/>

<http://bookbuster.googlecode.com/svn/trunk/>

<http://ridiculouspysch.googlecode.com/svn/trunk/>

------
dhouston
<http://www.google.com/search?q=questions+ask+joining+startup>

there are a bunch of useful "top N questions" blog posts from VCs and
entrepreneurs that should give you a good start.

------
bayareaguy
Consider putting together a list of all the "Google Interview Questions", give
yourself an hour to write a brief solution to as many as you can and then ask
someone you respect to review your answers. You could start with these

<http://tinyurl.com/3xtxa3>

<http://tinyurl.com/hpg7v>

<http://tinyurl.com/2fpl6y>

<http://tinyurl.com/2jqtgh>

I had a high school math teacher who gave tests with more questions then
anyone could ever answer. The top score for the class on a 100 point test
would often be around 8 and the average around 4. Everyone in the class
learned how to deal with situations where you couldn't possibly answer all the
questions perfectly. The high scorers were often people who provided partial
solutions to many questions instead of perfect ones to a few.

------
webwright
Ask about how much money is in the bank and what the burn rate is. What you
want to know is "When will you go broke if you don't get revenue or more
funding?"

If you care about equity, you should read up on options... But you should
really treat options as worthless unless you believe there is a chance for a
HUGE win.

------
brk
From the perspective of what you would want to ask them (you'll need to phrase
more politely than my thoughts here):

Founder(s) background(s) / prior wins

Competitors

Market for product / growth potential / expected scale

How many other developers

Release schedule (ie: when is the first Beta, etc)

Founder(s) reason for starting the company (get rich, get famous, have fun,
etc)

How far is the Angel or First/current funding expected to take them? Then
what?

Pricing model.

~~~
streblo
I always tend to ask a question like:

In every company, there are issues and problems that everyone seems to be
concerned with. For example, at my last job, there seemed to be a division
between the "old timers" and the new wave of recent hires. What kinds of
things do most of your employees tend to be concerned with or worry about?

------
dnaquin
follow 'brk's advice on asking questions. just thought i'd mention. you should
avoid asking about salary, benefits, etc. gives the image you care more about
getting paid than the actual project. and besides, if you get an offer, those
questions are easily answered in a page or two of an offer letter.

just ask about their project and business. but nothing you could have easily
found out on your own.

~~~
brk
Yeah, I forgot to mention,don't ask anything that is already answered on their
page/blog.

Also don't ask about pay details until after they bring it up.

However, as far as options are concerned, you SHOULD (IMO) ask:

What is the size of the total pool?

What is the size of the employee pool? How are the shares distributed in terms
of preferred/common?

Under the current terms, what point do the preferred shares need to hit before
the employee/common options participate?

Extreme and simple example: They could grant you 5 million common options out
of a total pool of 100 million with an employee pool of 25 million. Which
would sound like 5% of the company and a HUGE chunk of the employee pool. The
investors and founders might have 50 million preferred shares between them,
but if the terms say that the preferreds split the first $500M in an equity
event before the common shares participate, your 5 million shares are never
likely to see any value.

I wouldn't get too far down a rat-hole with this, but asking some good
questions will usually help show that you're not option-drunk and easily
bought off with big, but meaningless, numbers :)

~~~
timr
Don't do this until you have an offer.

The rule is: (s)he who says the first number, loses.

Don't be a loser.

------
dmpayton
I highly doubt that anyone will revisit this thread, but I wanted to post a
follow up for archiving sake, and in case anyone decides they want to know how
everything ended up.

So, I felt the interview on the 17th went great. I didn't have much trouble
coming up with answers to questions they asked me, and my interviewers had
fairly easy-going personalities, which helped me relax a bit.

That Thursday, December 20, they asked me to return for a second interview on
the following day. I got to meet the entire team (all three of them :o), see
the office, and see a bit of the product. They said they'd get back to me by
the end of the day and, long story short, I spent most of the weekend checking
my email every 15 minutes.

Then came Christmas Eve Day: I got an email from the head honcho saying I'd
been given the position, outlining my duties, and asking when I could start.

Thank you everyone who replied to this thread, your advice was invaluable!

------
edw519
Here is the dirty little secret about evaluating the code you write in the
interview:

What is on the piece of paper (or editor) doesn't make a whole lot of
difference.

What happens when you and I talk about what you wrote tells me almost
everything I need to know.

Less than one percent of interview code I've ever seen even compiled. What I
was really looking for was:

\- Did he understand the problem?

\- How did he approach the problem?

\- Does he appear as if he has any idea what he's doing?

\- Can he explain what he has done?

\- Can he defend what he has done?

\- Does he understand the concepts of order, cleanness, iteration, branching,
recursion, etc., etc., etc...

\- Based on this small sample, do I think he can do the work we need done?

\- Do I like him? Will he fit in and be a good team member?

So assuming they interview like I did (a big assumption), here's the good
news...whether or not you'll do well has already been determined. So don't
bother to "cram" between now and Tuesday. Relax. And have fun. Be yourself and
it will all work out OK (one way or the other).

~~~
dmpayton
Wow, excellent advice. Only problem is, I don't know if they'll interview like
you or not.

~~~
edw519
Even if they don't, I wouldn't lose sleep about your code being perfect. As
long as you can have an intelligent conversation about it (you ARE passionate
about it, aren't you?), you'll be fine. Best wishes.

------
streblo
<http://www.everything2.com/index.pl?node_id=717800>

