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

[dmpayton]

Hello,

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.

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?

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?

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?

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

Their website is http://www.galaxyit.com

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.

Thank you.

[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 → edw519]

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

[edw519 → dmpayton]

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.

[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!

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

[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 → 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 → 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 → 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.

[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 → dnaquin]

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 → brk]

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.

[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 → brk]

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?

[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!

[streblo]

http://www.everything2.com/index.pl?node_id=717800