Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As I move forward in my career new jobs become more difficult to choose between. When I was starting out and for the first 8 years of my career I took the jobs that I could get that would keep me programming on the general technological path that I was on.

I am a job hopper, I only stay with a company for between 2 - 3 years. I think that I do this because after 2 years I get bored and unless there are new projects to keep my busy I no longer find work interesting.

Now that I am becoming more experienced it is more important for me to only apply for jobs that are interesting and will move my career and my skill set forward.

My problem now is that I keep finding jobs where the projects appear to be interesting during the interview but once I get in the company I find the development environment is sub-par and the development team is disjointed. I feel like I am asking the wrong questions during the interview process and don't know what to look for to make sure that the environment I will be working in will be a good one.

Now my question: For those of you who are senior developers what do you look for in a new company and development team?

I am looking for the key qualities in a company and development team that you look for when interviewing with a company. These qualities are the ones that would give you hints that the company will be a good one to work for.

Update: Here is a list of questions that I have created based on the comments left here. There are a ton more but this will be the start of my list.

Good characteristics in a new company:

  • Ability to offer dependability and stability to an employee looking for a place to stay for the long term.
  • Financially stable.

Development enviroment:

  • SDLC
  • What software and/or tools are used?
  • What version control system is used?
  • What kind of project manangement structure is used and what tools are used to maintain it?
  • How do you ensure the quality of your products?

Development team:

  • How big is the team?
  • What skill levels are people at?
  • Where would you fit into the team?
  • What was the turnover in your team and company in the last year? Why did people leave?
  • How often and for what reasons is a person expected to work overtime?
  • What kind of development environment does the company have? Flexible, ridgid, laid back, etc.
  • Will my personal work practices be acceptable or will I be expected to conform to the rest of the team?
  • What does the team do for learning new skills? Training? Education? Shows? Conferences?
  • What was the last training that the company invested in for their developers?
  • How is conflict between developers handled?
  • How is conflict between developers and business users handled?

Joel test:

  • Ask the questions and find out what they will admit to.
  • If you can find an employee or former employee ask them to take the Joel test for the company.
share|improve this question

closed as not constructive by Yannis Mar 8 '12 at 14:35

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

Don't go through the front door. Network, meet people who work in different places, and get them to describe their situation honestly. –  Job Feb 18 '11 at 15:36
I must add that it is a necessary but NOT sufficient condition that the company is well-capitalized, so that they are not in survival mode and thus do not have to cut corners. Just because you can negotiate a good salary today does not mean that they make good $. Do your own homework. One exception too this might be when there is no competitor and market share to fight over, such as NSF-sponsored, non-profit work, etc. (However, this is just a guess). –  Job Feb 18 '11 at 19:35

9 Answers 9

up vote 16 down vote accepted

Ask them about their development environment and dev team during the interview process.

For development environment, I'd ask about the SDLC, what software/tools are used, what version control is used, what is done for project management, how documentation is written, etc. If you hear things you don't like, ask them if they'd be open to change.

For the dev team, ask how big it is, what the skill levels of the members are, what your role would be in it, etc

Don't forget, the interview is a two-way process - You're deciding if they're right for you in addition to them deciding if you're right for them.

share|improve this answer
Plus one, for the last paragraph. –  Coyote21 Feb 18 '11 at 17:12
-1: If you hear things you don't like, ask them if they'd be open to change.: I disagree. If you hear things that you don't like, don't harbor any expectation that things will change, no matter what is said during the interview. It's extremely difficult to inspire change in an organization. I'm not saying that it's impossible, buy I am saying that, often, it's not worth your while. –  Jim G. Feb 19 '11 at 15:32
@Jim: True, but we just went through the interview process and implemented a few changes based on our new hire's recommendation. A lot of things we just didn't know there was a better way to do. –  Rachel Feb 19 '11 at 17:02
I believe you, but this is not the norm, and even when changes are adopted it's often not worth your while, given how hard you have to fight for them. What's I'm saying is that you'd probably get more bang for your buck elsewhere. –  Jim G. Feb 19 '11 at 17:25
I said, "Don't hire me if we're not serious about making these changes and you're going to do <exactly this> to me." They hired me with enthusiasm and did <exactly this> to me. Companies that shoot themselves in the foot are like drug addicts. They just can't stop blowing their little piggies off no matter how much it hurts. –  Erik Reppen Jun 16 '13 at 6:32

I am a rarity in this field. I am an "over fifty" software practitioner. While I now hold undergraduate and graduate degrees in computer science, I was originally trained in this field by the military straight out of high school in the late seventies.

One word of advice that I will give you is that you cannot continue to job hop if you wish to have a long career. Senior-level (principal and advisory) software practitioners are held to a different standard than their younger peers. The two most important attributes that a senior-level practitioner brings to his/her team are dependability and stability.

One also needs to learn to distance oneself emotionally from the projects on which one works. A principal or advisory engineer gets it done, period, end of story! That means being able to complete projects that bore one to tears without complaining or threatening to quit. Principal and advisory engineers are expected to exhibit the same level of professional maturity as directors and executives.

share|improve this answer
Thanks for this advice. For the most part I have worked at really small companies and with small teams my entire career. In fact of the 6 places I have worked before here only 2 still exist. One of the 2 still around moved locations and I cannot work there. At the other one my manager and I did not see things eye to eye when it came to my career, abilities and interests. –  Amy Patterson Feb 24 '11 at 19:21
I'd upvote that last paragraph a million times if I could. This is the biggest thing I see lacking in the under 30 crowd, the attitude that they shouldn't have to work on anything that doesn't interest them. –  HLGEM Feb 24 '11 at 19:33
Has it occurred to you guys that maybe you had better incentives to be loyal to one company than they do? Pensions and 401K are rare. They're not likely to get social, much less a retirement plan. I've personally never been satisfied with an annual wage increase and my biggest increases always came from moving to other companies by quite a lot. Loyalty's a 2-way street. Modern US corporations aren't doing their part on that end. So yeah, if I can find more interesting work than pruning a symptom tree for more pay and you have no compelling argument for me to stick around, what do you expect? –  Erik Reppen Jun 16 '13 at 7:14

As you say, I am a senior developer, and that means that I have developed my habits and my specific ways of doing over the years. I am an expert in a number of fields, and I am pretty sure that my own way of doing things is one of the best possible ways that I could possibly use.

For these reasons, I expect that a new company or team won't waste my time.

If a company or team wants me, they should be willing to accommodate my idiosyncrasies. It would be very naive for them to expect that I would adapt to whatever ways of working they have.

I am not saying that I am inflexible, or that I won't be willing to change anything at all. It's not that. What I am saying is that one of the big things that a senior person can contribute to a company or team is, precisely, well-honed and mature ways of doing. Trying to change them defies all logic.

I do a lot of recruitment as well, and I apply this principle whenever I look for a senior person. I wouldn't be so silly to pay a big salary and go through the pains of hiring an expensive, rare, top-notch individual just to make him another cog in the machine.

share|improve this answer
This make you sound quite intractable, but I know where you're coming from. –  Alison Feb 18 '11 at 16:05
@Alison: I have the hopes that my answer could convey the equilibrium between respecting the special character of any senior person and the need of that person to adjust to his/her new environment. Nothing is excuse for being a jerk. ;-) –  CesarGon Feb 18 '11 at 16:09
Certainly not, and we're all special. –  Alison Feb 18 '11 at 16:11
It is a myth that older software practitioners are expensive. The non-management track software development compensation curve is bell shaped. Maximum individual contributor compensation usually peaks between thirty-five and forty years of age. That is the age bracket at which serious culling starts to occur. Non-independent individual contributors who manage to make it through this culling period experience a decrease in earnings due the to fact they must move to organizations that do not pay as well as the hi-tech sector if they wish to remain employed. –  bit-twiddler Feb 19 '11 at 13:14
@Amy P: I am not saying that I wouldn't be flexible. I am sayinig that I don't expect that my company asks me to be as flexible as junior people who are still learning things that I have already mastered. But, if the company asks, then I think I should oblige in most occasions, even knowing that it may be a not very wise move overall. –  CesarGon Feb 25 '11 at 10:09

I ask similar questions to @Rachel's and the Joel Test. I try to ask open-ended questions which generate discussion. That gives me a better feeling about the underlying values, principles and practices of the company or dev team, and it is also easier to detect if they are trying to tell what they think I'd like to hear instead of reality. One of my favourite questions is "how do you ensure quality?". The answer to this tells a great deal not just about the actual processes but of the general understanding of what quality means for that person. In one shop (let it remain unnamed) I got the answer "we have these two thick books written at our mother company which define our own in-house Methodology. Following this faithfully guarantees high quality". I knew instantly I will never work for that company :-)

Another important question is "what was the turnover rate in the company / team in the last couple of years?". And if people left, I also ask why. Of course I don't necessarily get straight answers, but I can read body language to some extent to detect when I touched on something sensitive :-)

A third important question for me is their relationship to work time, specifically whether they expect regular unpaid overtime. Pre-release crunches are OK every now and then (although even these are evitable). However, regular overwork means the company management most likely has very bad estimation and planning capabilities and/or they still believe that free slave work can create value. Either of these are an almost certain no-no for me.

I also ask whether anyone there has read Peopleware, but this is more like a personal interest than a good indicator, as so far I met only one interviewer who has even heard about it :-(

share|improve this answer

Joel Spolsky's test is a good indicator. (replace "you" with company you're considering)

The Joel Test

  • Do you use source control?
  • Can you make a build in one step?
  • Do you make daily builds?
  • Do you have a bug database?
  • Do you fix bugs before writing new code?
  • Do you have an up-to-date schedule?
  • Do you have a spec?
  • Do programmers have quiet working conditions?
  • Do you use the best tools money can buy?
  • Do you have testers?
  • Do new candidates write code during their interview?
  • Do you do hallway usability testing?
share|improve this answer
Employers expect this and do lie. –  Job Feb 18 '11 at 15:47
@Job: You can ask specifics on some of these. What source code control do you use? How do you make a build? What bug tracking software do you use? That doesn't work well for the second half of the list, but may catch some places you really don't want to be at. –  David Thornley Feb 18 '11 at 17:40
@Job: I agree. In fact, at my last job, the person at the other end of the table, without my prodding, told me that they could pass 'The Joel Test'. Weeks after I joined, I found out that this was not the case. –  Jim G. Feb 19 '11 at 14:05
Well you can tell if they didn't ask you to write code in the interview ;). As for the others some of them you can see walking around the office. –  Zachary K Feb 19 '11 at 18:11

I've been looking lately, and I've got about 15 yrs of experience (not sure if that's senior or not. :-)) and I'm looking for the following:

A good working environment in which you fit in, this will vary depending on what kind of person you are. Personally I prefer a laid back environment with a friendly work environment. Also make sure that its in a technology that you will enjoy working with.

If you going to be working for a company for god's sake make sure you check up on them and make sure that they are in a good position money wise. I wish I'd done this with a number of jobs but I didn't and ended up getting burned badly.

Make sure that its a place where you will be learning. Remember you are only as good as your current skill set to a new employer, so make sure those skills are kept up to date where ever it is you are going. Most employers these days don't provide training anymore from what I'm seeing, but at least make sure that you can use new technologies and techniques for projects.

Also ask around and see if any of your friends have worked there to get some information on the place. Don't ever take them at their word, always verify what they say, because more than a few employers will lie there ass off to you.

Also make sure that they are professional coders, this will be where the Joel Test can help. Also if you are talking to the programmers on the team ask them some technical questions right back to see how good they are.

Here are a few things that usually raise a red flag for me :

  1. You get x amount of pay but extra bonuses if you meet our goals. (These are bait and switch operations, the last job I had like this stopped the "bonuses" 1 month after I started.
  2. We now have x technology from 10+ years ago, but we want you to help upgrade us. (basically another bait and switch, if they meant to do any upgrading they'd already done it by now.)
  3. Also be careful of places that want to hire immediately. These can be good places but you can end up in a place where they don't manage the amount of work wisely, or have had a high rate of turn over.

In short make sure you do as much or more homework on them as they do on you.

share|improve this answer
+1: I fell prey to #2 at my last job. Never again. And the technology was literally ten years old at the time. –  Jim G. Feb 19 '11 at 13:58

Consider what makes an environment sub-par and what kinds of requirements do you have for your work environment. For example, how formal of a process are you wanting? Do you expect software tools for tracking features, bugs, code changes, continuous integration and code coverage? What kind of communication expectations do you have for that work environment? How long has this team worked together and how well thought out is the project?

Those are some initial questions that I'd consider in trying to get out what you want. I tend to ask questions about conflict resolution and how are various problems handled as this is something that matters to me to see what kind of answer I get. If I get a, "We don't have that kind of problem here," then I know to walk away from that position as I've worked in this field long enough to have a 95% confidence that that either they didn't understand my question, are that one in a million place that doesn't have this issue or are just lying to me. If I get something that seems like a reasonable, logical and mature approach then I know I've found something. Do people generally work extra hours? That's another question I tend to ask as some places may consider 60+ hours normal and others would consider it inhumane if someone works more than 37.5.

While I can claim to have a similar issue in some ways of running into problems a couple of years into a position, I do know some of the causes. In working on the same system so long, it becomes clear to me what kinds of problems will likely never get resolved as they are a low priority and there are dozens of other things to do before fixing these little things. However, if there are enough of these little things then I tend to see more of the warts of the system than the beauty of the system. Thus, I can become somewhat de-motivated and may want a bit of a change for a while to help reset how I see things which may or may not be an easy thing to do. In some cases new technologies came along that caused a massive re-write of a site that prevented this burnout problem as I can remember in my first job going from ISAPI C/C++ code to classic ASP to ASP.Net 1.0, where each re-write brought in enough new stuff that I didn't get to have my usual problems appear.

share|improve this answer

I am like you, but I probably get bored quicker. I'm always looking to learn something new. I have found that working for larger companies with a broader variety of types of work fits the bill quite nicely. There are times that I can work on 6 projects in a year and times where I do 1 a year. As long as you keep up a good reputation then projects are easy to find (usually too easy). It sounds to me like that is the type of environment you should be looking for.

share|improve this answer

A friend of mine once told me never accept a job if they offer it to you at the interview, It means one of two things:

1) They don't really know what they need so they will grab the first semi- plausible person.

2) There are so many fires to put out that working there will be hell.

I personally want to avoid both.

(of course the exception to this is if the person interviewing you worked with you for years before at a previous job)

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.