Dealbreakers for new programming jobs?

Question

What might be said or implied at an interview or job posting that should set off alarm bells for a coder?

I'm still only a few years in the industry but I already know to look out for excessive red tape and bureaucracy. Cubes and a noisy office also tell me that I'll be both miserable and unproductive and that management does not appreciate what coders need to work well.

Edit: The way things are going I'm taking extra time to look at the company's stability. If they depend on a single vendor for their livelihood and could be out of business if the vendor decides they don't really need the service or can do it in-house.

What are your dealbreakers?

Answer 1

• Inflexible working hours.
• The lack of ability to own code I write on my personal time, on my personal machine, that are not related to anything work-related.
• Lack of source control (like other have mentioned).
• Overly-rigid coding standards, or overly rigid application thereof.
• Lack of (sanity in) code reviews.

Answer 2

Actually, the opposite. Not enough process, no source control etc.

Answer 3

• No source control
• No centralised bug tracking or project management
• Performance measures SLOC / Check Ins
• VB6
• VBA
• Access databases

Answer 4

You might want to have a look at The Joel Test, an article Joel Spolsky wrote a few years back giving coders a 12 step guide to evaluating a prospective employer.

Answer 5

I'm about to start a 90 day contract-to-perm job where they have a dress code, and you're not allowed to have anything personal on your desk except one photograph of your family. I'm pretty sure it's going to suck.

Update: Well, the rumours about the "nothing personal" were wrong, there were things I liked about it and things which sucked, but they ended my contract before I could find something else, and that really sucks.

Answer 6

I would apply the Joel Test. Scoring poorly on it, with the possible exceptions of 9 (I don't need the best tools, but I do need good tools) and 12 (hallway usability testing might not be appropriate for all projects), might mean that it isn't the best working environment (and therefore possibly not the best job).

Answer 7

Lack of process and documentation, when they say "Yes we're implementing that." tends to really mean "We know we should be doing that but aren't at the moment".

If you enjoy pouring through hundreds of lines of code just trying to work out how things work, spending hours to make relatively simple changes, relying on the patchy knowledge trapped in the heads of your co-workers don't let this put you off in the slightest.

Answer 8

"You'll be able to work in <insert fun language here> really soon but just for a couple of weeks you'll have to maintain our MUMPS/COBOL/VB4 application..."

"Unit testing - yeah, we've heard of that. Sounds exciting. Have you done any?"

Answer 9

The deal breaker for me is when i look at the books in the office and there is nothing but programming books.

For me personally I like to see a good mix of books on the business of software development, efficient development process etc. It tells me that there is at least someone there who want to understand the end to end process.

I've worked in several companies where I've had to initiate development processes etc. that i now want to see that the foundations, of sorts, is already there.

Answer 10

This is the bitter voice of experience talking. ;-)

• When the interviewer does not seem happy with his job
• When the interviewer does not give you firm assurance that you'll be doing what you want to do ("We also have some REXX programming that we do..." means you'll be a REXX programmer)
• When the company doesn't keep their systems up to date ("We still use Windows 2000 and .NET 1.1")
• When the company is not financially healthy
• When management doesn't understand software development or doesn't see the benefit in good SCM practices

And, the aforementioned Joel Test... But failure of the Joel test isn't as much of a dealbreaker as if the company is not open enough to want to succeed at it.

Answer 11

A big red flag for me is if I get the feeling that I'm walking into a situation where I'm going to be the best dev in the shop, unless I'm going in knowing that I'm going to be the lead. If they're wallowing in mediocrity, I'm likely going to be miserable.

Also, if my spidey sense tells me that they know a lot of buzzwords but don't actually know a lot, I'm running for the hills.

If they code by the seat of their pants, that's trouble.

I can zone out noisy work areas (I wear my headset a lot) so that typically isn't an issue.

Answer 12

Lotus Notes. This is by far the worst email program I've ever used.

The way I look at it is... if they can't put a decent tool in place for something simple like email, what are the chances that your development tools are going to be any good?

Answer 13

• Lack of integrity in the boss
• Dysfunctional teams, especially if you can tell during the interview
• No time to learn or explore
• No mentors (unless that's why you're being hired)
• Unwillingness to invest in technology
• Draconian process or no process, both are bad IMHO

[EDIT] A normal work-week of more than 40 hours

Answer 14

1. You get an instruction by the employer to be formally dressed for the interview
2. All those that are interviewing you are not programmers (or dont have a background in it).
3. They tell you that you need to be in the office everyday at 8 AM.
4. You cannot own a laptop because you cannot take code home for security reasons.
5. They tell you that you will interact with testing/documentation people once every quarter.

Answer 15

If the interviewer is curled up in a ball in the corner, mumbling 'death march'

Answer 16

Many good answers - I'd add checking out the dev to tester ratio - 5D:1T or lower being good, IMO.

Answer 17

"We use a modified waterfall workflow methodology."

Answer 18

Noisy and Cubes is not necessarily a bad thing. It can sometimes mean that you're working in an energized interactive environment.

It comes down to the sort of environment that suits your style. I like working on a team in close proximity to others. My best programming experience was in a room with 4 others with no walls, a conference table in the middle and a huge whiteboard nearby (as well as whiteboards at each desk). It was incredibly collaborative, creative and productive.

Those 4 years created a valuable foundation for the rest of my career.

Answer 19

First, what breaks the deal for me may be the one thing that gives you an easy, peaceful feeling. I like change, disruption and reorganization. I like forging ahead with not usable internal support organization. That's me. If you like stability, read no further.

Caveat 1: I've been a contractor for 30 years, and had over hundred positions -- and almost as many interviews. This may not fit your idea of a good way to work/live.

Caveat 2: When all jobs are temporary, nothing is a deal-breaker.

With that warning, here's what I don't like.

The interviewer is your prospective manager -- not an HR person -- but they lecture you for 20 minutes on the ins and outs of the project, the politics and the technology choices.

After 20 minutes of listening to them talking, they follow up with "do you think you can do this?"

Nothing good comes of the above.

The answer is always "yes" because the question is merely rhetorical. All future conversations will be like this -- all their questions will be rhetorical -- your job is to guess what they've already decided.

Answer 20

For me, the biggest deal-breaker in a development job is the requirement to be on-call.

Answer 21

Required travel would be a deal breaker. (Since I have a family.) Not to mention that getting thrown into the client's home turf when things are broken is pretty nerve-wracking. Especially when what's broken is back at the office but you get to sit there in front of the client on the phone (or not) while your co-workers post on StackOverflow and go to lunch, etc.

Answer 22

Here is a list I recently compiled (mostly for myself, but I am sure a few aspects will be shared by others).

A list of things to keep in mind on the next interview.

• Ask to see a portfolio, if not available online
• Ask to see some of the code of the best/lead developer, this will be the best expectation
• Ask to see the version control log and unit test log, dont fall for ‘yes, we have/do that’
• Ask that the best/lead developer be present at the interview
• Make sure the best/lead developer is better than you, else you will be doing his job
• Ask to see some run of the mill code, any random snippet
• Ask them to be very precise on the responsibilities of the applied position, make them contractual
• Ask to look at their DB structures
• Ask to see architectural and design documentation

Once done with the above list, and you are happy, proceed with a normal interview, else say “thanks, but not interested”.

Answer 23

i recently had an interview with a BIG company and I figured that they would be at the cutting edge of technology, the following had my spidey senses going

• no definite answer on their QA process
• no definite answer on code review
• unit test - at times
• sharing code amongst teams - maybe
• no answer on their source control project
• as far as CI goes, they said depending on time and project
• they asked me a lot about GAC even though they do not use the GAC to place their assemblies
• they did not hear of subsonic, nhibernate, nservicebus,add-inn framework etc even though they do a lot of back end stuff and things with .net 3.5

Answer 24

• Visual SourceSafe. Never again I say, never!
• Having to be at work at a specific time in the morning (like 8:30)
• Anything that sounds like "we really want to implement [practice that good developers do] but we're real busy right now"; this means they're a code-it-now-fix-it-later shop

I'd put lack of unit testing on there, but honestly in my last job search I found that only 40% of the places I interviewed did unit testing. Which is pretty sad really but there you are.

Answer 25

The Joel Test and Field work in non-IT specialised organisations

For a software company or an in-house development shop the Joel Test (as various other posters have discussed) is quite a good start. However, as a contractor one tends to find oneself working in companies that are really not geared to develop software (otherwise why would they need to hire contractors?). Since I've been working in London I don't think I've seen a company that would rate more than 3 or 4 on this scale. Usually they can get specifications, source control (even if it's just VSS) and someone to do testing. Sometimes they have a bug tracking system.

In this situation, the actual project environment is quite sub-optimal and often has other political obstacles to getting work done. Data warehousing and B.I. projects are particularly vulnerable to this type of issue as they are dependent on interfaces to other systems, which in turn have their own politics. You can't really do a data warehouse project without having to stick fingers in pies, so these political obstacles are more or less unavoidable.

Typically, there is also an incumbent and poorly documented back office with their own manual procedures, politics and vested interests (often referred to as 'Gatekeepers' in data warehousing literature). There may also have been one or more unsuccessful attempts to produce a coherent MIS platform, so one tends to start out having to carry a burden of proof. The back office staff may or may not view the project as a threat.

Management's commitment to the project and making it work is a key factor in project viability and can be a make or break issue. In my experience management is really a weak link - project sponsors have to be prepared to back the project when it needs the business to pull its weight and line management need to be prepared to act as a two-way channel. I tend to be wary of signs of managmement that look like they aren't pulling their weight. Poor commitment from project sponsors, inadequate resourcing and evidence of a sleazy or self-serving management structure raise big warning flags.

Warning signs - some positions and interviews I've walked away from (or wished I had):

• Interviewer comes across as sleazy. This is a gut feeling or 'vibe' thing. At one point I went for an interview at a large consultancy and got the distinct impression that they were more interested in upselling than anything else. Sleaze is a big one for me as B.I. work is dependent on what is sometimes called 'customer intimacy - you need to gain the trust and backing of the business. An atmosphere of sleaze isn't going to promote trust.

• Interviews that consist exclusively of trivia questions or where the interviewer appears to be trying to prove they're cleverer than you. You don't want line management that is in the habit of trying to run you down. It also suggests some insecurity which can manifest itself in all sorts of negative ways. In the worst case it shows management looking up interview questions without really having the depth to do a competent technical interview. In a contracting role this is not necessarily an issue as they may genuinely need to bring in expertise that they do not have locally. However, an unwillingness to admit this or run the interview on an honest basis is also a warning flag. I also tend to view excessively structured interviews as a warning sign of someone who wants to simplify the decision down to tick boxes without taking responsibility for making a thoughtful evaluation of the candidates.

• Positions where the employer is offering less than a market rate. At best this is a clear signal that your management (at some level) is not giving the role the support it needs. If the manager can't or won't sign off (or get signed off) a market rate for the role, what other support will be lacking?
  
  At worst it is a sign that someone in management is always trying to pay less than the market for what they are getting. People like this are self-centered and will always try things on - give them an inch and they will take a mile. They will also not pull their weight when you need support for something.
  
  Lack of management support to resolve issues not directly under the control of your project is a key driver of project failure, wasted time and unresolved issues that hang around and cause friction. As these will be issues on your project you will be viewed as responsible for them by default. This is the sort of situation where unsupportive line management with a 'you should just make do' attitude can do real damage to the project - and potentially your career.

• Signs of micromanagement, self-serving management or excessive focus on minutae of performance. This is a signature of a direct report who is in the habit of reporting ticks in boxes to their management and proclaiming how wonderful they are for delivering everything on time and on-budget. Micromanagement of this sort is a bad habit in software project managers. It generates artificial work stress, disrupts flow and is always a drain on morale.
  
  Also, it allows the management to fob off the project risk to development staff, setting you up for meaningless 'failure to deliver' evaluations, which the manager now has an incentive to give in order to cover their own arse. This makes it a personal career risk to be involved in this sort of environment. For obvious reasons, all estimates will get padded in this sort of environment and Parkinsons Law law will apply - which means this type of management is a net drain on throughput.
  
  Finally it is also indicative of middle management who are not willing to stick their neck out to manage expectations with the business. This will erode your credibility, as management are in a position where they make self-serving promises to the business and blame the development staff for missed schedules without having any accountability for the reaonableness of the promised schedules. If it starts to reflect badly on you it is too late; you are already being perceived as poor at delivery and anything you say is likely to be regarded as an excuse.
  
  It is also a possible bellwether of endemic CYA culture that may be running at unhealthy levels. This is a situation to avoid if you can for many reasons - the principal one is that it gives people you are working with a strong incentive to drop you in it to cover themselves if they get in trouble, which means that you can't really trust other parties in this type of environment, including your own line managmenent.

• Support jobs dressed up as development. Hedge Funds are particularly bad for this. Also, anything billed as '50% development, 50% support'. This should be mentally translated to: 100% support and a development workload that won't get done because of all the interruptions. This type of job is unpleasant and sets you up as a convenient scapegoat for missed development objectives. Combined Deveoper/DBA jobs are prone to this sort of failure mode.

• 'Polyanna' overly positive hiring managers. Overly positive people who continually make claims like 'we don't have that kind of problem here' can be an indicator of middle management who won't acknowledge issues or won't manage upwards. It can also be an indicator of control freak tendencies - this type of personality tends to try and control information flow and present a rosy outward appearance. Finally, it can also be an indicator that the interviewer is misrepresenting the role or circumstances.

For a contractor, where (to some extent) you're only as good as your last job, career risk is actually a significant issue. As an example I've seen a situation where an ostensibly plum job at a company remained open at increasingly OTT contract rates because of the reputation that company had within the market. Previously I had been hired by the then incumbent in that job, who had been with them for 8 years until the company was acquired. He subsequently left, largely due to the rather septic internal merger-and-acquisition politics, and his replacement lasted for just a few months before he also left. In the meantime I had left as well. After that the position was such an obvious poison chalice that they couldn't fill it, even offering something like 50% over the market rate.

Joel Test for a typical London Insurance firm:

1. Do you use source control?
   Usually they do have source control, typically VSS (better than nothing although some say that's a matter of opinion ;-) On one occasion I've seen CVS used for a Java project.

2. Can you make a build in one step?
   Usually not geared for this (at least not on B.I. systems). However, I have seen C.M, C.I. and scripted builds on one occasion and introduced them on a couple of others.

3. Do you make daily builds?
   I have seen this on one occasion but usually they don't do this sort of thing.

4. Do you have a bug database?
   I have seen this on two occasions, but usually informal spreadsheets are the norm.

5. Do you fix bugs before writing new code?
   I've never seen this done in practice.

6. Do you have an up-to-date schedule?
   Most would say they do, but in practice schedules tend to be more for show than anything else.

7. Do you have a spec?
   Finance companies doing any U.S. business basically have to have a spec document for Sarbox controls. This might not have been the case a few years ago.

8. Do programmers have quiet working conditions?
   Never. Always in open-plan offices.

9. Do you use the best tools money can buy?
   Software tooling tends to be OK but fairly conservative. Hardware for resource-intensive development work such as a data warehouse project will often be lacking and correcting the shortcomings often takes months and backing from high-level project sponsors. On a number of occasions I've also seen software tooling - even basic stuff like Visual Studio - take months to arrive. For this reason I also maintain my own development lab.

10. Do you have testers?
    Often but not always.

11. Do new candidates write code during their interview?
    I've never seen this happen in practice, but the jobs I do tend to sit somewhere between development and consultancy so coding is only a part of the job.

12. Do you do hallway usability testing?
    When I have business reps with good buy-in something similar happens on occasion but it's far from the norm.

EDIT: Involvement in the support of what you've built, particularly in the early phases of roll-out can be quite instructive for a developer (as bernard-dy says). However, a mixed development/support role where you are on-call for general support issues (as is typically the case in a role described as 'Developer/DBA') has fundamental conflicting requirements within the role. This sort of environment is also frustrating and unpleasant to work in.

Doing any non-trivial development job requires concentration and support work is reactive with an implicit demand of 'drop everything'. This context switching is very toxic to anything that requires concentration and it will be the development work that suffers. In a role of this sort the immediate priority is always on the support but delivery deadlines for development are far more convenient judge performance by. The typical trap here is to be expected to drop the development work in favour of the support work but later find performance being evaluated on development deliverables (i.e. performance assessment is out of sync with the real work priorities).

Answer 26

Worked at a place with no vacation time. Said we'd "work it out later". Stupid of me, took it (of necessity). 2nd day there they asked me to sign something that said

a) If you ever look at non-company stuff from your work computer you can be fired (this is a small, dev shop, 6-7 developers only, not a financial).

b) If there's ever ANY legal dispute with the company, you agree in advance that you'll pay all the companies legal fees.

I started looking that day.

Answer 27

The Joel Test is great, but (yes, but) in some cases early on in your career you need to experience things. Poor management, fumbling through bad code, learning from your mistakes are all things that the perfect job should have early in your career. Am I advocating sacrilege? Yep. Having done this very thing myself, I can honestly say you'll learn more and work smarter, not harder once you have.

I worked at a lowly web development company where the "desks" were kitchen counter tops bolted to a wall and our space was about 2 feet in either direction from the other station. I worked for peanuts, but you know what? I learned PHP, MySQL, XHTML and CSS in the year and a half I worked there and I also learned why source control was important, because we never had any and when you lose 8 hours of work to Joe-saves-over-me you start to wonder.

From there I worked at another start up company out in the middle of nowhere and was paid exceptionally well for my level of expertise. They had source control, and everyone there was great to work with. I learned that everything I learned could be improved, and I learned a bunch of new skills. Then I learned the next valuable lesson, which I had started to learn at my last position: Management is key. You need to be managed.

Now I work in what you call the "red tape bureaucracy" and will likely never go back, until I start my own horribly disorganized start up. Oh sure, the service oriented architecture and SOX compliance might get to you at first, but you have to remember that you are learning. Learn everything you can. Learn how you want to work, and how you hate working.

Be open and honest with the hiring manager. Otherwise, you're likely to end up somewhere you won't enjoy. As far as red flags? Go for your gut feeling, and the Joel Test. Just don't devalue the experience of working through problems. After all, in our profession, problems are why we have jobs in the first place.

Answer 28

Making you work solely from a laptop with no monitor.
(About every large Consultancy that I've ever seen does this.)

Answer 29

The interviewer cannot or will not tell you how you will be evaluated and how you qualify for raises.

Answer 30

If they do web development but outsourced their own corporate site.

Answer 31

"No, the recruiter got that wrong, we don't do much Java, you'll be writing Tcl."

"Wow that's a long way to come for an interview. Sorry, the recruiter got that wrong, we don't refund interview expenses."

"Wow, that's a long way to come. Didn't the recruiter tell you, this is just a chat? If we're interested we'll get you back in on Tuesday."

"We don't use third-party code here, not even the standard Java API. We wrote our own String class, it's more efficient."

"What version control do we use? Visual SourceSafe."

"We normally work until about 7 or 8pm, but on Saturdays we finish at lunchtime."

"You'll be on-call out-of-hours Monday to Friday."

"All developers spend some of their time doing telephone support."

Answer 32

I walked out of a lucrative prospect one time because their NCA (Non Compete Agreement) read like it was written from Karl Marx or something like that.

Also, ANYTHING (and I mean any little or large or in-between thing) that I developed on, say, a Saturday afternoon was THEIR property. Talk about lame. I asked them, "If I am doing a science project with my kid after dinner and we create some pretty nifty gadget for him to show at the Fair - you own that?". The immediate answer was "yes". I shook their hands and said good-bye. It was then that I decided to go it alone (self-employment) and vowed never to do that to people who were hired to help me. Never tie their hands.

Answer 33

If I become seriously interested in the position, I always ask, "Do you like your job? Are you planning on staying here?" Watch for a quick flash of expression across their face, and watch their body language carefully while they try to answer the question.

Answer 34

I walked out of an interview once after 20 minutes when it became clear that their core hours were 9.30am-4.30pm and "they would be flexible about doctor's appointment". It didn't look like the sort of place I could wear shorts to work either...

Now that I am an employer, both of my employees frequently get in at 11ish, one because they work late, the other because they go and do sports in the morning. So long as they are here for meetings and get the work done, why should I care?

Answer 35

I've learned the hard way that technical questions that are dead easy are usually a sign of company full of people who wouldn't be able to answer harder questions.

So when you get technical questions ask yourself if you want to work with a group of people where these questions represent the minimum technical ability level.

Answer 36

If they are half competent they will be able to bullshit through a lot of the valid tests people have raised. A great sly one is to ask about what your personal dev environment and box. The attitude to providing a productive environment says a lot about their real attitude to developers.

• New mac pro == good, unknown second hand box == bad.
• Whatever OS you want == good, SOE Win2K == bad.
• Choice of IDE == good, tools budget == great!

Answer 37

My top 10 red-flags:

1. Their programmers are stuck with 17" tube monitors.

2. Internet access is not allowed or is severely limited. Ex. They think you can do your job just fine with locally-installed msdn help.

3. Their "data center" is running mostly PCs (ex. running DOS, Windows 95, Windows 2000, OS2, etc..)

4. Their network is still running on Novell Netware or Windows for Workgroups.

5. Their core data is FoxPro, Access, Paradox, mainframe extracts, etc.. [and this will likely never change as long as you're alive]

6. You'll be required to participate in night support [and you're told not worry if you receive your pager before your PC].

7. They ask you to take a hand-writing recognition analysis test. [yes, I was actually asked to take one of these once]

8. They ask you to write a bubble sort. [It's not the bubble sort I'd be worried about]

9. You're fore-warned that you should never install anything on your computer or store anything local because computers are re-imaged on an ad-hoc basis.

10. A perk of the job is a new FranklinCovey with free re-fills every year. Worse - the dev mgr or lead architect interviewing you is toting one around.

Answer 38

My deal breakers include:

• working on commission
• being on-call
• any software shop where the sales staff out-number the developers 2-1 or worse (in my experience sales loves to promise the impossible)

Answer 39

• when "interfacing with clients" really means "upselling whether they need it or not"
• when "leading the development team" really means "writing specs and running tests for an outsourced team that I don't get to choose"
• when "full telecommute" means "100% travel"

Answer 40

I was being interviewed for a job about 10 years ago:

Interviewer: So, have you ever built a Java Applet?

Me: "No, sorry. I really don't know java. I have read about Applets and have a general idea of what are they for and the basic scenario where you could use them"

Interviewer: Uhm. Ok. But suppose that you had to build one. Could you do it?

Me: Yes, naturally I think I could learn to build java applets, just like any other programming topic.

Interviewer: Could you do it.. say.. right now? I mean, if needed?

Me: I could try.

Interviewer: Perfect. Can you start tomorrow?

It is the only one time I have rejected a job offer. I have met people that have worked there and all of them agree that this place is the worst depressing software sweat-shop.

Answer 41

If you get a chance to wander round where the "real developers" sit (maybe even on the way in to the interview) - check out what apps are open on their screens, and what books are on their bookshelves.

Warning sign apps are when you see nothing but outlook, excel, word etc open on their desktops.

Warning signs for books are when everyone's desks are covered with the latest "technology stack components in a nutshell" or whatever, yet they are in pristine condition, and do not even have any crease marks in the spine

Answer 42

Having been lured in on the promise of working with the latest and most interesting technology, one of the interviewers asks me whether I happen to know any VB6 "just in case our legacy LOB app needs supporting..."...

Answer 43

Wow, I'm surprised at the number of divas that replying. I don't know - as I've matured as a developer/professional, my 'deal breakers' have relaxed a lot. Honestly, I can't believe that people would turn down a good job just because they have to be there on time. Really?

For my last interview, the only thing that I asked was to see their code. That's the one thing that can really make me miserable these days. I can wear collared shirts, get to work on time, do just about anything, but working with bad code is just horrible.

Edit - Also, money can be a deal breaker for me as well. I have a no-go line that I will not drop below. The rest is a series of compromises. If you pay really well, I'll toe the line and wear collared shirts and look smart. But, if you've got cool technology and great people, I'll work for less money. But those aren't deal breakers for me.

Answer 44

When they move you to another cubicle because you're "talking too much" to the developer in the cubiccle next to you...

Answer 45

Just look at the office: if they have "Motivators" posted all over the place, then... Oh, yeah, then you're in trouble.

Also, open space environment sucks.

Answer 46

Free Coffee - You'll never find a more simple indicator of how much management respects its workforce.

Peets delivery service and a good espresso machine? You'll also get dual 21s, a fast machine, and the tools you need to get things done.

Drip machine and cheapo coffee service? You'll get a Single 21" monitor and a re-tasked "server" as your dev box.

Drip machine, little cup for quarters, and "The Honor System"? Single 19" & a cheapo HP box with XP Home. And Visual Studio Express Edition.

Bring your own? Bring your own machine too if you want to get any work done.

Answer 47

Ask about employee turnover.

Answer 48

My deal breaker, other than the obvious unsatisfactory work environment; would have to be the expectation of a jack of all trades.

This is common in smaller companies, where a developer might answer a support call unrelated to code he's written, or make a system configuration change, or modify a DB schema, etc..

I guess the same could happen in a larger organization. Rule of thumb, make sure they understand that an agile development process doesn't mean you'll do whatever they want whenever they want.

If you're not careful they could have you mopping the floors. (not that there's anything wrong with that! --Seinfeld)

Answer 49

Beeing interviewed by your prospective manager and realizing he doesn't have any technical knowledge dating later than 1995.

Answer 50

You'll laugh, but I always check out the bathrooms/kitchen first when I show up for an interview. Often it tells you more about the people you're going to work with than the interview itself. If the group you're to be working with can't manage to keep a toilet clean by cleaning up after themselves or can't be bothered to wash their own coffee cup after using it, then it says something about the corporate culture.

Answer 51

If there is no bug tracking software and the general process used for develop is, "Just make it work!" this is a red flag.

If the idea of a specification is a one sentence e-mail, this is a red flag.

If the notion of career development is, "You want to do WHAT?" this is a red flag.

If the idea of source control generates a response like, "Hey, that sounds like a good idea. We should do that sometime," this is a red flag.

If mentioning the idea of testing one's code makes the interviewer say something like "Whoa... that makes sense. We should do that," this is a red flag.

I can see many more similar to the, "You might be a redneck..." type jokes.

Answer 52

Personally, the main dealbreaker for me would be feeling like I'd never get to work on anything that I actually find interesting or fun. Given the choice of of doing dull, mind numbing coding in a top of the line private office with a two 24" monitors and working on fascinating and intellectually challenging problems in a cubicle and a 17" CRT I'll take the latter every day of the week.

Answer 53

Deal breaker for me is some outrageous vesting period (5 years or more) for your 401k, or no matching 401k for a year.

When I'm at a company and the raises are very small, less than 6% then I start looking elsewhere.

Answer 54

Not me, but a friend going for a C# position was asked on his first morning not to use objects.

"We don't understand that way of doing it."

Okay... He left at lunch.

Answer 55

There's the old Dilbert test:

If there's Dilbert cartoons all over, it means they're applicable. Run.

If there's a few Dilbert cartoons, fine. Stay. This is a good sign.

If there are none, they may be banned. Run faster.

Answer 56

If you can totally wow the interviewer and he or she offers you the job on the spot, its usually a very bad sign.

Flexible working hours are a must. If someone seems like a clock watcher and requires everyone be there from 8-6, it's a very bad sign.

Any place that treats developers like second class citizens is also not worth it. Lots of companies treat devs like a commodity to be bought and sold as needed. It will become very obvious to you within your first week of working there.

Outrageously high pay is another one. If you're making anything more than 10-15% more on your base salary than you think you should, it means they are paying a lot because the job sucks.

Answer 57

Ask about the Application and its architecture. If they have no clue about the N-Tier Architecture , thats a bad sign.

In the enterprise world, companies invests time & $$$ to build an application and then they want to see the ROI. So somebody has to maintain the application for the rest of the years.

The company should also be willing to upgrade the technology and make it better. If not you will end up supporting classic ASP application, or .NET 1.0 applications written in classic asp procedural style.

There should also be a opportunity to build new apps in the job profile. If its all support and bug fixes. Then its a NO NO for me.

Answer 58

"Before we can offer you the position, we'll need to schedule you for a complete physical and a drug test."

No, I don't do drugs. But if they don't have trust in me as a person, they certainly won't have trust in me as a professional employee. So thanks, but no thanks.

By the way, the folks on here who claimed Lotus Notes as a deal breaker - you really need to have a look at the latest Eclipse-based Release 8. As someone already mentioned, it's MUCH MORE than just an email client!

Answer 59

I haven't ever had an interview for a programming job, but let me tell you about engineering jobs. And let me say that I think a bunch of you were spoiled by the dotcom boom...

Deal breakers:

• unpaid overtime
• overtime expected to be regular and in excess of 10 hours per week
• high turnover environment
• lack of work processes (similar to not have source control in the software world)
• bad tools
• micromanagement / CYA attitudes
• severely restricted internet access
• bad HVAC. Nothing worse than an office that near freezing in winter or 90°F in summer.

Things that one can live with:

• cube farms. Headphones work wonders at blocking out the background noise and your co-workers will learn not to interrupt over minor stuff
• bad coffee, if there is a decent coffee shop nearby
• being asked to be on time. This is ridiculous and lazy if you can't be in the office from 8:00 to 5:00. Some flexibility is nice, but it need not be ridiculous.

Only time I walked out of an interview: Right out of school, a guy with a major oil company asked why I wasted my time in school editing a newspaper, organizing social events, etc. When I said I learned alot doing it, he said "I think you would have been better served by working harder on your grades". I had a 3.6 grade point...

Answer 60

What a buncha wimps! There's only one dealbreaker: They don't pay my invoices.

I've been free-lancing, consulting, contracting for 35 years. Poor tools, noisy (and once, dirty) working conditions, inconsiderate bosses (and owners), long hours, new hardware that doesn't work, unrealistic schedules, angry customers - that's all folded into the rate.

Only once did I anticipate being screwed out of my last invoice. Sure enough, payment didn't arrive at the appointed time. Nobody would answer my phone calls except people who said, "Not my job."

Then 90 days late, a check showed up in my mailbox!

Nasty jobs, nasty people ... bring 'em on!

Regards, Bill Drissel

Answer 61

Off the top of my head....

• Lack of Source Control
• Strict Dress Code
• Management that does not understand the complexity of the problem they are solving (leads to mismatch between what is expected and what is actually produced)
• Long release cycles (I prefer companies that execute fast, nothing is more frustrating than having feature x done before your competitor but not releasing)
• Dumb Team (This should be obvious but you want to make sure that you are working with people at your level or slightly better)
• Positive attitude (Nothing will make you hate your job more than being around people who hate theirs)

Answer 62

Deal breaker for me is the development/programming tasks I am assigned to perform. I prefer to be working on projects that use tools and technologies that are not more than 5 years old.

Some companies tend to advertise positions by using the latest/greatest acronyms only for a new hire to find out later on that they would be asked to do maintenance work on old applications (i.e. VB6) for "the next 3 to 6 months" while plans are afoot to migrate the app to use the latest and greatest tools.

Answer 63

Family business - especially if there are VPs with the same surname as the founder but no obvious role.

Answer 64

• As mentioned above, employee turnover. If they tell you they've had a mass exodus of developers, do not believe their claims that those developers were "too junior", "not good fits" or anything else. No matter what, remember that if a place was not good enough for developer X to work at, it will probably suck for developer Y as well.

• If a shop is not currently using .NET, but claims that you as a new employee can "lead the drive towards .NET", do not believe it. This is even more so in a highly political environment, as a new employee will have even less influence. If your manager does not have the political pull to move towards a new technology, you will be powerless.

• If a startup "Isn't comfortable discussing their funding" or their finances, run away quickly. They are either broke or crooked.

• If looking at a job at a startup, ask about their major customers. If they say they don't really have any, don't be lured by anything else.

• Age of a company, success, and number of employees are inter-related, in my opinion. If a "technology startup" is > 5 years old and still has less than 10 employees, you should be worried. If they are > 10 years and have less than 5 employees, be very concerned.

• If they persistently and repeatedly ask you "How many hours are you willing to work?", obviously, run away.

• In general, being a production center rather than a cost center is always preferable. That is, working for a company that sells software is better than a company that is forced to create software as an expense. Both can be great jobs, but I think there are advantages to producing rather than consuming.

Answer 65

The big thing for me is a lethargic work force.

If the developers are down-trodden, stare-at-the-clock-until-it's-5-pm types, I'm going to be very unhappy and very agitated.

I left a better paying job for a lesser paying one for exactly that reason. I can do overtime, I can do open concept, I can do crappy HVAC work sites, I can do meaningless non-fun coding. Just make sure the people are passionate about what they do -- and that usually comes from a whole bunch of variable sources.

Answer 66

Most of these are, sadly, in retrospect:

• Family business where family members are senior management based solely on the fact they're family (it's okay if they actually have legit management experience) -- this normally means they have little or no real world experience and don't know what they're doing, but are in control because the husband/wife/father/mother is the owner.

• Draconian hours/no flex time. Obviously nothing ridiculous like coming in at 12, but the ability to rearrange your working hours if you need to for personal reasons. Not having this means the owner is a micromanager who feels that he can't trust anyone to put in an honest day's work without keeping tabs on you.

• One or more of your co-workers are "Company Men" and shill for the owner, saying how great a person he/she is and how fortunate everyone is to work at the company (a Smithers, basically) all the time and that "so-and-so is a VERY powerful man" as though it's a threat to you.

• The company is cheap - if you ask for a $200 tool to do your job and it gets shot down immediately, run away. If something that would save the company thousands costs $150 and the boss says that's too much to spend, run away screaming.

• You will be the only person in the IT department, and before you got hired the company didn't HAVE anyone in the IT department for over a year. Most (not all) of the time this is a HUGE red flag and you'll be stuck wallowing in crap and troubleshooting users all day.

• Developers are heads-down coding away the entire day, without any opportunities for experimenting with new technologies during "downtime", and/or lack of downtime altogether. Any company like this is undoubtedly a toxic environment and run like a sweatshop.

• Your boss-to-be keeps talking about how he was a programmer 20 years ago, but doesn't seem to have learned anything new in 19 years -- in my experience people who are like this have never learned anything new but think they are capable of managing new projects.

• The person in charge of the IT department appears to not know anything about IT but used to "work on mainframes" years ago.

• The owner/president seems to not have a good idea of what their core business is and what it entails, and/or the whole operation seems like an attempt by someone to "play" at owning a business so they can be the "boss", as opposed to being a legitimate business venture.

• (related to above) The entire business seems like just a quick way for the owner(s) to live the way they want to, instead of being an actual attempt to sell a product/service. A business that only exists to fund the owner's extravagant lifestyle.

• Your potential co-workers seem unenthusiastic and don't care to keep at least passing knowledge of new technology. They don't have to jump on the "next big thing", but if you're interviewing with .NET programmers and ask about LINQ, or Silverlight or WCF and get a blank look, it means that your co-workers are a group of "Morts" and don't want to better themselves.

• Miserably failing the Joel Test in regards to source control, bug tracking, and good development tools. There's a fine line to this though - if they give you a single 24" LCD and a mid/high-end Dell XPS it's alright, if they give you a shitty, yellowing 17" CRT and a 5-year old Compaq (or worse!) then it's not. Also, at least the basic tools you need to do your job effectively - I've worked for places too cheap to pay money for Visual Studio and was forced to use the Express editions just to have something to use. In short, a company that skimps on its developers doesn't CARE about it's developers.

• Q: "What do you use for version control?" A: "Visual Source Safe".

• Your job duties will consist almost entirely of maintaining legacy code with little to no chance of working on new development; also a company that still has large amounts of legacy technology and no plans to upgrade/move forward.

• (after the fact) Everyone in the company is using refurbished computers, residential class DSL, and cheap routers from Best Buy, but the owner drives around in expensive sports cars and takes frequent trips. Run away - this means the owner doesn't care about running a business but wants to live like a king.

• (after the fact) Your boss spends more time working on and coming up with new business ventures than running the business you work for. RUN AWAY SCREAMING (if at all possible - sadly this is in my current job and I cannot) for obvious reasons

And the #1 dealbreaker:

• You would not enjoy the job. Sometimes we need to make sacrifices because we need to earn money, but this is what it boils down to -- I don't care how great your company is or what you offer me as far as salary/perks; if I would not enjoy coming in to work 5 days a week for 8 hours a day, and if I wouldn't enjoy being around my co-workers and supervisor(s), then I wouldn't take the job no matter what.

Answer 67

As someone from a development background who is now involved in line management and internal corporate funding / roadmap development I can't really believe how out-of-touch some people in this thread are. Why do developers behave like such prima donnas these days - when I earned a living developing (not that long ago) I understood that I was being paid to do a job, and that as much as they (my employers) needed me / someone, I also needed the pay cheque. When someone states "having to turn up to work on time", or "no free coffee" is a deal-breaker, that person is going to find themselves outsourced quicker than they can type cappuccino.

Professional standards, interesting technology, market rates, management support / integrity are all good signs that make for a better workplace, which ultimately makes for better software, but meeting members of the development team as part of the interview process could / should make that clear enough.

As the chill wind of recession blows through the industry, I fear some people are going to have to re-adjust their over-inflated opinions of their own worth.

Answer 68

Being hired with only one interview, or ON the first interview. It normally means they are desperate to fill some positions. Their turn-over rate must be high. This has happened to me three times, unfortunately.

Answer 69

Over-reaching "all you ever create is ours" 'intellectual property' clauses. Post-employment restrictions on who I can work for or what I can work with.

I have no problem with "what's created on company hours is the company's", that's fine. I am slightly ambivalent about "what's created out of hours, on the company's equipment, is the company's", but on the balance, I think it's reasonable. I have a huge problem with anything I cretae, on my own time, with my own equipment, automatically being gifted to the company.

No-compete agreements are (essentially) an instant deal-breaker. I can make exceptions for a consultancy post, where I'd accept not to go directly into full-time employment with a recent client (that I've been working at/for).

Answer 70

The deal breaker for me is a high number of daily application bug reports. If it is over 3 then the application is poorly designed/written/tested. Combined with the interviewers boastful pride in the application just confirms the observation. I do not want to spend years of my time fixing an application that needs a serious re-write.

What irks me the most is the extensive list of experiential requirements for a position or contract. Little attention is ever given to whether the potential employee/contractor can actually create software that works flawlessly out of the gate. Some people have all of the required experience and are personable but cannot program their way out of a paper bag.

Many a time, on the job, I have been called upon to write programs in a language I had never seen and I simply read the manual and got the job done. Once you have programmed in 3 or more languages there is no difficulty in picking up another. This is especially true for 3rd generation languages. Once you have a few OO languages under your belt the same holds true, except for extensive class libraries that basically have all of same functionality but have different invocation and property names.

With respect to current skills I cannot get a COBOL programming job to save my life. Why? Because I have not used COBOL for over 15 years. Regardless of having programmed in COBOL for another 16 years in 14 different COBOL dialects. Not that I really want a job using COBOL.

I am just in a bad mood today, pay no attention.

Answer 71

A summary of all answers in the thread:

Will mostly do support / brownfield development

Will have to be on-call

No source control or SourceSafe used for source control

Don't do branching of code in source control

Working hours not flexible at all

Using legacy software / tools

no TDD / no unit-testing

Waterfall / no iterative development

You will be the best dev in the shop

(Overly strict) dress code

Obvious monarchy

Too serious / no joking / stressed out

No bug tracking system, or bug tracking 100% owned by QA

Overly restrictive Legal Agreement -- they own what you do at off hours

No blogging policy

No dual monitors

Internet access limited

Disconnected or lethargic or burned out team members

Overtime expected and not paid for

Code / db looks ugly

Yes we're going to implement that but we're very busy now

Too much talk of business priorities / results driven attitude

Not using resharper / will not buy resharper or something like araxis merge etc.

No free time to experiment

Nobody recently went to a software dev conference

Very many clients that come and go (e.g. a marketing company)

No books on shelves or books look not read

"Motivators" posted all over the place

Dirty bathroom / kitchen

No code sharing between team members

No Continuous Integration / no nightly builds

Lack of or little personal stuff on desks

Your potential manager gives you a long lecture

IT is a cost center rather than a production center

no match on 401k

Too eager to hire

Can't use your notebook at work / can't connect to their LAN

No working from home / no remote access

No admin rights on your development box

Answer 72

What constitutes a deal-breaker for me depends on how desperate I am to get a new job. If I was presently unemployed, the refrigerator is empty, and the bill collectors all have my number on speed-dial, "... after 12 hours of coding you'll be expected to work in our salt mines for 4 more hours" might not be a deal-breaker.

But assuming I'm not too desperate, things that run up red flags for me are:

1. Extremely specific job requirements. When an employer says, "We're looking for someone with Java, WebSphere, Oracle database, SVN, TestDirector, Eclipse, in a widget manufacturing environment, using a Windows XP work station from Dell, with a boss named Bob who has red hair" ... well, I've never had the part about the "boss named Bob", but when someone gives me a long list of specific languages and products, it tells me that: (a) They don't know the difference between "knowing how to develop computer systems" and "knowing Java". This place is mired in detail with no big picture. (b) If I go there, I am going to get stuck in a rut. If I come in knowing Java, C++, PHP, and twenty other languages, and the company's big new project uses C#, I will not get to work on the big new project because I am "not qualified" as I don't know C#. I will never be given a chance to learn new skills, and as the skills I already have grow increasingly out of date I will get stuck in a technological backwater.

2. Hints that there's excessive paperwork. Personally, any want ad I see that mentions "UML" or "ISO9000" I immediately skip over. I want to write code, not fill out forms. (I'm not saying that I don't want to do ANY paperwork, I recognize the value of requirements papers and ERDs. I just want to know they're in the realms of reason.)

3. Indications that this place has very rigid policies that are all take and no give. I understand that there are some jobs where you must show up promptly at 8:00, like receptionist or bus driver. But receptionists and bus drivers then expect to leave promptly at 5:00. In IT, I accept that when deadlines loom I have to stay late or work over the weekend. In return, I expect that when the pressure is off, the company will not care that I come in late and take a long lunch. At one job I came in one morning at 8:00 am and we had a customer with a serious problem and I ended up staying until 11:00 am the next day getting it fixed. Then I went home to get some sleep. The next day my boss's boss yelled at me for leaving before 5:00.

Answer 73

• working place (not having own room)
• strict working hours

Answer 74

What you will definitely notice is that companies that don't do "software' laugh at you when you ask for dual monitors.

Or when you say 'I really need a faster machine. Visual Studio and SQl Server can be pretty taxing on a slow system" and they'll say sarcastically "yeah we'll get right on that."

You typically run into this while doing consulting. you'll often not even get a cubicle. you'll be put at a desk where perhaps the light works and it's usually the noisiest area of the building. Full Time employees, especially in the IT department do not like consultants very much. Usually because we are brought in because people in house couldn't accomplish what needed done.

I suppose I don't really have a deal breaker at this point because I know what i'm getting into with consulting work.

It would be nice to work for a place that actually took development seriously, and provided the resources, but it's definitely hard to find.

Answer 75

I recommend the Dilbert Metric. Employee happiness is inversely proportional to the number of Dilbert cartoons posted.

Edit: I see David Thornley already said this, and did it funnier. Too late.

Answer 76

"Based on my experience developing and shipping software, do I think that this team can ship software?"

For any question I can ask, there might be a "right" and a "wrong" answer, and frequently the opposite of a wrong answer is another wrong answer, or the opposite of a right answer is another right answer. The main thing I'd look for is that the team has answers that seem grounded in reality and experience, and not simply arbitrary rules that somebody read somewhere.

Also, I'd look for a team that doesn't seem overly geared towards novice developers at the expense of experienced developers (draconian process controls, etc.)

Answer 77

The company has a bad credit score. After having had a couple of contracts go south on me due to the firm going bankrupt I always do a credit check before attending interviews.

Answer 78

I started asking this one a few years back. It never fails me.

"What is the last cool thing you learned?"

If I get an answer, great. If I don't, I follow up with

"It doesn't have to be work related, just something cool that made you sit back and say 'wow'".

After a seemingly successful many-on-one interview that I had... some reservations about, I asked the group this question. They all stared at me, deer-in-the-headlights. I knew working there would have been a serious mistake.

Answer 79

Vending machines
This one alwasy struck me as odd though the correlation between vending machines and TPS-reports is 1.0 thus far.

perhaps someone here can explain this.

Answer 80

1. They ask you to sign an employment contract, but they don't give you a copy to keep (this applies to any industry, not just software.)
2. They have a policy of not issuing copyright disclaimers for code you write at home.
3. You will be working in an open-plan office which is adjacent to (or even the same room as) the sales office and/or IT helpdesk.
4. They still use Microsoft SourceSafe.