If you've been in the industry for a while, undoubtedly you have had a Bad Work Experience. Whether you left a job on your own determinism or because you were pushed, months later you can look back at one incident that should have been a clue. With the help of several other people (all contributing anonymously), I hereby provide a Translation Machine to help you understand when the manager says one thing but really means, "Perhaps you should explore how best to improve your résumé and brush up on interviewing skills."

For example:
Manager says: "You are not a team player."
Manager means: "Start circulating your résumé, because there is no way you're going to make it past the next layoff."

Lesson: While it's perfectly reasonable for the company to want team members who care about the project's success, this phrase is not actionable and thus you cannot survive it. Especially if you're the programmer who worked through the weekend to make the software work.

Useful feedback is specific, meant to help you improve, with some sort of metric that lets you and your manager measure success. "You are not a team player" is a meaningless expression that means, "I don't like you."

Manager says: "We are reorganizing the department, but your job is safe."
Manager means: "It's very easy to upload your résumé to Monster. You should try it."

Lesson: Maybe they mean it. Today. But how much do you want to trust them?

I could provide several variations on that theme. But the bottom line is, anytime there is a major change in the company, your job is at risk. You might indeed be the safest person there — but how much do you want to count on it?

Here's one of the variations: "Can you come to my office when you get to a good stopping point?" Wrote my developer-friend, "That was my first layoff. I had the misfortune to solve the last major problem for a project the day before the layoff, thereby earning myself the distinction of being the very last name added to the list."

Manager says: Nah, you don't need to go to that trade show. (And it's the primary show on your technology beat, utterly relevant to your job. You've attended every year for five years.)
Manager means: Bye.

Lesson: If they won't invest in you, they don't expect to see any return.

Manager says: Nobody got a raise this year, you shouldn't complain.

Manager means: We don't value your work. Also, no-raises is swiftly followed by pay cuts, which are soon followed by layoffs. Guess who's on the list? (Extra points for, "Yes, those were valuable contributions, but unfortunately they don't count as part of your real job.")

Lesson: The economy is a real issue, and I won't make light of it. But you shouldn't, either. I've known several companies whose idea of deciding, "Which employee is most expendable?" is "Let's sort the employee spreadsheet by salary, and cut from the top." (Never mind that this also likely eliminates the most experienced staff.) If you suspect you're making more than anyone else in the department... Gosh, which buzzwords should you include on your résumé?

Manager says: We need you to volunteer to "help" QA (or documentation, or pre-sales support) for a few months.
Manager means: We are banishing you. Have a nice day.

Lesson: I've known several companies who "kindly" gave staff a graceful exit. At a high enough managerial level, the employee is given a title like Vice President in Charge of Nothing in Particular, an office with a folding chair and no window, and absolutely no job responsibilities. It's an unspoken suggestion that the company will provide a good reference if only the executive will kindly leave soon. People lower on the totem pole don't get such opportunities.

Manager says, "Here is our new employee policy for use of the Internet. Please sign this to indicate you've read it."
Manager means, "We're going to need an excuse to fire people in the not-so-distant future, so we'll forbid you from checking your e-mail or doing any kind of non-work-related surfing, even on your lunch hour — and then catch you when we need to."

Lesson: It's time to polish that résumé. And to get everything personal off your computer.

And a few more, that need no explanation:

"At the first company I ever worked for, I was head of training/tech support/consulting. They announce the sale of the company at the company Christmas party: Our company was sold to our largest competitor, our arch enemy. I introduce myself to the new owner as the head of technical support. He says, 'Oh, tech support. Well we won't be needing you guys any more!' I went home and prepared my résumé MERRY CHRISTMAS!"

In one of my first jobs, wrote one correspondent, "Every so often the chairman would visit the office and during his walking tour would stop and ask various people 'So, exactly what is it that you do?' Translation: Pack up your stuff as the HR director will have you escorted out the door by day's end (no matter what answer they gave)."

Manager asks, "How long have you been working here, not including tomorrow?"

Manager says, "So. I was reading your blog...."

What would you add?

We all like to think that applying for a job puts your résumé in front of your prospective new boss: a hiring manager who understands the technical background you carefully explained in your career summary. But most programmers apply for new jobs through the Human Resources (HR) department, which exists to eliminate candidates rather than to find them. If HR decides your background isn't right for the job, the hiring manager will never know about you. Even when you know you have the job skills the company wants, you can be eliminated for arbitrary reasons.

Most guides to writing résumés and CVs reasonably encourage you to write for the knowledgeable person with whom you'll interview: someone who can appreciate your brilliant achievements. This can be a particular problem for software developers because so much of the résumé is in-depth technology descriptions that a recruiter is unlikely to understand. A programmer easily can apply for a job whose duties are beyond a well-meaning HR pro's personal technical knowledge.

Obviously, the best strategy is to go around HR whenever you can, and eliminate the middleman. But when you're faced with a perfect-sounding job to which you can only apply by writing to something-or-other@craigslist.org, HR is unavoidable. So in a marketing sense there are two audiences, the staffing person and the manager, and you need to answer the concerns of the first before the second will hear about you.

Instead of continuing to complain about the situation, though, I decided to ask HR and staffing professionals how they eliminate you. That is: When an HR pro is looking at résumés from software developers applying for programming positions, what makes the recruiter hit Delete without thinking twice? What items in a résumé makes them crumple up the paper (virtually) and throw it in the circular file? What makes them think, "Whatever made you imagine you are qualified?!" A few dozen people responded to my query, and helped me learn how you can keep your résumé out of their trash bin. I don't promise you'll like this list of their criteria. But it doesn't matter if you agree with their perceptions; they are still between you and that job interview.

Let's start with the most obvious lesson: You need the buzzwords. Most HR professionals rely on a keyword matching process and an automated applicant tracking system — those tedious web forms you fill out. If you don't have good "key words," you won't show up on their radar as having the right experience.

These systems are understandably literal. A human might see "Paris" and recognize, "That's in France," but a search algorithm will not. So you have to be far more explicit than you think you ought to be. You know that J2EE experience counts as Java; an HR person who types "Java" into a résumé search system will only find that experience if "Java" is mentioned in your document.

Despite the expectation that you'll have the right list of technical qualifications, many HR professionals also want you to write in business terms and avoid technical jargon. Yes, I realize that appears to be contradictory advice, but it behooves you to find a balance. Sharon Blaivas, a former recruiter at Goldman Sachs who's now a resume writer for shakeupmyresume.com, says HR professionals want to see résumés that are pleasing to the eyes and understandable — not "a bunch of techno babble thrown on a page from margin to margin making the reader fear that the candidate won't work well with non-technical people." Your résumé may never see paper, Blaivas says, but it should have a clean appearance and nice formatting.

However can you do both?! Another recruiter suggested you dumb things down a bit. That is, he said, "Create a resume that a layperson will understand. Yes, include the technologies used and maybe a bit about your methodology, but make sure it's readable to the point that a non-techie friend can get the gist of what you've accomplished in each job. Keep that tech-oriented résumé for the hiring manager to review."

Perhaps that more in-depth technical overview is suitable for a web-friendly page to which you can direct the hiring manager (should you be lucky enough to get past HR). Because, continued the recruiter, IT folks are notorious for long resumes—painfully long resumes. "Much of this is due to the project-based nature of their work. However, they need to show some discipline," he says. "A resume is not a CV. It's not a data dump. It's not a bio. It's a marketing tool used to market YOU as a candidate." Or as one recruiter once made clear to me: the job of your résumé is not to get you a job. It's to get you an interview.

The HR people are indeed looking for the academic background and certification "achievements" that irritate the heck out of techies who might have the right technical background without a college degree or personally believe that vendor certifications don't accurately judge ability. One HR pro listed the things he looks for, from higher to lower importance, as:

• Academic education
• Technical experience
• English level
• Right language structure and sintax [sic]
• CV arrangement

But that's just the start. Here are more mistakes you can make in trying to get past the HR department:

Misrepresenting how long you worked with a particular language or technology. Johnny C. Taylor, Jr, author of The Trouble with HR cites software developers who'll emphasizing proficiency in a new programming language in a way that isn't credible. Just as you and I have seen job ads calling for five years of experience in a technology that hasn't existed for five years, some folks pad their résumés in an equally dumb manner.

A little less obviously, developers sometimes claim technology expertise in their summary, Taylor says, but they fail to show any actual work experience with the language. For some recruiters, this is a major turnoff — one that'll get your application dumped immediately. If you list a technology in your technical summary, then you should be ready to pass a technical screen on that technology. Don't exaggerate experience, particularly with self-proclaimed labels. "Someone a year out of school and no prior experience calling themselves a test architect," for example, is a fast trip to the trash heap for at least one recruiter. Don't try to give vague arm-wave to get noticed, either. One hiring manager rejects applications with "lots of buzzwords that mean nothing," such as "familiar with the SDLC." She wrote, "Which SDLC do you mean and how does you're being familiar help me?" Don't use words like "familiar" because they are too mushy; does that mean you can recite back a list you memorized for an interview question or that you actually understand what activities are appropriate when? "I see this a lot on resumes with little experience in an effort to make the resume look bigger," the manager says.

Software developers need to learn the art of leaving out irrelevant skills. For example, Taylor says, a developer who proclaims proficiency in basic business applications such as Microsoft Word is working against herself. "A programmer I am interested in hiring should have enough relevant experience that padding a resume with trivial items is unnecessary," Taylor says.

That also means leaving out experience, such as the stint in high school where you worked at a retail job, when you've had more than ten years of experience. "Telling me about high school or college clubs, honors, and the like when you're a mid career professional is just silly," wrote one HR pro. "FORTRAN, COBOL, and other obsolete programming languages really make you question how strong the programmer is in object oriented best practices," said another.

None of the HR people I interviewed for this post said so directly, but long ago I was advised to leave off my résumé any technology that I didn't want to work with today. I may once have been a goddess of OS/2 system internals (well actually, yes I was), but if I'm not prepared to accept a job doing that today... leave it out.

Don't be irrationally loyal to a system or exhibit your pride in being an early technology adopter — not with the HR people, anyway. Submit a résumé in .doc rather than .docx or Open Office's .odt. If a recruiter can't open your file, I was advised, she's not going to try very hard to find a way to view it.

Here's three résumé items that will get one technical recruiter (at a 70 person firm in the Pacific Northwest) to hit the Delete key:

• Hasn’t worked in 9+ months without addressing reason why. Even in this economy the mid to senior level developers are finding jobs with only a few months gap. So unless you tell me right away why you haven’t been working (school, travel, etc) I am going to assume you aren’t very good.
• Out of the country and looking to work remotely. I haven't found a client yet that is open to paying a fee to find them this type of candidate.
• No experience in the language/tools relevant to the position. Missing some of the tools is fine, but if you are a 10+ year embedded C developer, my client won’t look at your résumé for a job requiring 5+ years of Java experience working on web apps.

Some advice given by recruiters is certain to rub programmers — oh, excuse me, software developers — the wrong way. For example, Marsh Sutherland, president of Walden Recruiting feels the word "programmer" elicits old school mainframe programming. "Modern titles are software engineer and developer," Sutherland says. I'm not sure that most techies would agree (but then I just had a reader write a long diatribe about the difference between "journalist" and "reporter," making a distinction that nobody I know in the profession would recognize). But it's what the recruiter thinks that counts, because it's the recruiter's hand on the DELETE key.

More important, perhaps, is the language used in your résumé that's meant to appeal to the techie manager to whom you hope to report, not to the HR person who has to examine the résumé. One HR pro was ready to dump "silly job titles that are screaming to be noticed," such as "Web site dazzler," which "seemingly never get you noticed." Stephanie Krebs, who works at Sapphire Technologies, is also turned off by "programming guru" because she sees it as overselling; someone always knows more then you, Krebs says. (Perhaps the lesson here is to have a buttoned-down résumé for when you submit to an HR department, and the personable appeal-to-other-techie version for when you know you're applying directly to a technical manager.)

That's plenty of negative advice, isn't it? All sorts of things you should avoid doing. But what do HR professionals and job recruiters want to see on a programmer's résumé? We'll cover that in the second part of this series, next week.

I could probably write a whole blog post asking you, "Which books most influenced your programming or IT career?" Any maybe, one day, I will. But there's no doubt that my Top 5 would include Jerry Weinberg's Secrets of Consulting, a book that that helped me get past programmer-think (in which all is logic and code) to explore the nature of giving advice for pay. In a series of easy-to-read anecdotes, he helped me get my own consulting practice off the ground in the late 80s, by teaching me how to deal with difficult clients, what to do when the client wants more than I thought I had agreed to, and other business issues that didn't come naturally, at least not to me. I've interviewed him on a few occasions, such as The Unfulfilled Project, and we've had a few spirited conversations in which Jerry has gently shaken my assumptions.

However, I'm far from the only person to be influenced by Jerry Weinberg, who's written books and articles on topics that range from computer systems and programming to education, problem solving, and writing. And, in a move that's remarkable for our "what have you innovated for me lately" industry, Dorset House recently published, The Gift of Time: Essays in Honor of Gerald M. Weinberg on his 75th Birthday. You may want to take a look at it — even if you haven't encountered Jerry before — for two reasons. First, the Who's Who of contributors both shares useful lessons for software developers (I'll get to those in a moment). And also because it's a good thing, every so often, to acknowledge how much we have learned from other people... and thus to contemplate the ways in which we influence the people around us.

Jeez, that sounds so self-conscious. Would you listen better if I said: This is fun, thoughtful reading?

Because it is, at least in summary. These are not fannish love letters from some of the top names in our industry (such as James Bach, Esther Derby, and Tim Lister). Most are standalone long-ish articles on topics that can help us do our jobs better, which just-so-happen to be inspired by Jerry. As with any collection of essays (or short stories), some will appeal more than others. A few didn't hold my interest, and I skipped ahead — but the good ones make the book worth the purchase price.

My favorite probably is Tim Lister's essay, "The Consultant's Consultant," who shared a consulting situation that was all too familiar to one I recently experienced (on the user side of the table). Lister's client had a big IT project that had been divided into three releases, spread out over a year or two. But the users "unreasonably" insisted on non-showstopper features being included in Release 1. When Lister researched the reasons why, it turned out that the corporate culture put all emphasis and staffing on Release 1, then less and less priority on Releases 2 and 3. "They didn't believe that their Release 2 was coming any time soon, and they believed Release 3 was fiction," Lister writes. As a result, users fought to get as much into Release 1 as they could. Lister didn't find a magic bullet to solve the problem (I don't want you disappointed, looking for an answer that isn't there) but I liked his analysis of the problem and how/why a developer or consultant might find and address it.

I also enjoyed the anecdotal interplay in James Bach's story about his software testing exercise using playing cards, and how Jerry continually pushed the assumptions and rules. ("'There are four cards,' he replied with comic indignation. Then he pointed at a napkin on the table. 'I call that a card. . . . It looks like a card to me. It's made of paper. It's flat.'") Jerry opened himself to learning about potential variables and thus, says Bach, "He was practicing the first responsibility of a tester."

I've also long admired Esther Derby's sensible advice for IT managers; as an editor, I've enthusiastically assigned her articles like Stop Demotivating Me!. For A Gift of Time, she wrote about congruent feedback, sharing advice about how to give feedback to the people you work with. Certainly, she was inspired by Jerry (who told her, "If you can tell a coworker that he has BO and he feels you've given him a gift, you can offer feedback about any situation") but Esther's advice is very much her own — and, as I've come to expect, thoroughly worthwhile.

Depending on your background, your current itch at work, or your temperament, you might be more engaged by different essays, such as Johanna Rothman's "Writing is the One Surefire Way to Avoid Writer's Block" or Naomi Karten's "The Wisdom and Value of Experiential Learning." But I do expect you'll like at least a few of these as much as I did. End result: This is a book worth reading, even if you've never heard of Jerry Weinberg.

Anyone who has spent any length of time as a computer consultant (either as an individual or as part of a programming team) has at least one sad tale of woe. Sometimes it's a clueless client; other times it's a dumb technical mistake you made yourself. But all too often, the developer's error is in the legal contract she signs. With the help of several people who painfully admit to a "learning experience," (with names omitted) today I'll share several ways a contract can go wrong. I'll also point out what could have been done differently — so that you, o best beloved reader, do not suffer the same ugly fate.

These anecdotes are related primarily for developers who are also computer consultants (or wondering if they dare to hang up their own shingle), but they are equally relevant to programmers who write code for their company's internal use. Every time you read "contract," you can just substitute "agreement with your user."

1. No graceful exit strategy. The first story is my own. Once, my two-person company had a contract with a then-major minicomputer company to write a custom QA application for a new hardware line. (This is before I became a computer industry journalist, obviously. It's long enough ago that I could write "major minicomputer company.") The contract was split into several phases, and was slated to last for seven or eight months. After a long contract negotiation in which the client got picky about a few dumb items (one of which would have had us working for free), we finally got to work. The first phase went fine. But during phase 2, suddenly things went awry. Literally, over the weekend, the client went from "This is great!" to "This isn't intuitive. Fix it." To make a long story short, we walked away, mystified and broke, since we'd budgeted for a solid six months of work from this job.

In my case, the universe was kind; years later, I found out the rest of the story. An ex-employee of the (now defunct) microcomputer company told us that the hardware line for which we were writing the app was canceled. The contract didn't give the company any way out except to reject the prototype in Phase 2. Otherwise, by the letter of the contract, they would have had to pay us for the entire six months of work. The client might have been honest with us (and we'd likely have negotiated with compassion) but I suppose they didn't think they could take the chance. To this day, I can't believe that we spent so much time on the contract without any other kind of exit clause. I learned to look for a clause that lets either party walk away in the case of unforeseen circumstances, with options that are fair to each party.

2. Beware scope creep. Scott had a time and materials (T&M) contract with a client who was a referral from a colleague. Before work began, they agreed on rates and the scope of the work, and he provided an estimate. Scott stayed within the estimate and scope and delivered on time. "When I presented the bill (which was actually 15% below the estimate), they offered a partial payment that was less than half," he says. "Being a one man shop, I accepted the payment, though advised them that that was not how I did business with small projects and that the balance would need to be paid off within 60 days. Then they expanded the scope, claiming they did not understand that they would not get all of these features that were never discussed at any level, and would not pay what they owed until they got it."

Scott's position got a lot uglier and finances headed south. At the end of the tale, he accepted a salaried position six months later at a 30% reduction in income.

Many woes are wrapped into the label "scope creep" but this particular horror story exhibits several. Most consultants I know expect some kind of down payment from a new-to-them client. At the very least, there should be a phased approach with interim releases, and payment made at the acceptance of each release. By requiring payments to be made at fixed stages, a consultant can limit the financial damage if something blows up. (If nothing else, you learn whether their idea of "Net 15" is measured in weeks rather than days. But getting paid is a different subject; I'll save that for another time, assuming you exhibit interest.)

Scott's situation also implies that the "scope of the work" was not adequately documented; the client may very well innocently but wrongly assumed features to be included because gosh, he thought of them. The phased delivery also gives the client an opportunity to make changes — to which the answer is always, "Why certainly we can do that. And here's how much extra it will cost you."

3. Fixed price gone wrong, terribly terribly wrong. Bob was once co-owner in a small Bay Area custom software development firm. Initially, they made good money doing fixed-price contracts because their clients were all reasonable folks. "Then we got a client who wanted a Windows-to-Mac port of a GUI front-end for a CD-ROM-based database," he writes. "They claimed they couldn't provide a complete functional specification for the software, but they had a marketing feature list, and we had the Windows version to play with. So we agreed to match the functionality of the Windows version." Boy, was that a mistake. The Windows software had crazy, non-obvious features which they'd only discover when the client reported a test version didn't work. They lost their shirts on that project, and soon learned that any project with squishy scopes was a bad idea. "I decided to never do anything but T&M again. Life is too short to argue about things like that," says Bob.

You can't blame a client for wanting a fixed price; none of us wants a big surprise, especially when budget approvals are part of the client's business process. But by my observation, fixed price contracts only work when you-the-consultant have a lot of control over the entire process. Ideally you know the client, the real scope of the project (don't depend on client assurances), and the project priorities (if the fixed price project takes longer than the time you budgeted, how will it impact your other commitments? by which I mean, the other clients who do pay on time and are waiting for you to serve them?).

It's hard to resist accusing the client of mal-intent (if not reproductive acts that are physically impossible), but what's funny-or-scary is that most of them simply operate out of computing and business innocence. As Bob says, "That client kept coming back off and on for almost a decade, wanting us to work the same way: no specs, fixed price, yadda yadda. And they just couldn't understand why we didn't want to do that again."

4. Protect yourself from those who would steal from you. Mark, the practice VP for a small regional consulting firm in the midwest, negotiated a contract with a health care services firm to provide applications enhancements, security and related project management. "We had a rock-solid contract with the client and our consultants, including to not discuss rates, and mutual protections against hiring each others' staff," Mark tells me. But after a few months, his project too went from "Awesome job!" to "What's happening?!" over one weekend. In Mark's case, the problem was caused when the client attempted to hire two of his consultants directly (clearly a breach of contract), and one consultant divulged rates and costs. "We got paid for our work to that point, but the project was canceled when we refused to totally ignore their little indiscretion," Mark says.

There are, alas, endless variations on this theme. Bob, from the previous scenario, says that on two occasions people gave their confidential bids to competitors, who then undercut them. "From the first, I learned that a software design should never go into a bid, and if the client wants a design, it's a deliverable to be paid for at a very, very high rate," Bob says.

Howard, a consultant I've known online since the beginning of my consulting career 25 years ago, learned to look at his contracts for time limits, with a default action taken if nothing is done. For example, he was handed a contract that said all billing needed to be for approved timesheets. "I added a clause that said that if timesheet was not approved or rejected (with explanation) within 7 work days, then it was to be considered automatically approved." That clause would prevent someone from stonewalling the approval process to prevent Howard from getting paid; it also (in a more common and benign situation, but no less financially painful) covered the possibility of the approvers being on vacation or otherwise unavailable.

You can't think of everything. But one wonderful bit of advice I was given, around the time I met Howard, was to view the contract as "What to do when everybody wants to screw each other." Sweet new consultants blanch at such a thing; after all, we like the client, we would never want to hurt him! But my advisor from long ago pointed out that project problems never arise from what's in the contract; they come from what isn't there. A contract clause that says, "Client will pay for..." might be irritating but it won't make anybody angry (except at themselves for agreeing to such a stupid thing). It's the items that nobody agreed to in writing that cause angst. If the contract doesn't say who'll pay for the such-and-so, that's when the shouting starts — and the lawyers lick their lips.

There's four horror stories — and their lessons — to begin with. Feel free to add from your own experiences, to save some poor soul the pain you went through.

The job-acquisition dance sometimes seems like it has two performances. There's a public, polished show in which everyone (both candidate and company) tries to make themselves look as attractive as possible, and at the same time there's also an undercurrent in which all the participants are trying to guess what the others are "really like." Sure, he claims to be a JQuery expert, an SEO god, and a bowling champion, but is he really? The company says it's dedicated to the welfare of its employees, blah blah blah. You wonder if they mean it.

When you're desperate for a job, any job, then maybe you feel like you don't have options. We all have to put kibble into the kitty bowl, after all. But when your straits are not quite so dire, and you can sensibly recognize that job interviews go two ways — though it surprises me how few people (especially software developers) keep that in mind — it's important to judge whether you'll fit into the company culture. You want a job that makes you excited to get up and go to work, don't you?

So I was particularly interested in reading 8 Ways Job Seekers Can Assess a Prospective Employer's Corporate Culture, written by my ex-colleague (and, I hope, friend forever) Meredith Levinson. Meredith interviewed Vanessa Hall, author of The Truth About Trust in Business and, as always, she did a fine job at drawing out the author's opinions.

But really, I think Hall left entirely too much on the table. While I don't really disagree with anything she told Meredith, I think the advice on how to evaluate the company culture could stand to be far more granular. When it starts looking like you'll be offered the job, and you start to wonder if you'll say Yes, here's some of the things I'd consider. (Naturally, I'd start with several of the questions in 28 Questions You Wish You Asked the Manager During the Job Interview and, just for balance, read the comments on 19 Ways to Know The Software Development Job Interview is Over as a cautionary tale.)

Laughter. I assume that, at some point, you walked through the halls in the office. (If you only saw the HR rep's office or met managers in a conference room... I'd worry. If nothing else, it'd mean you couldn't judge the next point.) How often did you hear people laughing? Even when people are intent on doing their jobs and wholly lost in a warm creative fog, they smile when they interact with other people. Try to step back from how you felt in the interview situation and try to assess the mood. It's one of the few useful things you can do sitting in the lobby, waiting for the HR rep to arrive. Watch people. See if they're glad to be there... or if they look desperate and scared. If they are laughing with one another, and you see this several times, I'd start to feel good about the company.

The office layout. Some people like to collaborate in big wide open spaces; others want a door that closes. (Me? I want a cat nearby. Now you know why I telecommute.) There's no one right answer for this — except that which makes you happy. It's an actual example of where "company fit" means what it says (and not "We just didn't like you" or "I can't believe you wore that dress to an interview."). I wouldn't judge the company culture too harshly based on the money spent on the office space; plenty of start-ups sensibly invest in their people rather than in deep pile carpet. But I'd glance at the walls in employee's offices and cubes. If it's stark and cold... well, that's a -1 for me.

Evidence that the company works towards quality. I hope you asked other developers (or people at roughly the same level as you) during the interview: When was the last time the company sent you to a conference? or paid for training? (Listening to the way in which they answer the question is another way to judge the organization's emotional tone: resentful? grateful? matter-of-fact? What is it that employees take for granted?) Presumably you also asked about the tools you'd be working with... not just the favored programming language or IDE, but the other software that's intended to make you more productive, such as performance tuning tools, version control software, or whatever makes sense. The latter might include people. If everything about the programming job sounds spiffy but nobody is actually dedicated to software testing, you have a big fat clue about how much (or little) the organization cares about helping you create the best software possible.

Evidence of collaboration and openness. With whom did you interview? Just the managers — none of the people who'd serve on the same team as you or who would report to you? Sometimes it isn't possible to have full transparency in the hiring process (particularly if you're still working elsewhere and want to keep negotiations secret), but I'd look at whether the expectation is that team members' opinions matter. I believe that it was in Peopleware that DeMarco and Lister first recommended that a job candidate have lunch with the people she'd be working with. Certainly that's been useful in my own experience; it helps everyone decide if they want to spend at least 40 hours a week hanging out with these people... and laughing with them. (Playing Dungeons & Dragons with the candidate is optional, though.)

I'm sure that I'm leaving out other things you can do to really test the company culture. What would you suggest? Or, to put the question another way: If you ever had a bad job experience... what might you have asked or done ahead of time to avoid it? Let's see if we can save someone else from making a really bad mistake.

Programming communities and corporate culture naturally encourages the development of peculiar nomenclatures and in-the-know jargon. As a demonstration, here's several expressions and terms used only — or primarily — by people who work at Microsoft... and not used, really, by anybody else.

I've given more thought to my blog post from last week about the architecture of programming communities. Although that post emitted a warning, I don't want to give the impression that it's a Bad Thing for people to create workable teams. I just want to highlight the ways in which the walls we build to help ourselves can sometimes block others out.

When people work together regularly, they naturally create shortcut expressions based on common experiences — and not just in programming. When I worked for a compiler optimization company, my boss and most of my dozen coworkers were also fans of Arlo Guthrie's ballad, Alice's Restaurant. It was a function of our hippie background and the high per-capita Folk Musician population of Deer Isle Maine, I guess, but certainly we all knew most of the lyrics.

I'm not sure who started it, but as a conversational shortcut in meetings, company employees summarized, "I explained to the user all of the details that we have discussed at great length before, including bla-bla-bla..." (you know how those explanations can drone on) as, "I showed her the 27 8x10 color glossy photographs with circles and arrows and a paragraph on the back of each one explaining what each one was, to be used as evidence against us." Which itself was soon shortened to "circles and arrows." Thus, to this day, I'm apt to say (to those who'll understand, including that old boss who continues to be a friend), "When the client asked why his site had crashed, I gave him circles and arrows." When someone outside the circle (heh) understands that expression without me explaining it, I feel as though I've found a friend.

I've come to refer to these as "married-people macros;" I'm sure you and your spouse have a few of your own. But in our professional lives, it's those shortcut expressions that help us create communities with in-the-know jargon... and maybe (to a small but usually harmless degree) exclude those who aren't sure what the specialized term means.

And sometimes it's just a mark of corporate culture.

For example, Microsoft folks use "rich" more often than anybody else I've seen, from "a rich user interface" to "rich text format." I don't think I've seen a single Microsoft press release or tech presentation that missed out on the opportunity to use the rich term even when it adds no actual meaning. In fact, I've sometimes amused myself by substituting "high-cholesterol" or "with extra butter" while reading their press releases.

Some terms, I suspect, were either generated first at Microsoft or were made popular within the company... and then escaped. One of these may be the term "decks" for a collection of PowerPoint slides. I'm sure that I heard it first from Microsoft people, but now the expression has escaped into the wild. (I wish it'd escape back, but I do admit that presentations no longer uses actual overhead projectors. On the other hand, someone referring to a "deck" in a painful PowerPoint presentation suggests to me, "I could deck him..." which is a dangerous temptation I'd like to avoid.)

However, there are also some Microsoft terms are that linguistic curiosities. While nobody seems to imagine that Microsoft was the first to use the expression "eat our own dogfood" (i.e. use and rely on the technology we develop), as far as I know Microsofties (by which I mean company employees and those closely allied with them, such as business partners and MVPs) are the only ones I've encountered who use "dogfooding" as a verb. Similarly, others might use the expression "go down a rathole" (that is, "to digress in an extensive way") but, I am told, people at Microsoft use "rathole" as a verb.

In fact, one Microsoft employee confided, the Microsofties "verb" almost everything. There's also lots of words for shipping software, as you can imagine, many of which are verbed. For instance, I'm told, there's a large meeting towards the end of a product's release called "shiproom." "So we'll say something like 'Take this to shiproom and tell them we're not the long pole any more,'" my friend explained. "Long pole, by the way, is the team, group, or feature that will take the longest." Me, I thought it was what you were up the creek without. Or "on the critical path," in old-style project management lingo.

These are only a smidgen of Microsoft terms. One kind soul pointed me at The Microsoft Lexicon, in case you want to put together your own trivia quiz.

I confess that I'm intrigued by this behavior largely because I love language and how it intersects with community. (How else could I use my most-of-a-Linguistics degree?) So I find it fascinating to watch how groups share knowledge, invent expressions, and then summarize them... not the least of which is a tendency to "verb the nouns" (even if specific examples irritate me) and to turn expressions into community macros. There's a master's thesis in this for someone, I betcha.

Last week, I pointed out that communities rarely take the time to gaze into their own navels to observe the effect of their behavior. I picked on Microsoft here, but not because there's anything specific to the company. I think most companies have their own expressions, and most programming communities develop their own jargon. What are some that you've encountered, in your own organizations?