How did you find your "dream job" (or great place to work)?

Question

I'm a senior developer and consider myself very good at what I do. I have high expectations for how I believe software should be developed. I'm having a hard time finding a place to work that shares a similar view on the software development process.

Here's my modified version of The Joel Test that I ask potential employers during an interview.

• How do you determine the requirements for your system?
  • How do you document these requirements?
  • How are they prioritized?
  • What does your schedule typically look like?
• Do you practice "test first" development?
• Can you "build" in one step?
• Do you build (and run automated tests) daily?
• Do you use source control?
• How do you manage releases?
• Do you have a bug database?

I find it surprising that many companies never speak to their users to determine future requirements, have no automated tests, do not use source control, cannot build their systems without an IDE, and do not manage bugs or releases. Further many of these organizations don't realize that they have a problem, and therefore are not interested in implementing them (one place even commented "Hey, We're process lite!)

My questions are:

1. How do you identify the "good" places to work (i.e. the places I should be focused on getting hired at)? To this point, my network has been of little help here.
2. Are my standards too high? Do organizations that practice development in the way I'm describing actually exist? I've developed this list by reading and listening to people like Spolsky, Fowler, and the Poppendiecks so I'm assume their writing are at least in part based in reality.

Thanks!

Answer 1

I'd add that you have to believe in the company's product(s).

If you don't, it doesn't matter how "good" the place might be.

Answer 2

If you can't find such a company in your area, maybe you could consider starting your own. You already know that you'll be better than the local competition!

Answer 3

While I certainly dont want to work at a shop that hasn't the slightest respect for programming and throws standards and best-practices into the abyss, my dream job is dictated more by the work I am doing:

1. Am I working with interesting technologies?
2. Am I enthusiastic about the product?
3. Am I going to want to go to work when I wake up?
4. At the end of the day, will I be proud of my work and my accomplishments?

Answer 4

While I completely agree with the Joel Test in terms of the tools to perform your job, a commonly overlooked requirement for a pleasant working environment is your social relationship with your management and your peers.

One of the largest contributing factors to my being happy at many of the jobs I have had is the word of mouth of the friends who have recommended the job, and even let me use them as a reference.

Answer 5

You didn't say where you lived.

I live in a low population area and had a hard time at first. Then I put specific searches on Indeed, SimplyHired and Craigslist and added the result pages to my RSS reader. It took six months from the time I started, but I eventually found a company that values the things I do.

In a bigger city, I would be checking out job boards from Joel, 37 Signals, and DailyWTF.

Answer 6

The things I look for most is the attitude of the people running the place. If they are public or plan to go public, it's a negative, if they are funded by anything but existing sales, then big minus. If they are Google, big plus, ...

The owner of my current (very small) company is really great--not really out to make money, no thought about going public, an engineer that enjoys solving problems more than running an empire, so well respected in the field that customers call him rather than the company having to sell itself; and no real desire for growth (except that the projects we are on are demanding it). In a small company that's perfect!

We also virtually never work more than 8 hours a day and out of 20 employees, there doesn't seem to be a single personality conflict (Unless it's me and they just aren't saying anything).

I'd say don't ask here though, consider what you have liked--for every person it's different and what I think is important may not interest you at all.

Also, consider it a fact that you will probably change jobs every 3-7 years. Use that fact to try different areas and find what works for you and what doesn't.

Life is a pretty long race, don't get winded right off the bat, stay in for the long haul :)

Answer 7

I feel your pain. I think the biggest tells for me are the quality of the other developers. To some extent I try to get a sense of this from asking things like

-what's the turnover rate among developers? (this one hasn't helped me as much as I thought it would)

-what are the quality of the interview questions? If they're too easy then it's likely that people with insufficient skill have passed them, and it's also likely that they don't know what to look for.

-what kinds of tools are they using? Some tools are more commonly associated with high-functioning developers. Some places don't even get source code control.

I've only intermittently found work that's good or great in the sense you're talking about, often because I ignored the warning signs or (more likely) just needed the work.

Answer 8

Answers to Your first question:

• Use Your network. Ok, in Your case, that does not seem to help. Try anyway.
• Use Your modified Joel test in the interview.
• Ask Your potential new co-workers, how long they have been working for that company. (The longer, the better. Bad working conditions cause shorter durations.)

Answers to Your second question:

• It depends on the field You are working in.
  • If You look for an application in security related fields (e.g. car manufacturing), then Your expectations are right.
  • If You look for an application in standard customer software (e.g. computer games, office tools), then Your expectations might(!) be too high.

It is sad but true, that in some fields, a dirty hack has a higher marketing potential than software produced in a process that passes Your test, because

• The hack will be available. (It is sold before it's finished.)
• High software quality is not the most urgent design goal. (compared to release dates and marketing-friendly features)
• The first version of the hack is extremely cheap to produce compared with proper software development. The next version of the hack may be impossible to produce, but that does not matter to the average manager.
• Last but not least: A proper development process is often seen as overhead. Most of us know that this is not correct, but management and marketing have their own sources of knowledge.

Answer 9

A good step is always to try selling yourself and your unique talents. Every programmer with an interest in programming has their own mix of talents which makes them unique. Don't look for job postings--look for organizations that could benefit from what you do. Approach them well-prepared to explain to them what it is exactly you do and how it would benefit them.

Another perk of this approach is that you might be blazing a new trail for the group you're working with, meaning you might be able to be your own boss in many ways.

It's not a career path for everybody, and there's a lot of proving yourself involved in it (so be prepared to walk the walk) but I managed to land a development job which directly applies to my master's thesis topic where I still get to do a lot of learning every day this way.

Answer 10

Your standards are definitely not too high. Software development is never easy, but it can be as hard as one makes it. I can see no reason not to use tools like version control software, bug databases, and automated testing. One might make an exception for a project scoped so small that you expect to complete it in under a week, but in that case you wouldn't need to be hired for a full-time job to work on it.

As for how to find a good employer, I think you are already on the right track by being picky and asking lots of questions. Strive to work for the smartest people that you possibly can.

If you have to, you should take the best job available to you at present and continue to shop around in the off-hours. You might think that having a job already would make you unattractive to other employers, but in the software business I've found that the opposite is often true. When interviewers ask you why you are leaving your current job, tell them that you are looking for more ambitious work.

edit: Addtionally, I agree with Lou's advice that it's easier to find a good tech employer in a densely populated area. Personally, I was fortunate enough to be hired away from my home town by a developer in a major urban center, and they paid for my relocation. I had three tech jobs in my home town before moving, and none of them were as good as the job I have now.

Answer 11

One question you could ask is "how has your development process changed over the last two years".

A software team that doesn't have a perfect score on the Joel test (or any process evaluation measure) but is evolving is a good sign.

At the other hand of the spectrum, I'd be afraid of a team that jumps on every new fad, and answers your question with piles and piles of buzzwords.

Answer 12

I quit and started working as an independant consultant. It can be hard work but I'd never go back.

• I make my own decisions about my work environment and the tools I use.
• Negotiations happen on equal terms instead of being dictated to me.
• People treat me with more respect even though I'm doing the same work. They know I'm free to pick and choose my projects.
• Corporate politics are amusing instead of frustrating when you are not an employee of the company.

Answer 13

I've got one question I always ask in job interviews, usually after a couple of Joel Test-style technical questions:

"What do you enjoy about working here?"

The look on their face for the five seconds after you ask will usually tell you everything you need to know. Usually, everyone ends up spouting a canned PR "we're awesome" response after they've had a chance to think about it, but their initial reaction tells volumes. The current all time worst reaction I ever got was the two guys interviewing me going "ummmm..." and staring at each other for, and I'm not joking, 30 seconds. "... the people?" one finally stumbled out.

On paper, the job looked pretty good - decent pay, decent tech, sane sounding development standards, but after a response like that I knew it wasn't worth my time.

Answer 14

1. The vast majority of companies do not meet your criteria. Developers are focused on the task at hand, get the code out the door cultures. I believe this is true for IBM to 37 Signals to Apple to Woot! I'm certain that there are folks who jump out of bed to go work at those places and others, but the majority of developers are just regular folks that attend PTA meetings and boy scout camps with their kids.

2. No, your standards are great! But rather than look for a company that already meets your standards, find one whose IT department would like to move in that direction and champion change from within. I'm worried you would simply look forever for the perfect fit when something close might do.

Answer 15

If you have already determined that you need to move on, I'm assuming there is something that is unacceptable with you current arrangement. That might be a good place to start when analyzing other employment opportunities. No sense moving to "same stuff, different place".

The problem is usually in pin-pointing what defines "good" for you. If you know already, great - if not, a list of things that are important to you in terms of employment always helps me sort out my emotions from the facts. Your list of items above seems heavily weighed on coding/programming specific things - you may want to consider some other factors also, like:

• do I like the people I work with?
• do I like the commute/can I work remote?
• is there a dress code / do I care?
• free soda? :-)
• salary (obvious)
• benefits

When I've been at the point of considering career options, something that helps me is to take all of the things I need to consider, and listing them out. I give each item a 1-10 value for each employer I'm considering. This gives a "weight" to each item, and helps balance out things like "dress code" and "salary".

Sometimes even just the process of making the list and taking the time to really think about all of the things that make up the job as a whole gives a different perspective to everything.

Answer 16

I'd start by looking at the job you will be doing there. I've found that the work you'll be doing trumps the environment.

For instance one of my life goals was to write my own programming language, the company I now work for has our own programming language as part of our software and I'm in charge of the language compiler/development.

Answer 17

1. Identifying the "good" places can be in part by looking at where some of the people you look up to develop. For example, I have seen a few developers come from a company called "Thoughtworks" and may try, try, and try again to get in there. If your network isn't much help, try expanding your network would be my suggestion as well as talk to people about why they like this place or that. Sometimes a good place will pop up there.

2. No, there are some places that develop like you describe. However, they aren't likely to have big signs on the front saying, "We want refactoring specialists," so you may have to find an alternative way in. Another idea to change the process where you are at, if you have enough clout. Sometimes doing things in a better way can grow in a company if they start seeing the dividends of doing so.

Answer 18

I found my current company by sheer luck, but I can share some of the important reasons I've spent well over 10 years here:

• Size: we're still small enough that we all understand the impact of our daily activities on the company's success. We feel the "bottom line" every day.
• People: I respect and enjoy the people I work with--both employees and customers. We appreciate each other and laugh a lot, even when things aren't going smoothly.
• Opportunity: With more work than resources, there's always another hat that needs a head beneath it. Also still a forest of trees with low-hanging fruit. You can't avoid success if you look for it.
• Policies: they're designed for humans, with lives outside the company. We understand what needs to be done and are flexible about how. It's ok to ask for forgiveness instead of permission when we're behind your motivation.
• Technology: We need to stay current to be competitive. Developers, Sales, and customers think our products are not only useful, but cool.
• Growth: I learn every day. The lessons are not always technical. :-)
• Challenge/Adversity: There's still an awful lot that isn't "right," and it's a challenge to inflict your point of view on coworkers at various levels. You don't always win, but you're heard, and you learn that a combination of tact, assertiveness, transparency, and sneakiness often works wonders. And being the "inflictee" is equally helpful for me.

And, for me, perhaps the most important:

• CHAOS: Plans and schedules notwithstanding, I never know exactly what I'll be doing tomorrow. Priorities shift, opportunities and emergencies arise constantly. In addition to my primary responsibilities as architect and engineer, I sometimes find myself in management, tech support, counseling, sales engineering, HR, business development, training, QA, manufacturing, customer (and employee) retention, IT, ...

  I'm required to think on my feet, solve unexpected problems, and sometimes, it feels, walk on water. (I have a long way to go, but I often manage to swim.) Becoming bored or stagnating is simply not possible.

Want a job? :-)