46

We hear much about code smells, test smells, and even project smells, but I have heard no discussion about employer "smells" outside of the Joel Test. After much frustration working for employers with a bouquet of unpleasant corporate-culture odors, I believe it's time for me to actively seek a more mature development environment.

I've started assembling a list of questions to help vet employers by identifying issues during a job interview, and am looking for additional ideas. I suppose this list could easily be modified by an employer to vet an employee as well, but please answer from the interviewee's perspective.

I think it would be important to ask many of these questions of multiple people to find out if consistent answers are given. For the most part, I tried to put the questions in each section in the order they could be asked. An undesired answer to an early question will often make follow-ups moot.

Values

  • What constitutes "well-written" software?
  • What attributes does a good developer have? Same question for manager. Who are your most valued employees/managers, and why?

Process

  • Do you have a development process?
  • How rigorously do you follow it?
  • How do you decide how much process to apply to each project?

  • Describe a typical project lifecycle. Ask the following if they don't come up otherwise:

    • Waterfall/iterative: How much time is spent in upfront requirements gathering? upfront design?

Testing

  • Who develops tests (developers or separate test engineers?)
  • When are they developed?
  • When are the tests executed?
  • How long do they take to execute?
  • What makes a good test?
  • How do you know you've tested enough?
  • What percentage of code is tested?

Review

  • What is the review process like?
  • What percentage of code is reviewed? Design?
  • How frequently can I expect to participate as code/design reviewer/reviewee?
  • What are the criteria applied to review and where do the criteria come from?

Improvement

  • What new tools and techniques have you evaluated or deployed in the past year?
  • What training courses have your employees been given in the past year? What will I be doing for the first six months in your company (hinting at what kind of organized mentorship/training has been thought through, if any)
  • What changes to your development process have been made in the past year?
  • How do you improve and learn from your mistakes as an organization? What was your organizations biggest mistake in the past year, and how was it addressed?
  • What feedback have you given to management lately? Was it implemented? If not, why?
  • How does your company use "best practices?" How do you seek them out from the outside or within, and how do you share them with each other?

Ethics

  • Tell me about an ethical problem you or your employees experienced recently and how was it resolved?
  • Do you use open-source software? What open-source contributions have you made?

Follow-Ups

I liked what @jim-leonardo said on this Stack Overflow question:

Really a thing to ask yourself: "Does this person seem like they are trying to recruit me and make me interested?" I think this is one of the most important bits. If they seem to be taking the attitude that the only one being interviewed is you, then they probably will treat you poorly. Good interviewers understand they have to sell the position as much as the candidate needs to sell themselves.

@SethP added:

Glassdoor.com is a good web site for researching potential employers. It contains information about how specific companies conduct interviews...

Community
  • 1
glenviewjeff
  • 1,405
  • 15
  • 17
  • 6
    from the title, the answer that leaps to mind is "like a dog"; please rephrase the question to be less...gross ;-) – Steven A. Lowe May 30 '11 at 18:10
  • 4
    @Steven A. Lowe: Agreed. There's no way to thoroughly smell a prospective employee that won't make the interview seem thoroughly creepy. – FrustratedWithFormsDesigner May 30 '11 at 18:13
  • @Developer, you're right it is essentially the same question, except that it belongs on this site. I'm not sure what the policy is about moving old questions to the new more appropriate sites, but I'm willing to consolidate them if possible. – glenviewjeff May 30 '11 at 20:26
  • @glenviewjeff doing due diligence on a prospective employer is not specific to programmers... – Steven A. Lowe May 30 '11 at 20:46
  • 1
    @Steven, the set of questions is likely specific to programmers. – glenviewjeff May 30 '11 at 20:50
  • @glenviewjeff: then it's just the title that's inappropriate ;-) – Steven A. Lowe May 30 '11 at 21:05
  • @glenviewjeff: fixed it for you. – Steven A. Lowe May 31 '11 at 03:16
  • 2
    Do you really want to be asking questions about Ethics in an interview?Also how thoroughly you vet your prospective employer is a sure shot indicator of how much he might not hire you. Do you want to risk appearing as all bark and no bite? IMHO only few and good questions ( most appropriate at that time and situation ) must be asked. – Aditya P May 31 '11 at 05:24
  • 1
    @Aditya, I'm afraid I don't understand your questions. glenviewjeff made it clear that he cares *more* about these things that just getting any job, so I don't see why he wouldn't ask. Otherwise he could just stay in his current job. – Benjol May 31 '11 at 08:08
  • @Benjol a lot of these questions cannot be answered correctly or factually as there are various factors affecting it and it will vary time to time and as per the person answering it.Knowing the answers to some might not necessarily apply or hold good as a reference as the various other factors have in all probability changed. – Aditya P May 31 '11 at 08:29
  • 1
    @Aditya (+1), I agree that it needs to be done carefully, and certainly not all of the questions need to be asked to evaluate the company. Many of the questions may be rendered moot once an answer is given that indicates that a weak area. The questions can also be spread across any phone calls and then spread throughout multiple people that are spoken to at the interview. Incidentally, I am less concerned about "getting the job" unless it's a good match with my values. I think part of getting the right job is working for an open-minded employer who is also honest and forthcoming. – glenviewjeff May 31 '11 at 15:44
  • Vet is unfamiliar to non-native speakers. –  May 31 '11 at 16:03

17 Answers17

14

Look closely at the product you'll create. I work for a good ethical boss but I really dislike the industry that we are in. I wish I would have thought about that before accepting the position. I am now trying to transition away from it but most companies don't understand the niche enough to evaluate my work.

mcotton
  • 685
  • 3
  • 9
  • 6
    +1 "dislike the industry we are in". Boy, there are enough of those! Lotteries, mass advertising, some finance areas, etc. I once worked for a guy who invented a popular database package. Know who one of the best customers was? The Polish secret police. It's not easy to do well *and* do good. – Mike Dunlavey May 30 '11 at 17:27
  • 2
    "Most do not understand the niche enough..." what niche is this? Now I am curious. – Chris May 30 '11 at 17:35
  • +1: Also "dislike the industry we are in". I once wrote software that enabled people to do derivatives trading. – Bob Murphy May 30 '11 at 18:18
  • @Mike Dunlavey, development of a mass-killing robot vehicles automatically attracts a sort of people, who will really like such a thing (not sure about lotteries though) – kagali-san May 30 '11 at 18:57
  • @mhambra sounds like a high-growth industry, got a link? ;-) – Steven A. Lowe May 30 '11 at 20:47
  • 1
    @mhambra: I once worked for a defense lab. I didn't, but the lab did, build computers and guidance systems for nuclear missiles. We got picketed regularly. The people doing the work were just like you and me. – Mike Dunlavey May 30 '11 at 22:36
  • I do home automation. It has all the downsides of working in the construction industry. It is making rich people lazier. It is also helping people with the opposite social, economic political goals as myself. – mcotton May 31 '11 at 00:29
  • @mcotton, well, I guess that's not quite as bad as all the alternatives people were guessing at in the comments :) – Benjol May 31 '11 at 08:10
  • @Steven @mhambra The Pentagon will spend about $5 billion next year developing drone aircraft, bombing is an important use case. http://www.herald-review.com/mobile/article_da4c3e76-8ba2-11e0-92cb-001cc4c03286.html – MarkJ Jun 28 '11 at 11:41
  • @mcotton: get to know some of these "lazy" rich people; chances are you'll find they work harder than you do - they just don't bother to do certain things that aren't a good use of their time. A "lazy" NBA star? As if! ;-) – Steven A. Lowe Jun 28 '11 at 15:28
14

Don't settle for one word answers

It's ridiculous to try and make an informed decision based on the employer using "Agile" or "SVN".

  • Ask questions that are your minimum criteria for working at a place, but get them involved in a discussion about it.
  • Ask to hang out with/work with/pair with a programmer for an hour.
  • Ask for a walk through of a typical day.
  • Ask what their standard release to production involves.
  • How often they work weekends, Holidays, late nights, etc.
  • Ask what process problems they are working on fixing

Smells

  • One word answers and a change in topic
  • Many late nights and weekends spent working
  • Antagonistic relationship with Ops or QA
  • Day-to-day involvement of the manager for task assignments and changes
dietbuddha
  • 8,677
  • 24
  • 36
9

Find out about the people who work there.

Processes are nice and all, but processes are implemented by, and followed by (or ignored by), people. If you have the right people, you can adjust the processes as needed.

For each of your questions, I would add meta-questions, e.g.:

  • Who decides what constitutes 'well-written' software?
  • What if there is disagreement?
  • How do we evaluate whether our definition is helpful?
  • How do we update our definition as state of the art or company priorities change?
  • What are the processes for creating 'well-written' software?
  • How do we evaluate those?

and so forth.

Alex Feinman
  • 5,792
  • 2
  • 27
  • 48
  • 1
    I like your questions very much, but I'm not sure what answers I would want to them, and even if I knew, I'm not sure they would be as important as a clearly defined and documented idea of what constitutes well-written software. The answer I'm looking for is the list of "-ilities," understable, maintainable, extendable, etc. How that's implemented will change over time, but the "ilities" should not. If the company values these, and a particular employee doesn't like it, I suppose the answer I'd like to hear is that they would patiently try to convince the employee. – glenviewjeff May 31 '11 at 16:44
  • 1
    +1. I was lied in an interview about my potential role. It is difficult to lie to someone who does the same work as you. – Dimitrios Mistriotis Jun 28 '11 at 13:26
8

I'll add a caveat to this after several bad experiences: Many companies will lie or mislead you about their answers, especially in situations where you can't easily verify it without looking at their code (which they will never let you do).

For instance, if you ask about Version Control they may say they use Subversion, so you think okay good they use SVN. Except they don't have repositories set up properly, or everybody has their own repository, or they don't understand branching/merging at all. You can't verify that kind of thing.

Same goes for actual coding practices. If you ask them about coding standards they might tell you they follow, let's say, the "normal Java conventions". Upon taking the job you find they use Hungarian notation (I hate to pick on poor Hungarian notation as much as I do, but it's the first thing that pops in my mind all the time), refuse to touch any open source packages outside of Java itself, and basically write code very poorly compared to the "standard" of writing Java. Again, you cannot verify that without actually saying "Show me your code" which they will refuse.

Sure, you can find out if they're lying about testing by asking what unit test software they use ("The Visual Studio Debugger" is not a unit testing application...) or if they don't use version control at all, but you won't know if the code is bad.

On the non-coding side of things, again it's very hard to actually tell what is embellished. They might tell you one thing (everyone always makes their company appear amazing in interviews) and taking the job it turns out completely different or obvious lies. I hate to say it but many companies are founded on a "smoke and mirrors" approach and that stench permeates every corner of the place. As always there are exceptions, but I have yet to find a good, solid way of gauging the worth of an employer until I actually take the job and, if necessary, leave immediately upon finding out it's no good.

Wayne Molina
  • 15,644
  • 10
  • 56
  • 87
  • 1
    I have worked for many companies where the rosy picture painted during the interview is laughable once reality hits. I wouldn't look at it as if the interviewers were outright lying, and give them the benefit of the doubt that they may actually think they were being completely honest with you, but didn't think about things the same way. I think that's probably why it's best to make sure the questions are answered with enough detail that unless they do explicitly lie, you will have a better idea what you might be "in for." I.e., ask them to explain their branching strategy. – glenviewjeff May 31 '11 at 15:52
  • @glenviewjeff Agreed 100% there. Often being more in depth than usual results in being able to figure out when you are being fed the "company line" and the environment isn't really good. Another thing I'd add to the list of what to ask is about their coding standards (variable naming, and the like): A good "best practice" style is good, no style at all or very strange styles are often bad. – Wayne Molina May 31 '11 at 18:13
  • I havn't had a problem getting to look at code once I signed the NDA. – dietbuddha Jun 01 '11 at 05:23
5

One thing i ALWAYS do is ask to be shown around the companies working / office areas (as opposed to nice corporate boardrooms where you get interviewed). This gives you an idea of the working conditions, equipment used, demographics of your colleagues and general vibe of the place.

... And yes I learnt this lesson the hard way :(

NWS.

NWS
  • 1,319
  • 8
  • 17
  • Very good idea as well. Too many companies have shitty working conditions (tiny cubes, open spaces) and "hide" the poorer members of the team so people don't notice them and run away screaming while only showing the posh areas of the building (executive offices, meeting rooms, etc.). I make it a point now to always ask to see the developer's area. – Wayne Molina Jun 28 '11 at 12:16
  • +1 Also make sure you see the locations that matters to you. ie the place where you team hangs out, the kitchenette, the cafe, your teams' desks, meeting rooms etc. – tehnyit Jun 28 '11 at 12:46
5

Another thing I thought of: If you ask the interviewer what they like/dislike about the job, keep this caveat in mind:

The "good" answer is one that mentions the good and bad parts of the job

If the interviewer is all giddy and telling you how amazing the company is and how great the job is, be careful as it could mean the interviewer is a "Smithers" and is just a corporate yes-man and ass-kisser - many people, especially those complacent in their job (read: got promoted due to tenure without skill so wouldn't be able to find work outside of this company) tend to "buy into the company line" and wouldn't ever be able to see any problems even if there are problems. This is not always the case, but if you get an answer that smells like somebody drunk on corporate kool-aid you should investigate further to make sure.

On the flip side if the interviewer starts to rip into the company, it's a huge red flag because, obviously, they aren't happy with their job and more importantly they can't bring these concerns to anyone in the company since they have to vent to somebody that won't snitch on them for not being happy; again from experience I have seen places where if the executives think you aren't happy (for legitimate reasons or otherwise) they will fire you immediately, so everyone just pretends to be happy all the time because they can't tell anyone they don't like X about the job or they'll be shown the door.

Wayne Molina
  • 15,644
  • 10
  • 56
  • 87
2

I'd move code reviews either into their own section, or as it's own point under improvement (not testing). I'd also ask what kinds of reviews they do: Do they encourage pair programming (an immediate NOT A CHANCE IN HELL from me usually ;))? Do they do reviews prior to every commit? Do they do quarterly group reviews (this could also fall under mentoring)?

For me, when evaluating a company, I do ask a few specific questions, mostly related to the Joel test, but rather than concentrate on those (especially with a smaller company), I'd rather concentrate on the person I'm talking to and their passion and drive. Even at large companies, more times than not, you'll find similar personal and professional characteristics throughout the employee base. So, chances are that if the person who is interviewing you isn't driven and passionate about what they're doing, other will not be either. For me, passion is much easier to determine how I will enjoy working for a company than going through a list of questions, even over the phone (I recently spoke with a CEO from a startup whos passion and excitement was absolutely infectious, so I know it's possible :)).

Passion determines a solid company far more than a list of black and white questions. You can encourage and help steer change in a passionate company with a broken development process (you'll find that if they love what they do, they're always willing to change for the better). However, a company (or leadership) with a lack of passion but the best process in the world will always be a drag to work for..

Demian Brecht
  • 17,555
  • 1
  • 47
  • 81
  • +1 for the "smaller company" part and the passion argument. Formal code review and team evaluations are less important when you're working in a small team full of passionate, skilled programmers. – tdammers May 31 '11 at 09:11
  • To me it's less about the specific implementations and more about the culture and how open-minded the organization is and how truly interested they are in continuous improvement of the company as well as the individuals. – glenviewjeff May 31 '11 at 15:47
2

Glassdoor.com is a good web site for researching potential employers. It contains information about how specific companies conduct interviews and what salary you can expect for certain positions.

All of their information comes from community members, so it may be a small sample size.

Despite that, it seems like a great place for people to discuss their interview experiences.

Britt Wescott
  • 1,220
  • 1
  • 17
  • 25
2

You haven't mentioned any quality of life questions. Especially frequent issues in software development companies are problems with scheduling and hours, so I'd ask about how often people come in each week and how long they are there. Although I'd try to find a subtler way to say it, so as not to imply that I don't want to come to work.

jhocking
  • 2,641
  • 19
  • 18
  • good point, although I can't imagine that if the other questions were well answered, that the same company would fail to recognize that "quality of life" is important to employee satisfaction resulting in higher quality of work. I suppose it couldn't hurt to ask the employees what kinds of hours they work, including how often there is "overtime" or weekend time, and how often they telecommute. – glenviewjeff Jun 05 '11 at 16:26
  • 1
    If it wasn't that so many companies are clueless to the benefits, I would *always* ask how much flex time is available; developers do **not** like to work rigid hours like factory workers - I'd love an environment that understands this and lets you come in later but eat lunch at your desk or leave a little later, and not this "You must be in ze office at 8am sharp or you von't be comink in anymore" garbage that you find so often. – Wayne Molina Jun 28 '11 at 12:18
1

Some has touched on this but not specifically: ask for things you hate as if you liked them. For example, if you dislike the idea of paired programming (to take an example from Demian Brecht) do ask about it.

Finally. always ask: "What is the most frustrating thing about your job?"

Sardathrion - against SE abuse
  • 3,706
  • 3
  • 19
  • 34
1

Try to find some of the employees' Twitter accounts. If you see them mentioning overtime or long work hours a lot, it might be wise to investigate a bit more or even avoid the company.

Tom van Enckevort
  • 193
  • 2
  • 9
1

I would always recommend trying to find out what a company is like before deciding whether to work there. There are places where you can find it – websites like http://www.whataretheyreallylike.com – where employees review their own employers. They can’t tell you everything, but they’re worth a shot, eh?

gurgling_mrd
  • 11
  • 1
  • As long as it's taken with a grain of salt (see earlier comment regarding Glassdoor), agreed 100%. Seeing what employees think of the company can often help if you can weed through the "dreg who couldn't work anywhere else so makes the company their life and thinks it can do no wrong" and "disgruntled person wanting to ruin the company due to some perceived sleight" type of reviews. – Wayne Molina Oct 19 '11 at 13:46
1

Ask to meet with someone familiar with the automated software deployment process. If they say, sure, you can meet with Joe or Mike, then fine. If they are vague, then you have your answer.

Christopher Mahan
  • 3,404
  • 19
  • 22
1

Apart from the technical questions, I would also throw in some business related questions. Such as...

1) How is your business going to support my employment?

2) What is the business model that your company is using?

etc..

tehnyit
  • 1,469
  • 2
  • 10
  • 16
1

Depending on how the interview is going, and how much rapport you have built up with your interviewer, i think it ok to ask 'Why shouldn't I work here?' after all people dont usually leave due to the selling points of the company, they leave because of the bad points, but if you know in advance what they are, then you can assess whether you can deal with them beforehand.

Jim Dagg
  • 103
  • 5
NWS
  • 1,319
  • 8
  • 17
0

Companies often hire those recommended by their employees. If you network in your own geographic area by attending code camps and other dev related meetings, you can find out from employees of other companies what their conditions are like in what is far more likely to be an honest fashion than in an interview. Then you know who to apply to. And you also have people who work there who will recommend you.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
0

Make sure you are associating yourself with quality people who are under managment that recognizes they are quality people. I know that's subjective and so is your preference for where you want to work. You'll have to determine what you think is important. You can have a long list of questions, but you'll probably be able to figure out the people on your own. We tend to be able to smell our own kind.

They may not be implementing the best practices, but are capable of doing it and are in the process of improving. Are you going to pick a company that wins on the Joel Test by a couple of points only to find out they are all set in their ways and have not desire to improve? I personally would have a problem with that. Even a perfect score won't last forever if they can't continue to attract quality people.

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • I may be in the minority here, but I really don't think the Joel test is by any means sufficient to determine the quality of a workplace. My former employer would have scored pretty well on the Joel test, but was terribly dysfunctional, closed minded, and inefficient. – glenviewjeff Oct 19 '11 at 16:33