For those of you who are senior developers what do you look for in a new company and development team? [closed]

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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 :-(

Answer 5

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?

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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)