Questions to ask your potential employer

http://www.stefankendall.com/2013/11/10-questions-to-ask-your-potential.html

by stefan_kendall • 13 years ago

314 147 13 years ago

I think another important question to ask is will they will let you speak to the current team(s) and ask them questions. In my experience they are more likely to give honest answers.

sethammons• 13 years ago

or just interview at a place where the teams do the interviewing, like where I work ;)

human_error• 13 years ago

I had a job interview two days ago and the manager covered the first 9 questions before I asked (I had 1,2,3,4 and 6 on mind but he talked about all of those topics). I don't know if it's a good sign or a bad sign though.

namenotrequired2• 13 years ago

I'd say that depends on whether you liked the answers or not :)

namenotrequired2• 13 years ago

11. What's your reason for working here?

Bahamut3• 13 years ago

In my case in my last interview, I asked to see some of the codebase. It was a less than ideal situation, and there were no unit tests for the frontend. However, I saw it as an opportunity to make an immediate impact on the dev process.

I ended up accepting the job, but I knew what situation I was entering and what to do to make a difference. Suffice it to say, it has been a great experience for all parties involved, and we took a demo and shipped a major product in under 2 months while solving many critical issues along the way, paving the road for smoother development in other concurrent & future projects.

edw519• 13 years ago

Excellent list.

A few more:

- What will my typical day be like? (The answer will always start with "We don't have a typical day." So you say, "I know. Describe it as if there were one.")

- What will my life be like in 6 months? One year?

- What's the worst thing that can happen in the next 6 months? Next year?

- What's the probability we'll achieve our goals in the next 6 months? Next year?

Don't depend upon the answers but expect some very insightful discussion.

joezydeco2• 13 years ago

- What will I be doing the first week I'm here?

If you get an answer like "you'll be setting up your development machine and loading/building the A-12 project to get a feel for our servers and systems", that's good. You also have your first assignment when you show up and your boss is too busy to guide you around.

If you get a shrug and something more nebulous, press harder. If they can't answer, expect a goat rodeo when you start.

rmc12• 13 years ago

a "goat rodeo"?! I think I'm missing the analogy, can you explain?

pseut2• 13 years ago

I've found, "what was yesterday like, then?" to be a fine response when interviewers have claimed there's no typical day.

dsr_• 13 years ago

I've never interviewed a candidate in person and not given them at least 20% of the scheduled time to ask questions about the company. I have only once accepted an offer from a company that didn't offer me a similar opportunity, and that acceptance was a major mistake.

rmc12• 13 years ago

Interview are not just a company evaluation a prospective employee, they are also a person evaluating a prospective employer.

raverbashing• 13 years ago

Good list. N. 2 is a good catch really.

I would add another question. What's the development stack like. And by that I don't mean N.4

What I mean is: What's your source control system, bug tracker, (possibly) IDE/Editor, (possibly) other tools/environmental issues depending on the area (more usual in specific areas, embedded software for example)

jkbyc• 13 years ago

The list may be good but I find this writing style off-putting

Bahamut3• 13 years ago

Questions I like to ask as a job candidate:

- Can I see the code base? (it lets me see a bit of app structure, code style, etc.)

- How is the company doing business-wise? (I like to see big success indicators like rapid growth)

- How flexible is the employer with regards to having to take emergency and/or scheduled time off work without being penalized for vacation (i.e. waiting for a package, or specific to me, reserve duty in the military)?

- How do you see me fitting in with the company initially? (I am flexible, but I would like to know what role I am being hired for, as job descriptions are often opaque or misleading)

Unspoken questions I'm looking to have answered by coming in for an interview as a job candidate:

- What is the dynamic between employees?

- What is the company culture?

- How intense is work at the place typically? (just for personal gauging purposes - this isn't a make or break thing, but it's something I want to know)

- Does the workplace treat its employees well? (do the employees look happy to be there?)

- How transparent is a company when answering my questions? Are the responses detailed? Is there something that is being hidden from me?

There are probably more questions I tend to want answered that are never spoken, but incumbent on me to take note of through observations. As a job seeker, you owe it to yourself to be as sharp as possible about your own future.

reinhardt• 13 years ago

- Can I see the code base?

I've often wanted to ask this but didn't have the nerve to do it. Even if it doesn't raise some eyebrows, are there companies that actually say yes?

Bahamut3• 13 years ago

I got an affirmative answer with just a brief look into it - I didn't see the details, but I saw enough for me to extrapolate valuable developer insight.

I was obviously not looking to steal code, and I was a candidate that was "interviewed" by only tech leads - I think I asked more questions than they did, and I kept the discussion very respectful.

rmc12• 13 years ago

Heck, employers want to see code samples from employees. Why shouldn't employees be allowed see code samples for what they will be working with.

pbiggar• 13 years ago

Coming from the interviewer's standpoint, this is one of the best lists like this I've seen. Everything is relevant, they're all valuable questions, and their all fair to ask.

I would add that you should ask questions about the employer's business too, especially at a startup. How do you make money? When will you be profitable? What's your direction?

yitchelle• 13 years ago

That is a really good point. It is really important to know that the growth of the company is planned. I doubt if the company would ever paint a dark picture of the future of the company. It would either paint it neutral or bright.

seiji4• 13 years ago

Practical questions that always bite me:

- When do we get paid? Every two weeks or twice a month? Every two weeks means your pay is essentially reduced by two entire paychecks. With "twice a month" your paycheck is $NET_SALARY/24. With "every two weeks" your paycheck is $NET_SALARY/26, meaning two months out of the year, you'll get three pay checks. But--the rest of the year, your salary is essentially reduced by ($NET_SALARY/26 * 2). You can't create a monthly budget out of two pay checks you get twice a year, six months apart.

Realistically, you aren't going to not go with an employer because they pay 26 times a year instead of 24. It's just something to be aware of since it reduces your practical salary by two entire paychecks.

- Are benefits included? It's a mild disappointing cognitive change to go from a job that pays full benefits to one that makes you pay $100/month for them.

- Meals/snacks/fruit? It's another mild disappointing cognitive change going from a company catering two meals a day to one charging $2 for a water from a third party vending machine.

- Are you lumping any bonuses in with the full salary you're offering? Be careful of HR starting your conversation with "Your total compensation is $80,000 per year" when they then mumble "That's a $45,000 base and a $35,000 bonus, paid out yearly at the end of your hire date anniversary." Your huge total comp package may make your ego feel good, but you can't budget against end of year bonuses.

- Stock is always imaginary unless you're at a public company. Always try to double or triple the base "options" they offer. Be wary of places that do 25% cliffs instead of 50% cliffs. 25% cliffs are just silly.

Espressosaurus• 13 years ago

Total compensation is what's important, so long as the interval between payments isn't too long.

If you have to sweat the difference between being paid twice a month and every two weeks, you need to start saving yourself more of a cushion.

seiji4• 13 years ago

It's always easy for not-poor-people to say "just have more of a cushion."

Let's use an example. Assume $100,000 salary, pre-tax. Post-tax, let's assume your net salary is $74,000.

For being paid twice a month (15th and last day of the month), each pay check will be $3,000 (we're rounding up here). Each month you'll have $6,000 to spend.

For being paid every two weeks (every other Friday), each pay check will be $2770. Each month you'll have $5540 to spend ($460 less than the twice a month schedule). Except—two months out of the year, you'll get a third $2770 paycheck, giving you $8310 to spend in those two months.

It's just... weird. What's the difference? A car payment or a student loan payment or extra food or insurance premiums or parking or transit or anything you can spend $460/month on. Sure, to a well off person $460/month may not sound like much, but it adds up when it's taken out every month and only paid back in lump sums twice a year. (My entire point being: you can't form your monthly budget to include lump payments six months in the future.)

vadman• 13 years ago

Create a monthly budget out of the guaranteed 2 paychecks a month, and consider the other 2 mini-bonuses?

seiji4• 13 years ago

That's exactly what happens. "Oh, look, May has an extra Friday. Looks like I'm getting a treadmill this month."

walshemj3• 13 years ago

The two weeks is very American no one in a professional job in the Uk and Europe doesn't get a monthly salary.

ljf• 13 years ago

Was coming to post the same thing, here in the uk the more regularly that you get paid, the simpler the job type. Nearly all salaried jobs are monthly, come temping and contracting is biweekly, and manual work is weekly or even daily in small scale construction or other manual work.

skylan_q• 13 years ago

When do we get paid? Every two weeks or twice a month? Every two weeks means your pay is essentially reduced by two entire paychecks. With "twice a month" your paycheck is $NET_SALARY/24. With "every two weeks" your paycheck is $NET_SALARY/26, meaning two months out of the year, you'll get three pay checks. But--the rest of the year, your salary is essentially reduced by ($NET_SALARY/26 2). You can't create a monthly budget out of two pay checks you get twice a year, six months apart.*

Am I missing something there? To me, this is only a concern for someone living paycheck to paycheck and that generally doesn't seem to be an issue for software developers.

rmc12• 13 years ago

"Your total compensation is $80,000 per year" when they then mumble "That's a $45,000 base and a $35,000 bonus, paid out yearly at the end of your hire date anniversary."

And if that bonus isn't guaranteed, then you're not even getting that.

mcenedella4• 13 years ago

This is a terrific developer-specific list. The realism about acceptable answers is quite good.

Here's my own list of 20 interview questions, from a more generic business / process / employee life perspective:

1. What's the biggest change your group has gone through in the last year? Does your group feel like the recession is over and things are getting better, or are things still pretty bleak?

2. If I get the job, how do I earn a "gold star" on my performance review? What are the key accomplishments you'd like to see in this role over the next year?

3. What's your (or my future boss') leadership style?

4. About which competitor are you most worried?

5. How does sales / operations / technology / marketing / finance work around here? (I.e., groups other than the one you're looking to work in.)

6. What type of people are successful here? What type of people are not?

7. What's one thing that's key to this company's success that somebody from outside the company wouldn't know about?

8. How did you get your start in this industry? Why do you stay?

9. What are your group's best and worst working relationships with other groups in the company?

10. What keeps you up at night? What's your biggest worry these days?

11. What's the timeline for making a decision on this position? When should I get back in touch with you?

12. These are tough economic times, and every position is precious when it comes to the budget. Why did you decide to hire somebody for this position instead of the many other roles / jobs you could have hired for? What about this position made your prioritize it over others?

13. What is your reward system? Is it a star system / team-oriented / equity-based / bonus-based / "attaboy!"-based? Why is that your reward system? What do you guys hope to get out of it, and what actually happens when you put it into practice? What are the positives and the negatives of your reward system? If you could change any one thing, what would it be?

14. What information is shared with the employees (revenues, costs, operating metrics)? Is this an open-book shop, or do you play it closer to the vest? How is information shared? How do I get access to the information I need to be successful in this job?

15. If we have a very successful 2015, what would that look like? What will have have happened over the next 12 months? How does this position help achieve that?

16. How does the company / my future boss do performance reviews? How do I make the most of the performance review process to ensure that I'm doing the best I can for the company?

17. What is the rhythm to the work around here? Is there a time of year that it's all hands on deck and we're pulling all-nighters, or is it pretty consistent throughout the year? How about during the week / month? Is it pretty evenly spread throughout the week / month, or are there crunch days?

18. What type of industry / functional / skills-based experience and background are you looking for in the person who will fill this position? What would the "perfect" candidate look like? How do you assess my experience in comparison? What gaps do you see?

19. In my career, I've primarily enjoyed working with big / small / growing / independent / private / public / family-run companies. If that's the case, how successful will I be at your firm?

20. Who are the heroes at your company? What characteristics do the people who are most celebrated have in common with each other? Conversely, what are the characteristics that are common to the promising people you hired, but who then flamed out and failed or left? As I'm considering whether or not I'd be successful here, how should I think about the experiences of the heroes and of the flame-outs?

mVChr• 13 years ago

These are good questions, but many seem to be applicable to 100+ person companies only.

cdcarter2• 13 years ago

I'm currently at an organization of about 50 and almost all of these are questions that would provoke very good information about this company. Even if finance is one person, it's important to know if your manager gets along with her.

cdcarter2• 13 years ago

Have you considered publishing this list somewhere? It's incredibly useful, and though I'm saving the HN permalink, it could probably become something more.

mcenedella4• 13 years ago

Thanks. I write the largest career advice newsletter in America over at TheLadders.com -- reaches an audience of 6mm weekly.

You can see all my stuff here: http://www.theladders.com/career-newsletters

This particular newsletter is here: http://www.theladders.com/career-newsletters/it-s-not-about-...

ChiperSoft• 13 years ago

I have an open source list of these kinds of questions up on github called InterviewThis. Would you object to me adding some of these to it? These are all really good and cover some things I didn't think of previously.

http://github.com/ChiperSoft/InterviewThis

mcenedella4• 13 years ago

Looks great. I will add via github.

dinkumthinkum6• 13 years ago

Your #2 sort of bothers me. Actually, a lot of these seem like "answers" to a school assignment about what to ask an employer ... Also, would you really ask all this? You put a lot of work into this.

If someone asked me this stuff, I would thank them and probably go on a vacation to forget the whole experience.

elohesra• 13 years ago

I personally think #2 is quite important: it proves the employer knows why they're employing you, and that they have thought about the scope for career growth in the role. If the employer hasn't got a clear idea of why they're employing you, then your role becomes an amorphous "do whatever I want done" job, that won't necessarily meaningfully contribute to your skills or remain interesting. If the employer hasn't thought about the scope for career growth in your role, then that -- to me -- shows they don't value their staff enough to care about whether they get anything more than a salary out of the job.

I think it's a little strangely phrased (sounds a bit obsequious), but I think it's a valid and important question.

x0x0• 13 years ago

how? Are you in the habit of hiring without knowing the criteria for success in that role? Is the candidate supposed to guess or read your mind?

As a candidate, I always ask what would make my future boss count hiring me an awesome decision. Also, it's really interesting when different interviewers answer the question differently; I've been in the middle of a job I quit after a year where different decision makers thought the role should be different things, and it sucked.

PeterisP• 13 years ago

Most other questions may seem too verbose to actually ask in a short interview, but the #2 is a key question that should be asked always. Most likely will tell you more about the actual job contents (i.e., which task you'll be required to focus on) than everything else; and asking it early is key to avoid a mismatch in expectations.

mcenedella4• 13 years ago

Yeah, I write the largest career advice newsletter in America over at TheLadders, so I do this stuff professionally.

The key to asking #2 is to be more 'Vince Vaughan' than 'Steve Buscemi' in your approach. More butt-kicker than butt-kisser, if that makes sense.

btilly• 13 years ago

I prefer questions that are specific, verifiable, and relevant to me. When they are specific and formatted differently, interviewers will often surprise themselves by being honest. Furthermore if there is anything that would be a deal breaker, you need to ask up front.

"Why and when did the last three people who left, leave?"

"How big is the team?"

"Due to family responsibilities, I need to work an odd schedule. How open are you to letting me start at noon and then work a full day?"

kapilkaisare• 13 years ago

Instead of asking "What's the process like?", I'd try to avoid a buzzword-ed answer by asking instead "How long is an iteration? How are your teams structured (flat vs hierarchical)? Does each team have its own tester, or is there a separate QA division in the company?"

thenerdfiles9• 13 years ago

"Do you use presentational CSS classes in markup, or do you fully utilize LESS/SASS?"

I think the answer here will explain everything. (Does this employer know/care? Am I about to dive into legacy practices? What does the bottom floor of the codebase look like?)

It draws a line.

zalew2• 13 years ago

Low level implementation details are relevant questions for getting a freelance programming assignment of taking over an existing project, not a full-time contract and especially not one at a bigco. IMO asking such questions tells you are religious about petty stuff instead of looking at the bigger picture and focusing on the deliverables. Being curious about team structure, general project management and development practices is great, as it shows interest in your possible future working environment, but picking on tools and discriminating against minor tech solutions is a bit naive from my perspective.

thenerdfiles9• 13 years ago

You missed the point. It's a fishing question.

know/care

This is an implied project management question. (1) Can the employer even speak to it? (2) Does the employer see those who specialize on these areas as less important than other areas, in that they are fine with having no opinion on the matter?

legacy practices

Did you not see this?

I picked HTML and (presentational) CSS (classes) for a reason, as they are boilerplate and they indicate whether or not Separation of Concerns bubbles up to management. Questions about HTML minification, the whole point behind preprocessed languages, etc. can be teased out with just one question.

It's like breaking into a network, looking at the codebase, and then combing for organizational and sociological judgments based on what you see. (LESS/SASS will comparatively more likely be documented. That said, would you take on an employer that leaves undocumented what can most easily be documented? — so it's likely they have lots of throw-away, unreadable, undocumented CSS. Do you want to work for an employer that is okay with "throw-away, unreadable, undocumented"?)

HTML is the lingua franca of the Web. Would you honestly work for an employer that calls this "petty stuff"? Tell me that. It's a tech interview both ways.

What if the employer responds, "That's petty stuff. We hire you to make that decision. We don't care. See the forest"?

You can find any person on the street who might say this. So why are you dolled up in a suit and tie yet again to be told "What you care about is irrelevant"?

Or what if the employer says, "I don't really know, but I'm glad you think about very finely detailed problems..."?

Generally my belief is that interview questions should fish or have the structure of getting you hired on the spot (http://pbfcomics.com/81/), where in asking them you've maximally described yourself but minimally given the employer the opportunity to fail. (Again, you don't care about your lingua franca of the Web? Go hire someone who has no opinion on this like you do.)

dinkumthinkum6• 13 years ago

I agree. I had a "Oh, here we go" reaction.

philwelch5• 13 years ago

I can't think of any substantial job where stylesheets, of all things, are anywhere near the top 100 concerns.

bartonfink• 13 years ago

I'm playing devil's advocate here, but a full-time front-end designer might care deeply about such things. I would not, for example, take a J2EE job even though I know Java because I know they are not "just the same." I could see a designer caring about the stylesheets they'd be working with even though it's all fundamentally CSS.

thenerdfiles9• 13 years ago

Look, "text/less" is not something browsers understand. This question is also asking about the adoption of standards — this has absolutely nothing to do about stylesheets. Three aspects of the codebase are involved here: HTML (the lingua franca of the Web), CSS, and LESS.

Look at what the question contains: "presentational CSS classes in the markup". That's Separation of Concerns, not "stylesheets."

You're begging the question. And it's one question that can easily be generalized as a format-question: look at the operative words "use" and "utilize". Look at where they appear in the sentence.

goblin89• 13 years ago

"Do you use presentational CSS classes in markup, or do you fully utilize LESS/SASS?"

Are those even exclusive?

One of the projects I work with uses Ace “responsive admin template” (paid theme from Wrapbootstrap). In its styles, declared variables and nesting are used unpredictably, as is indentation and other whitespace, which leads to awful readability and flexibility. It does utilize LESS, but it also uses presentational classes (least of its problems).

Pure well-structured CSS can be much better. LESS offers some useful possibilities, but also a lot of new ways to shoot yourself in the foot.

My point is—what OP wants (I guess it's readable, elegant, maintainable code) depends more on coding standards than tools used.

thenerdfiles9• 13 years ago

You understood the point as to the nature of my question.

It's a fishing question.

dinkumthinkum6• 13 years ago

Maybe in your mind but in reality this could just tell you that the person interviewing saw one if the same YouTube ideas you d and started using LESS, big whoop.

thenerdfiles9• 13 years ago

A negative attitude is not "in reality".

tgrass• 13 years ago

To filter for those managers who will never be happy with anyone's work ask: "Who is your favorite employee? Why? How do you motivate them?"

jerryr• 13 years ago

I like the intent of this, but I'm not sure I'd ask "who", specifically. I personally would not feel comfortable answering that part of the question. Instead maybe, "How do you motivate your favorite employee?" If the answer is vague or too broad, the manager probably hasn't identified a favorite employee.

ye• 13 years ago

We don't have tests. - Get out

Maybe it's an opportunity to introduce automated testing.

I've worked at many companies where my managers wouldn't allot any time to develop automated tests and change the deployment to accommodate them.

Many companies are just not aware, because they never hired the people who are familiar with automated testing.

eropple3• 13 years ago

Many companies are just not aware, because they never hired the people who are familiar with automated testing.

Established shops mean established culture. If it doesn't already exist, and you aren't in a position of sufficient authority to make it happen without buy-in, this "opportunity" is probably more likely to be bailing out the ocean.

ShirtlessRod• 13 years ago

Like anything, often it's just a matter of selling it properly, even without "authority". Even at an established shop, if something will make a difference in the bottom line, it will likely gain traction.

I've been at a company with thousands of developers, where a guy that was just hired came in, saw a need for a tool that had been missing, prototyped something, and showed how useful it could be.

When there are missing needs like this, it's a tremendous opportunity for someone who is sufficiently motivated.

Of course, there's a balance between a good company that is just missing some things here and there, and a very bad company that is missing just about everything...

johnbellone• 13 years ago

Established shops mean established culture.

I work at a relatively large technology company (Bloomberg) and I have had great success in changing developer culture for the better. It takes a lot of elbow grease, many meetings and you need the gumption to ride through it but we've truly made the day-to-day productivity enhancements that we need for our business. In just this year my team has accomplished:

GitHub Enterprise deployment;
Massive project conversions from Ruby 1.8.7 to 1.9.3;
Adoption and training of AngularJS building reusable directives;
Utilizing Boxen to make developer work environments reproducible and deterministic;
Consolidating build systems (Jenkins) and integration with corporate internal systems;

We're really on a roll and I think once you gain the trust of management and they see the moral changing for the better you can really stop the world. But coming in from the outside I can see how this is intimidating and, roughly speaking, you need to consider most organizations are not going to give you the keys to the castle with merely blind faith. You need to disrupt a bit.

bowlofpetunias• 13 years ago

This applies to virtually any item on that list. The questions are good, but the lack of ambition bothers me.

But maybe that's just me, I would always prefer to work at the place that isn't 100% perfect but will give me the opportunity to change things. Much more of challenge in that than just being a replacement cog in an already perfectly tuned machine.

quanticle3• 13 years ago

There's a huge difference between "we don't have tests and we don't see the value in automated testing", and "we don't have tests right now, but automated testing and process improvements are something we're working on". I suspect you're talking about the latter, whereas OP is talking about the former.

Culture is a lot harder to change than code. If the people already there don't see the value in process improvement, then attempting to introduce any sort of process improvement will be a Sisyphean task. You'll make progress only to see it get rolled back time and again by teammates who just don't believe in what you're doing.

Take automated tests as an example. I have worked at a place where I committed automated tests and configured them to run before build. Then, I got a bug report for a module I had worked on and wrote a test suite for. The test suite should have caught the bug... had it not been disabled by another developer who'd committed the breaking change and, instead of investigating why the test failed, just dropped @ignore annotations until the tests passed again. That's the sort of thing that OP is warning against. Life isn't long enough to spend time bashing your head into walls like that.

dinkumthinkum6• 13 years ago

This is actually a very useful and insightful comment rather than the obligatory "What!? You aren't using tool X that I watched a YouTube vid about!? No way I'm working here!" responses you expect in these kinds of threads.

damncabbage• 13 years ago

There's a baseline level of competency I'm willing to work with. I've had to fight for basic things (like version control) over and over again, and I'm fed up to the point of not wanting to fight those wars again every time I join another company.

The lack of testing culture, for example, was what first drove me away from PHP (to Ruby). Every PHP role interview, I'd gingerly have to ask if they knew what Automated Testing was ("Yes? Great. Have you done any yet? ... No? You don't want to? Oh."), whereas at every interview for a Ruby role I've basically gotten a "Of course we're testing. What else would you be doing?" response.

Once you get past talking about things up to the baseline, you can start the real interview.

rmc12• 13 years ago

Maybe it's an opportunity to introduce automated testing.

Sure, but this is why you ask a follow up question, "why don't you have tests?"

If the answer is "We are just starting this project, and haven't done any yet. We'd like you to help us write tests", then that's an oppertunity.

If the answer is "Tests don't work, they're useless and never catch serious bugs. Our team is smart enough to not break things, and we have to move too fast to waste time write silly little unittests for everything", then there's no oppertunity here.

tokenrove3• 13 years ago

Ten or fifteen years ago one of the fastest make or break questions I would ask was "what version control system do you use?" (and of course, whether they were using nothing(!) or ClearCase or VSS or CVS would immediately say a lot about the culture there); version control is ubiquitous now even in lousy companies, so I think "what is your code review process?" is my new favorite question to get some indicators of the development culture at a company.

rmc12• 13 years ago

Even now, version control can tell you a lot. An organisation still use CVS, or even SVN, will tell you something.

dylam• 13 years ago

I agree with most of the things here except for the last part of no. 9:

"Beware of "I built an internal tool that..." or "I built a flux capaciting tool that..." or "I rewrote an open source tool because...". Some developers like to jerk off to rebuilding the wheel and wasting business money on projects that strictly aren't required or useful to the business as a whole. Like I said, I like to build products. If you feel like you needed to rewrite the compiler, you're probably awful, and almost certainly wrong."

What about DevOps and people who work on improving the work flow for other developers?

Otherwise, great list.

rch• 13 years ago

Why are you hiring?

This is a good one to ask, but tricky sometimes. I've heard answers along the lines of 'we keep positions open perpetually' for architects, systems analysts, data scientists, and the like. So I think to myself, that's great! It is fun to think I'll be a valued hire, and the friend who brought me in will eligible for a nice referral bonus. However, I am starting to think that if a company appropriately values experienced, talented leadership in the most challenging sectors of development, then these roles don't need to be 'always open' any more than entry level positions. My guess is that there's always a catch with companies that give this answer.

So what's a good answer? I'd prefer: 'we weren't hiring, but X thought we should meet you.'

sbov• 13 years ago

I don't quite get why internal tools are listed as "beware of". Internal tools are products too. At game companies they have teams dedicated to building just them. I'm sure most larger companies do too.

tokenrove3• 13 years ago

Indeed; according to this author, the guys at Naughty Dog were "awful" (writing their own compiler) during a period where I would have killed to work with them.

nilliams2• 13 years ago

Well, there really is a difference between people who are reinventing wheels for good (because they really know their shit) and people who are doing it out of ignorance.

I think it's usually fairly easy to tell which person is which. (Person is either a bullshitter you can quickly catch out, or is smart and inspiring to talk to).

wtracy• 13 years ago

Because you will end up investing a lot of time learning skills that don't transfer anywhere else.

Two of the last three companies I've worked at had their own internal version control systems. I'm sick of having to learn how to check code in all over again every time I start a new job.

quanticle3• 13 years ago

Yeah. This is one place where startups have a distinct advantage over established firms. Established firms tend to have home-grown build and deployment systems, either because they started writing code before open source versions of those systems became available or because of straight up NIH. Startups, on the other hand, aren't big enough to tolerate that kind of wastefulness. They use as much open-source and standardized software as possible, simply because they don't have the time or manpower to write non-business code.

ufmace• 13 years ago

The last company I worked at had one. How bad of a sign this is depends on when it was developed and why. Theirs was developed in the early days of VCS, when none of the off-the-shelf systems had the feature set that they needed. Probably they kept using it longer than they should have, I suppose out of inertia, but they were in the process of moving away when I left. In that situation, it isn't too bad of a sign.

On the other hand, if you ever find a company that wrote their own VCS 3 years ago that has half the features of Git, then run far and run fast!

MaulingMonkey2• 13 years ago

They're a potential indicator for NIH syndrome.

Good, well developed internal tools which speed up company work in a way that something off the shelf cannot, can be a good thing. Even the best internal tools, however, will require some ramp-up time for someone joining the company to understand and use them to their full potential. They require developing in the first place. The gains must be able to justify the costs, which even a good tool cannot always do due to the limited consumer base of an internal tool.

In less ideal circumstances, they can be unholy buggy unsustainable messes that actively sap resources for maintenance and are worse in many if not all respects than cheap off-the-shelf alternatives, even for the company's own specific needs. They may be kept alive by the difficulty of transitioning, other internal tools depending upon it, or misplaced attachments to the system ("we've invested too much into it to switch now!" etc.) or misguided approach to tools in general ("licenses are expensive, let's just build our own.")

philwelch5• 13 years ago

For larger companies, internal tools become absolutely essential.

temujin• 13 years ago

Yes, that point definitely should have been qualified better. If the new tool is much better than preexisting ones in important ways, it probably isn't a waste of time, and it could very well be a key asset.

But he does have a point in that the majority of rewrites are not significant improvements; you have to look more closely to evaluate this.

pseut2• 13 years ago

I think they're definitely "beware of" if it's the answer to "what's the coolest thing you've produced?" Unless, like you said, it's an interview for a position in a large company that's dedicated to building internal tools.

rmc12• 13 years ago

Their answer should be combined with the size of their organistion. Pretend, someone like google has their own internally developed web server. It makes sense, they have the manpower and the need. But when a 10 person tech team has their own internally developed bug tracker for no real reason, that's something to worry about.

pasbesoin• 13 years ago

The elephant in the room, for many of us: What would be my physical environment?

I like a challenging problem. I don't like fighting a bunch of extraneous noise and distraction while trying to concentrate on it. (Collaboration is just fine. Noise is not.)

I've yet to see a clear formula for addressing this concern in a neutral fashion (or, perceived as neutral or acceptable).

ricardobeat2• 13 years ago

Step into the office and take a look? In my experience your first impression is correct 9 out of 10 times.

walshemj3• 13 years ago

I got dinged for pointing that out at one agency I went to an interview at.

mooreds3• 13 years ago

Did you get dinged, or did you avoid a company that would have been a bad fit?

100k• 13 years ago

Any company that can advertise a quiet working environment would have a huge boost with me and other developers who care about that sort of thing. I'm not looking for a private office, but open plan offices with dozens or hundreds of programmers lined up seem incredibly depressing to me.

mooreds3• 13 years ago

I think it is OK to ask 'where would I be working? I find I'm most productive in quieter settings?'

Any interviewer that is offended by this seems like they work for a company worth avoiding.

thenerdfiles9• 13 years ago

If you're trying to remove or drastically limit the human element, that is a sign that you need to freelance.

rmc12• 13 years ago

You could ask to see where you'll be working?

davmar• 13 years ago

i've been trying to determine why this list bothers me because it's seems so reasonable, but i think i found it.

this list helps you identify a "goldilocks" product company. it's narrowly targeted at a specific subset of product-based companies at a specific growth stage with a very opinionated view of how the company should be organized.

try answering any of these questions from the shoes of microsoft or a no-name early stage startup. you cannot win in either case. i can only see a company like airbnb or dropbox succeeding in answering these questions to his satisfaction.

kudos to the author for knowing what he wants and what makes him happy. i think candidates will most likely need to compromise on more than a couple of these points with most companies they interview with.

edit: i absolutely agree that candidates should interview the employer as much as they are interviewed. and i think this list is very good. what bothers me is that it's hard to answer positively to all these questions, so flexibility on the part of the candidate is probably an important thing :)

na85• 13 years ago

Now you know why it was submitted to HN. Here we lionize the small percentage of startups that succeed and actually build something worthwhile, while demonizing the big fish in the pond, and pretending the heaps of failed startups never existed.

devanti• 13 years ago

right on. a large of big companies don't have things like automated testing

eitally• 13 years ago

Or they do, but only in a small niche where a progressive manager made it a priority and hasn't yet earned consensus among his or her peers. The same things goes re: NIH at most large companies. It's not that the homegrown tool is better, but if it's the difference between spending $250k on dev and $100k/yr on maintenance and improvements versus $1.5m on licensing, $500k on implementation and change management and another $250k/yr ongoing... those things get a lot of scrutiny. Especially when they're not driving the profit. As a couple of examples, let's look at homegrown HR systems vs things like Workday. Workday is loads better and they are constantly adding new features, but it is always easy to excuse a homegrown HR system because of innumerable edge cases in localized employment law, or ties to tiny payroll systems in third world countries that you've already built but no one else has, or .... Netsuite is having the same adoption challenges vs Oracle & SAP, too. It's not that the big guys are objectively better, necessarily, but that they've been around long enough and have a huge enough consulting arm (and external partners) to have seen almost every possible business scenario globally. There's a lot of value there, and it often leads to short sighted and myopic decisions.

I don't actually know that this is true, but I suspect the vast majority of programmers work for large, non-software-product companies, and most of them spend their time primarily on KTLO work, not any kind of innovation or profit creation.

perlgeek• 13 years ago

0) Do you use version control for your code, and if yes, what?

If they say "no" or "RCS", politely say that you don't want to be a part of that dev team. Unless they hire you as the only developer, and you see real chances of introducing some sanity.

This is not just about the way they store code; it's about the attitude towards tools. If they aren't aware of source/version control, or are aware but don't care, experience shows that they will be a huge pain to work with. Know a perfectly fine, open source library that does 90% of that task? Have fun getting permission to use it!

10098• 13 years ago

I would never think of asking this question since I have always just assumed that if you are building software, you are using version control. Apparently I was wrong...

lotyrin• 13 years ago

... Yeah. I spent one job emailing code files back and forth (and verbally acquiring locks at the file-level). I spent most of the time there trying to convince the team to at least learn how to use a patch tool and mail patches instead.

At another job they just had a shared drive with a single copy of each project and mandated we use a particular editor because it had an in-built locking scheme. There were a few conditions (e.g. crashes) that required manual lock manipulation before you could accomplish anything. People would often manually release locks out of habit, open a file for writing but just leave it open all day in the background while the lock-holder worked, save the old copy when they were closing up at the end of the day, thereby reverting a day's progress. There was no backup strategy in place. This wasn't the 90s or anything, git and GitHub were already established.

dyadic• 13 years ago

I once thought the same, and then I landed at a company where the source was contained across a mixture of svn, network drives and customer production servers.

However, I don't directly ask about VCS now, it seems overly focused for a question, instead I will ask how they produce builds, what the deploy pipeline is, and then track back if I find their answers alarming.

rmc12• 13 years ago

Oh those companies exist.... Much less now... but still...

sergiotapia• 13 years ago

Yep - I worked at a company where our entire codebase was inside a folder in our web server. We actually copied things locally and had to paste in changes via FTP.

I tried to make the team switch to something like Git or hell - even SVN - something to manage the code and not have it all in one point of failure but that fell on deaf ears.

Ultimately I create a private repository on Bitbucket and pushed the code there using Git and used that as my personal backup in case shit hit the fan.

brianmcconnell• 13 years ago

I would add a question about vacation policy as a signal about whether you want to work there.

Wrong answers: two weeks, or "unlimited" (because everyone knows there will be peer pressure not to use vacation time).

Right answer: four weeks, use it or lose it (as in, we want you to check out for a proper vacay a few times a year).

The definition of vacation = I am going to be on a beach/wherever, not checking email, probably drinking, and definitely not thinking about work.

Location is also important. If you have a 2-3 hour round trip commute each day, you'll hate your job no matter how interesting the work is.

mfringel• 13 years ago

"Four weeks, use it or lose it" wouldn't tell me whether people actually used the vacation or not... which is a somewhat harder question to phrase.

eru3• 13 years ago

At my current job, I have five weeks plus, and two of them are mandatory.

lbarrow• 13 years ago

"Unlimited vacation time" isn't always a red flag. I work for a company with unlimited vacation time (Braintree) and I've always felt comfortable taking vacations. In fact, in June I went to Europe for over 3 weeks, and I still feel comfortable taking time off for the holidays as well.

A "real" unlimited vacation policy is a strong positive signal about the company. It shows that (a) people are trusted to manage their own time and not to abuse the system and (b) the people who work there are good enough and driven enough to deserve that trust.

rmc12• 13 years ago

Of course, that depends on the country. In the EU, the legal minimum is 4 weeks that you have to take (or be paid for), some member states have higher legal minimums.

"Unlimited" holidays is a scam, unless they'll put in writing that you're entitled to 6 months holiday per year.

seivan• 13 years ago

Regarding #2 what if a person wants to be both. What should one ask then?

jakejake• 13 years ago

These are all really good questions. I think it's a great idea to have some questions in mind when you interview. It shows that you are interested in making an investment in a company and not just looking for a paycheck.

I would probably spread these questions out over a few people and not hit the same person with 20 questions. I would also be cautious of making the interviewer feel embarrassed if they are not following SCRUM to the letter with 100% automated testing and code coverage. Because in real world situations we are often striving for that but we don't always get to do it perfectly by the book. So it won't help if you make them feel even worse about it!

Silhouette3• 13 years ago

I'm not sure I'd agree with all of these. For example, the ones about automated testing or building internal tools sound a lot like "Do you like to work the same way I do?" and if the answer is no then the dubious assumption is that you know more about what this potential employer does than all of their existing staff. The list seems reasonable for the most part, though.

Aside from obvious questions about the kinds of projects you'd be working on and the skills and technologies involved, I used to rely on a few simple tests:

1. What is the employee turnover like, and if people have left recently, why? [This is a reasonably objective proxy for what the rank and file staff really think, and they collectively know this potential employer much better than me.]

2. Did they ask brain teaser type questions or do a pop-psych personality test in the interview? [Do their hiring practices suck, in which case even if they hired me, would I want to work with anyone else they hired? Also tends to indicate an unhealthy assumption of superiority and desire to conduct one-sided interviews, which is a red flag in its own right.]

3. Will they show me a sample of their production code and of the related documentation, and if so, what is it like? [If they won't and don't have a very good reason, my assumption is that they aren't confident their code will impress, which is not a good sign. If they will, what I see is about as good a marker for whether they're any good technically as any benchmark you can fit into an interview.]

4. What does the car park look like on the way in? [Far from scientific, but a handful of executive cars in reserved spaces and then nothing but old models in the few remaining spaces is rarely a good sign.]

5. Does the contract impose on my life outside of work? For example, would I need permission from the employer to take on an unrelated side job that had no bearing on my ability to work properly for them? Would they be claiming IP rights to any work I did unrelated to that employment, so that for example I couldn't release a hobby project as Open Source if I wanted to? [Any attempt to control life completely outside work is a fairly reliable red flag for a generally over-controlling attitude and/or a show run by HR/legal rather than sensible management or the people I'd actually be working with.]

tokenrove3• 13 years ago

I find it interesting that you decide that assumptions about software process maturity are dubious but are happy to make assumptions about the lack of utility of "brain teaser" questions or personality tests.

Silhouette3• 13 years ago

I find it interesting that you decide that assumptions about software process maturity are dubious

You appear to be making your own questionable assumption, which is that the techniques mentioned before necessarily imply a more mature software development process. If a development team didn't use automated testing, I'd certainly be interested to know why, but I can immediately think of multiple plausible alternatives that might have proven to be more effective for that team depending on the circumstances. Unlike the use of brain teasers and popular psychology to assess applicants' value as employees in technical fields, there is a significant body of empirical data to back up the effectiveness of some of those alternative testing strategies.

novaleaf5• 13 years ago

I totally agree with this. I personally do not use unit tests at all.

Why? Because I do assert-driven testing. My test code is integrated into the actual business logic. So no need to contrive scenarios.

ababab• 13 years ago

Could you expand on what you mean by assert-driven testing? I'm not finding any good explanations from a Google search. Sounds interesting.

eru3• 13 years ago

Without scenarios, how do you run your code before it goes into production?

rmc12• 13 years ago

So you do do tests, just not specifically separate unittests.

That's totally different from an organisation that doesn't do tests at all (yes they exist).

aabalkan• 13 years ago

Take a look at this post for specifically web developer positions:

"Questions to ask your future web dev employer" https://medium.com/what-i-learned-building/f7a161b5bc70

j1z0• 13 years ago

Given that I run a consulting company I spend a fair amount of time on each side of the interview table. Both recruiting for contractors to help with a project and trying to convince others that I'm the right guy / company to develop the system.

That being said I think this list of questions is excellent. I would be much more inclined to hire someone who asked these questions than someone that didn't.

Somewhat conversely as an interviewee I would be at least slightly concerned with a company if I had to ask these questions. This is basic ground that any good interviewer should cover in an interview and if thy don't they may not be looking for the type of development styles that I like most.

Interviewing is a two way thing both sides should be choosey and neither side should settle for something less than ideal. If we all found jobs / employee that we love then the workplace would be some much better off for it

erikb• 13 years ago

I like the list. Just for me personally there are some differences. From experiences I like chaos more then organization, because I can make more out of the chaos for myself. I don't feel so well today? Well in a chaotic company I can just stay home or answer emails. When I feel energetic I can also convince my coworkers to get a major feature done or an ugly bug fixed that was laying around for months.

Also from some of my colleagues I see that not everybody is really interested in delivering results. Some are just fine with doing what they are told, then going home and caring about their family. When the whole department/company thinks like that, then the life of these people is much better. It's definitely not for every engineer, but I think it's good such spaces are out there!

tptacek• 13 years ago

I think this is a thing that everyone goes through in their career at some (or various) points: you take an inventory of what does and doesn't work about the roles you've held, and try to turn them into a qualifying questionnaire for future roles.

That's fine as far as it goes, but one of the things you'll learn as you progress is that superficial process issues are actually not at the core of effectiveness; talent, vision, and ability to execute are. You want to be careful that your questionnaires don't blind you to opportunities to work in radically different cultures/processes that will succeed for reasons you don't yet understand.

Questions to ask your potential employer

Related Stories