Good and bad questions for candidates to ask

As a candidate, you should definitely ask questions during an interview. But it’s a complete myth that you need to heavily research a company or startup beforehand in order to come up with good questions. Here are a few good questions I’ve heard recently, in no particular order.

What are the working hours like?

I get the sense some people avoid this question even when they should ask, because they fear coming off as too concerned about work/life balance. I think this is overblown, and most places are going to at least pay lip service to caring about balance and offering a reasonable description of the hours and flexibility you would be subject to. A great way to frame it is ask about the interviewers’ hours or the founding or executive team’s.

What are the team members’ backgrounds?

This seems like a good way to demonstrate curiosity about cultural fit and working environment. I think cultural fit is overused and misused as hiring criteria in a way that has the unintended outcome of being racist or sexist, but it can still be a useful signal, or at least a way to suss out red flags about the company culture.

Also, at smaller companies, this might be the single most important detail, because the experience and character of the early leadership team is overwhelmingly going to determine workplace culture, not to mention the success of the venture.

Do you hang out together outside of work?

The answer to this question could help set and communicate expectations around friendships in and out of the office. I think it’s a tall order to assume people “need” to be friends outside of work to be successful, so a mismatch in expectations here is illuminating.

And also for me personally, it would be weird if the team didn’t occasionally celebrate milestones with team offsites or dinners.

What will my first few weeks be like?

This is a good way to check if there is a defined onboarding plan and specific set of projects in mind for the candidate. Speaks to the level of organization and preparation of the firm for the new employee’s arrival. Note that this question may not be appropriate for interviewers who would be peers.

What is your technology stack?

Not a great question on its own, but sometimes leads to interesting origin stories regarding the firm or product[1]. Also, it can reveal how the stack has changed and hint at how the company approaches technical decisions. As a bonus, it can also reveal naive aphorisms like “use the best tool for the job” which in my opinion always betrays a lack of technology planning (who is going to maintain your polyglot systems at scale?).

What are your hiring plans?

This can reveal organizational priorities and shine light on projections for growth, cashflow, etc. In rare cases this can immediately disqualify companies that clearly don’t know what they are doing (e.g., trying to get sales and biz dev #10 before a prototype has even been built, etc). But this is rare for most companies that have raised outside money, in my experience it’s mostly bootstrappers and people who are spending a financial windfall who fall into those traps because they often have no one to tell them their hiring plan won’t work.

Other good questions to ask

There are some situational or firm-specific questions that should be asked if you’ve done some research and can’t find a satisfactory answer. Sometimes it’s good to ask in general about the product roadmap (to test if they have a plan, and/or whether their plan is delusional). Sometimes it’s good to ask about monetization plans (if they are pre-revenue) or fundraising (if they are pre-revenue and haven’t raised in, say, a year or more).

Bad questions to ask

A lot of bad advice on this topic takes a cargo cult approach to interview questions, or treats it like a clever game of turning the tables on the interviewer (“act like an owner” or “act like an investor”). This is not a winning approach.

Investors are either putting in someone else’s money, or investing their own money that they can afford to lose. In either case, there’s no obvious parallel to how you as an employee should vet a company you plan to join. You should do your diligence, but there’s nothing specific to diligence as a potential investor that you should emulate. Investors hope 9 of 10 investments utterly fail and 1/10 becomes the next Facebook. This isn’t some special corner case – it’s the ideal scenario for the investor, and an absolute disaster for most employees.

And “act like an owner” sounds like smart advice, but doesn’t actually mean anything in practice[2]. You will, by definition, be essentially the opposite of an owner. So even if “act like an owner” could be translated into insightful questions or actions, they aren’t likely to be good moves in your situation. So with all that said, here are some things I would personally avoid:

Coming off as skeptical of the product or business model.

You should definitely ask about the product or business model if things aren’t clear, but wrap them in a veneer of curiosity, rather than the arrogance of an “investor”/”owner” diligencing a deal.

Asking about competitors

This one’s a bit nuanced – if there’s an obvious competitor that is further along and the firm doesn’t have clear differentiation, then this is a fair question to have them elaborate on. But I think that questions about the broader market are more illuminating than asking about any one particular competitor in the general case, because you might otherwise come off as skeptical of the product or business model[3], or miss the bigger picture.

Do you do X?

Just as it is on the other side of the table, close-ended questions are bad, and give you very few bits of information. For example, you want open-ended ones like “how do you do code reviews?” instead of “do you do code reviews?” And even that’s not a great question – it’s usually better to ask meta questions about process and how changes are expected and managed, rather than about the current process.

Are you planning to do X?

Aside from falling into the one-bit-of-information pitfall above, this question asks the interviewer to verbally commit to something that you have no way of verifying. “Yes, we’ll definitely do X when we have the funding for it” gives you less than one bit of information, because you haven’t established enough trust to rely on their word, and it’s too early to be making demands that will get you written assurances.


[1] I’ve had multiple people who, upon hearing about our hosting stack (Heroku), complain that it was too expensive, with a subset of them obviously implying that we made a poor choice.

[2] I’ve found most career advice that can be summed up in one sentence to fit this description.

[3] This is one thing investors get to do that you don’t: you don’t get to be skeptical of the plan or business model, because nobody wants to hire someone like that. On the other hand, I’m sure plenty of founders could live with skeptical investors as long as they forked over the money, because as much as both founders and investors like to pretend its about more than the money, its mostly about the money.

How to Write a Software Resume

One of the fun things I did in college was screen resumes and interview candidates for various reasons: as a student programming lead, then as a technical adviser to nonprofits at my university (the trust conferred on me was rather novel at the time). The good candidates have stayed in my mind as vividly as the terrible ones. I later got to see hundreds of resumes while recruiting for Microsoft, and there are patterns to the best and worst resumes. Here are some of them:

  • Use keywords: C++, Java, Ajax, ATL, pthreads, MongoDB. Preferably in the context of stuff you worked on. I’m trying to judge how hard the projects were, and it doesn’t help if you just say “built an e-commerce system.”
  • Show some expertise. Don’t just spam keywords but rather clusters of related ones to show you’ve actually explored something in depth rather than just dabbling in 30 languages. “Java 6, Ant, JBoss, Spring & Hibernate” says a lot more than “Ruby on Rails, Python, PHP, Java, Lisp.” As a corollary, make sure you list where you worked with these languages under your experience. If you list “Java” a single time on your resume, I can pretty much guarantee you do not know Java.
  • Don’t give mundane details. If it takes you more than about a sentence to describe your role, you’re probably doing it wrong. I want to see accomplishments and specific projects and technologies you worked with. As a general rule, ruthlessly remove every word that can’t conceivably change my mind about you. “Filed reports and assisted customers with inquiries?” Shut up.
  • Don’t lie or exaggerate. Don’t even stretch the truth. “Assistant to the Manager” is not an “Assistant Manager.” A “4.0/5.0” GPA is not “a 4.0”. Reviewers pick up on these tricks.
  • DO NOT PAD your resume. If you’re a college hire or looking for an internship, we understand your experience is light. This doesn’t mean you need to go on endlessly about your volunteer work or have 5 bullet points about your cashier position at CVS. I don’t need 4 lines of crap about how you worked at a dog shelter. Adding drivel de-emphasizes your relevant experience and drowns out the signal with noise.

This last point is particularly sensitive. Many people don’t feel comfortable filling out 3/5ths of page, or even 4/5ths. They must fill the whole page, with anything. I have seen college sophomores who insisted on 2 full pages, size 10. The perpetual fear among this population appears to be: “I am so young, how do I prove I am mature, responsible, and capable without bucketloads of meaningless accomplishments?” To that I answer:

  • Your grades. Especially in computer science, but also peripheral classes. It’s important that you do well even in courses you don’t like, because that’s the sign of a responsible adult (doing things you don’t want to do: story of a grownup’s life).
  • Length of employment and/or extracurricular involvement, rather than quantity (or needless details). Being able to stick through things for medium and long term commitments is the sign of a mature person.
  • Projects: open source contributions, bootstrapped web-apps, whatever. This is the next best thing to work experience, displays initiative, and is the best time for you to experiment before you get beaten down by the everyday stresses of life after college. True story.

IBM Software Engineer Interview Questions

Here is a dump of some questions from an IBM software engineer interview.

Note, these questions are mostly behavioral, and are geared towards a student who will or has recently graduated from school. Copious notes are taken during this process.

Whether these should be questions of import in a software engineer interview, I will leave for another time.
Continue reading “IBM Software Engineer Interview Questions”

The Amazon SDE Interview

Amazon recruited on campus at UMass over last fall and I was lucky enough to snag a spot after running into them at the career fair. The rep at the table quizzed me on some generic stuff, recording my answers (what is the algorithmic complexity of the best comparison sort?) on the back of my resume.

The interviews are done over several days by 4 interviewers on campus. Each one lasts about 45 minutes. In the first interview, I am randomly assigned to one of the interviewers. I was not asked very challenging questions, but we briefly went over my resume and he described his engineering department and product. Continue reading “The Amazon SDE Interview”

The Microsoft SDE Interview

This is the first of several interviews from fall of 2010 that I will document.

The Microsoft Software Development Engineer Interview is hard. While no interview process is perfect, they do a lot of things right in terms of setting a high bar, as well as showing off what the company has to offer. It is exactly what you’d expect from a world-class software company that has fairly high standards for engineers. Continue reading “The Microsoft SDE Interview”