Avoiding hell at work by spotting Dilbertian job descriptions

Everyone wants that dream job, but it's often hard to tell a dream job apart from the Dilbert job - you know what I mean - boring work, lots of finger pointing, technical people marginalised, pointy haired boss makes all the money...

So here's the thing about job descriptions - they always contain a certain amount of hyperbole. It's a fact of life. The trick is to take a close look at the bits which use words like 'leverage', 'teamwork' and more recently, 'rock star'. Examining the hyperbole in a particular job description can give applicants a fair idea about the nature of the company, and possibly even the nature of their future boss.

Here are some of the standard JD patterns that any Google search will turn up. I'm compressing job description to JD - I'm too lazy to type it every time.

1) Requirements that aren't filters
So there's this JD which has a requirement 'should be a team player'. Do you seriously think any applicant is going to look at that, say 'Nah, teamwork isn't for me' and move on? Or to put it another way, some requirements simply state the obvious. This is especially true if adjectives are used, but without any subject. For example, compare these two extracts:

+ Should be passionate about Ruby
+ Should be self motivated and open to learning and working on new languages and platforms

as opposed to

- Should be passionate and self-motivated
- Should be dynamic, with high energy and enthusiasm

In the first case, it is clear that someone who knows something about the job has used those adjectives, not some HR drone trying to create meaningless filler content. The subjects to which those adjectives are applied are clear and applicants can use them to make decisions.

Count the number of requirements which don't really help you as an applicant decide if you're a fit for the job. Less is, of course, better.

Some key phrases to look out for:

• Excellent team player
• Strong work ethic
• Highly motivated, dynamic, passionate
  
• High energy and enthusiasm
• Flexible
• Open and honest (ha ha, I'm sorry, remembered some Dilbert cartoons)
  

2) Requirements that are plain impossible
This one is simple and obvious, so I won't spend too much time on this one. If you see any of these, run for your life - the company hasn't a clue.

Look for stuff like:

• Minimum of five years experience with Rails
  
• Minimum of nine years experience designing and developing enterprise class applications in .Net

Rails was released in 2004, and .Net in 2001. This article was written in 2007.

3) Requirements that are all over the map
I'm talking about a JD where the requirements are so generic and broad that they cover just about everyone in the field. The requirements aren't necessarily contradictory - but they aren't complementary either.
Here's a sample:

• Extensive experience developing in Perl/PHP
  
• Strong foundation in XHTML and CSS
• Extensive experience in developing in Visual C++ including MFCs
• Strong foundation in networking protocols

Steer clear of such JDs unless there is a clear thread linking all the requirements. It's most likely that their HR is just fishing or there is a major disconnect between HR and the department looking to do the hiring. In India, there's a clear and present danger that you're being hired for the bench.

4) Weird or pompous designations
Watch out for weird designations for the job in question, especially if not accompanied by an explanation - either the job is really cool or really mundane. The people writing JDs often invent weird designations for a position if

a) They want to stand out and attract cool people
b) They want to disguise a mind numbingly mundane job as a funky one
c) They want to use your ego to get you do something fairly run-of-the-mill

It's the latter two that you need to watch out for. For example, in Bangalore, it's now understood that if someones designation is 'Marketing Executive', they are essentially salespeople. Every fifth person in Bangalore is an executive of some sort these days. Unfortunately there is no hard and fast rule to tell the first apart from the second and third except to research the background of the company. A designation of 'Hacker Dude' at a startup is much more plausible than 'Hacker Dude' at any one of our 70,000 employee local outsourcing behemoths. Companies which let you choose your own designation are the best (shameless plug: guess which company fits the bill...)

5) Corporate babble
You've seen this in a thousand places - stuff like "As a senior architect, you will focus on developing collaborative strategies to leverage the latest technologies and maximise productivity". Yeah. Whatever.

OK, my example is a bit over the top, and you'll always find some amount of this gunk, especially around the description of the company itself. Often it's fairly innocuous - stuff like 'work on cutting edge technologies', or 'leading innovator'. Sure, that's sort of OK, you can understand why it's there and it doesn't directly affect you.
However, the more babble there is, the more care you need to take. If meaningless babble like that is being used to describe the job itself, steer clear - PHB ahead.

6) Appeals to a misplaced sense of duty
I've met people who've been brainwashed by their employers into thinking that working fourteen hours a day, every day, is really cool. They (the employers) manage this by appealing to employees (misplaced) sense of duty and loyalty. JD writers know this, so watch out for stuff like "aren't afraid of working around the clock to make things happen". Again, this depends on context. Working for a startup is very much a 24 hour job, and you're doing it because you own a part of the gig. Not so with your regular company.

All things said and done, there are a bunch of cool people out there, and a bunch of cool companies where they'd like to work, and who in turn would love to hire them. We just need to figure out standard patterns to identify each. In this case, the cool companies somehow tend to have a minimum of these JD anti-patterns so it isn't too hard to identify them simply by examining the JDs they put out.

Do let me know if you've come across any JD patterns or anti-patterns of your own.

Read the other side of the story: Be the nail that sticks out - how to get hired by an interesting company

Be the nail that sticks out - how to get hired by an interesting company

When I've posted about recruitment in the past and how ThoughtWorks strives to ensure that truly passionate and competent people are hired, at least one comment says "But do we really need that level of competence in plenty?" or something similar. It's an interesting question, but its obvious by observing hiring practices in India's vast outsourcing industry that most people don't think so. The question is, what does this mean for the developer who cares about his code?

Traditional career paths treat writing code as a menial task (that damn 'software is a commodity' philosophy). To get anywhere, you have to make team lead in 2 years, architect/project manager in 7 and then you start scaling the heights of upper-management. You need, essentially, to go from being a hacker to being a suit. This means that at most companies, it's people who have 0-4 years of experience who actually write code. And most of the time they have little say in the design or other decision making - a highly frustrating position to be in.

So the obvious step for someone who is an alpha geek in the wrong job is to find another, more suitable one. And the truth is, there aren't that many programming jobs out there which would suit. Worse, these jobs are distributed across several companies ranging from Google down to small start-ups in stealth mode. One ray of light is that the personnel departments (I dislike the phrase 'Human Resource', I mean, come on...) of these companies are as desperate to hire you as you are to work for them. In an industry flooded with 9-to-5 developers for whom writing code is 'just a job', separating the wheat from the chaff can be very difficult indeed.

Here is some advice to help get yourself noticed by such companies. Interestingly, they will work as a filter to weed out employers like the one you're trying to get away from. It's just two words - 'stand out'.

1. Be opinionated. You can't write code, care about it, and not have opinions. In your current organisation you may get hammered for it, but hey, that's why you want to quit in the first place, right?
2. State these opinions somewhere for the record. A blog, perhaps. It shows the evolution of your opinions over time and gives you a talking point during an interview. Please don't blindly copy someone else's. Of course, if I needed to tell you that, then I'm targeting the wrong audience with this post :-). I'm assuming you'd be too proud to do that anyways.
   
3. You don't need to make your resume conform to the industry standard. For gods sakes, some of the things I see on resumes under the 'Objectives' section are plain silly. I'm pretty sure that the people who wrote them thought they were silly too, but were forced to put them in there because everyone knows it's expected in a resume. If a company won't hire you because your resume doesn't have an objective along the lines of 'To strive for the betterment of the organisation and for personal growth to achieve success', then you probably don't want to work there, right?
4. Don't make assumptions about career paths. Most organisations where alpha geeks are respected also have flexible roles.
   
5. Say which programming languages you like in your resume. Also say why. Like I said, if you think Java is an ugly language and someone won't hire you because of that (despite the fact that you've done n projects in java, know it well and thus have a sound basis for your judgement), then you probably don't want to work there, right?
6. Try to publish some code on your blog or on Google code or something. Link to it in your blog and your resume. Put your code where your mouth is. If you are what you claim to be in you resume, then prove it in code. My initial impression of someone goes up substantially if they've linked to their code in their resumes.

If you have any additional suggestions which I can add to this list, please let me know and I'll drop them in.

Update 2007-07-01: As promised, here are more suggestions distilled from the comments on this post. Do keep them coming.

7. Sunil: Some people I've come across have half-baked opinions, that they throw around to impress. I'm sure they'll be shot down during interviews. Know your stuff before you go around pronouncing opinions.
8. Amy Isikoff Newell: Be a woman.
9. Amy Isikoff Newell: Be honest. If you took time off for something important (like having kids), say so in your resume instead of trying to hide the 'gap', as they call it.
10. Neil Bartlett: Look for opportunities to speak at conferences. Start small, for example with you local User Group, work up from there, and in a little while you could be presenting at JavaOne.
11. Sidu: List your programming experience as far back as it goes. I have more years of BASIC than C++ and more of C++ than Java/C#/Ruby (and this is true for several of my classmates from school). People who have done programming in school usually tend to choose it as career because they've tried it for a while and decided they like it, not because it offers good job prospects (something which happens a lot in India).
    

You may also want to read: What developers look for when they consider a job offer

Strategies for recruiting top notch developers in a flooded job market

Hiring experienced and competent developers in India is a very, very difficult job. Not because developers are hard to come by - but because there are just so many of them that filtering out the wheat from the chaff is a herculean task.

This post includes an explanation of why this problem exists, forces in the environment which exacerbate the situation and a description of how ThoughtWorks' recruitment practices attempt to solve at least some portions of the problem.

Understanding the root of the problem
Let's start at the beginning. Why is the Indian job market currently flooded with developers? The answer to this question is fairly simple - lack of opportunity.

For nearly fifty years after independence, the only opportunity for a kid from a middle-class family in India to make it big involved studying engineering or medicine and then moving to America. Interest or inclination had little to do with career choices - one had to be pragmatic in order to be able to support oneself. While this situation has improved over the last decade or so, engineering and medicine are still the only courses which guarantee some form of employment.

Sometime during the mid-nineties, a new field of engineering surfaced in mainstream Indian colleges - computers. Here was an engineering discipline which didn't need lakhs of rupees in investment to create lab infrastructure. Buy a dozen desktops and hire a few teachers and you're ready to roll. Soon, newer colleges which only offered courses in computers started appearing. These 'IT' colleges as they were called were a great success, with as many as a dozen new ones opening every year.

Then came the outsourced services boom and suddenly there was a huge market for these skills, with far less competition than was needed to go abroad. You no longer needed to crack the incredibly difficult IIT-JEE entrance exam (probably one of the most difficult in the world for a bachelor's degree) and make it into the IITs to achieve a good standard of living - an IT job guaranteed a salary far above what was normal at the time for fresh graduates and a standard of living to match. Of course, the cream still went abroad - the advantages of more than a hundred television channels, social security and spray paint in cans (something unheard of in India even today) were undeniable.

That trend has continued to grow to the point where today, roughly 10,000 students graduate every year with some degree in computers. A very small percentage of them actually enjoy writing code and learning new stuff in the field - both very necessary prerequisites for a successful programmer. This has resulted in a dramatic drop in the overall quality of talent available at the entry level. Some companies have simply stopped looking for knowledge of computers and now hire anyone with a BE in any field. The logic behind this decision is that the knowledge of computers one can expect from someone with a BE in, say, chemical engineering is much the same as someone with a BE in computers. The company doing the hiring looks for a base level of aptitude (indicated by the fact that the candidate has earned a BE) and proposes to train them themselves. The degree to which this affects the job market is clearly visible in the number of applications the bigger services firms receive. According to this article in the Economist, Infosys alone receives approximately 1.3 million applications every year, most of them unsuitable.

One must also keep in mind that this is equally hard on the all the people forced into software because (unlike in the first world) one does not get employment simply because one is educated in a certain area. I have several friends who graduated as engineers in various disciplines who have been forced into software jobs simply because there was no other alternative. If this is the case with engineers, it is easy to imagine what the situation is in fine arts, nursing or any other field where demand is driven from within the country rather than from without. But that rant is worthy of an entire post and I'll get around to it some other time.

One complicating factor is that demand from the software industry has also grown proportionately. The leading services firms like Wipro and Infosys routinely hire 20,000 people every year. A simple Google search for the keywords Infosys and hires brings a wealth of information to light. This makes for a very competitive market, where demand actually outstrips by a substantial margin.

Another is the way in which the career of a developer progresses in the majority of Indian firms. It is taken for granted that everyone eventually wants to become a manager, since that's where the money is. Whether he likes it or not, but his second or third year a developer is a team lead and by his seventh a project manager. Each step up the ladder means less hands-on coding - which most don't really miss anyway. The leveraged model followed in these firms result in developers being treated very poorly, with all the benefits accruing to managers. At the time of writing, the average developer with two years of experience could expect to earn approximately four lakh rupees a year before tax while his project manager took home that same amount simply in bonuses, with his entire package amounting to five times that. Finding a developer with ten years of experience is practically impossible. All you'll find are people with ten years experience who are managers and who used to be developers five years ago.

ThoughtWorks' recruitment process
There are two basic principles

1. Leave assessing the capabilities of developers to other developers
2. Don't hire developers without seeing their code
   

I'll get to these in a bit; we first need to do some filtering. Unfortunately, I have no earth shaking revelations here. The process is quite simple.

1. Recruitment receives a CV
2. They give it a once over to check that there is alignment in technologies (at the moment, this would include Java, C#, Ruby and Python)
3. They look at the project work the candidate has been involved in. This is especially important for fresh graduates as little importance is attached to pure academic performance. The question is: Is the candidate interested in coding?
4. They call the candidate in and administer a written test consisting of a dozen logic based questions - hardly rocket science.

Once the candidate clears this, we move onto the next level - writing code. Like Joel Spolsky says so succinctly in point 11 of 'The Joel Test', 'Would you hire a magician without asking them to show you some magic tricks? Of course not.' I personally feel it's pretty unrealistic to hire a developer without having him write code. Indeed, we feel so strongly about this that we get them to write code not once, but twice. The reason we actually have that logic test I mentioned is simply to ensure that ThoughtWorks' developers don't get flooded with too many code reviews and interviews. It isn't the best way to filter by any means, but it'll have to do until we come up with a better way.

So once a candidate clears the logic test, we send him a coding problem and ask him to solve it in (at the time of writing) either Java or C#. If the candidate prefers to do, say, C++, Ruby or Python, that too is acceptable. Once the candidate solves the problem, he emails it to us and it is assigned to a developer for review.

The objective of the review is to see if the style of writing code is up to the standard that we expect on our projects. This standard would of course vary from organization to organization depending on the kind of work they do - a company which specialises in kernel code in C may be completely indifferent to the candidate's Object Oriented Programming skills. In our case, the focus is very much on OO - for example, we occasionally receive code badged as C++ but which don't have a single class and is purely procedural. Such a submission would not be accepted because it doesn't make sense given the kind of work we do. The reviewer does base his expectations upon the number of years of work experience - you can't realistically expect a college grad to write unit tests, say. If they do, that's awesome, but if they don't - no big deal.

Once the candidate's code clears the code review, we enter the final stage of the process. The candidate is asked to come into one of our offices for a round of 'pairing' on his code. Here, he works with a ThoughtWorks developer to modify his code submission to handle the same problem but with more complex requirements. There are several takeaways. First, people who fudged on the code submission will never make it through this round. Second, the ThoughtWorker doing the pairing can fairly accurately assess the level of competence of the candidate, his openness to new ideas and his general exposure to programming concepts in general.

The pairing is followed by two rounds of interviews, with a couple of ThoughtWorks developers on the panel in each. I'm not going to go into the style of interviewing in detail - personally, besides technical competence, I look for two things:

1. Does the candidate have opinions on technical subjects?
   
2. Is writing code one of the top three things the candidate does in his or her spare time

Here I don't look for a 'right' opinion or a 'wrong' opinion; it's just a way of assessing the candidate's interest in technology in general (and I make it very clear to the candidate that contradicting the interviewer's opinion is not at all a bad thing :-)). Any opinion is a good thing and I make sure that the topics covered by the question are not something with very clear-cut positives or negatives. The ambiguity makes for good conversation.

These three rounds are followed by all the ThoughtWorks developers involved getting together for a chat and figuring out whether the candidate should be hired. If there is any area where there are still unanswered questions, the candidate may have to face a third panel. The final consensus of these developers is what decides if the candidate is hired or not.

Summary
The Indian job market is flooded with developers. Identifying good developers isn't easy and at a bare minimum, candidates must be asked to demonstrate their competence by writing code and must also clearly prove their inclination toward coding for fun.

What developers look for when they consider a job offer

This post focuses on listing what developers in India look for in a job. The importance various individuals attach to the points listed here will of course vary based on several factors (number of years of experience would probably top the list is my guess).

Please remember that this is about Indian developers. While a $2000 laptop may be 2/5ths of a months salary to the average beginner in the US, it's about four months salary to a fresher in India. It's value as a perk is thus proportionately higher.

This is an evolving post which I will update and refine based upon the feedback I get. Expect it to be vague to start with. I wish posts had versioning, but whatever. Here's the dope.

Update: 20/11/2006

• Package
  
• Money
  
• Perks/Benefits
  
• Access to cool tech (company issued Core 2 Duo Laptop with a Go 7800GTX/MacBook Pro anyone?)
  
• International Travel (Per Diem earnings in $ or euros can increase annual income by anywhere between 10% and 100% - or more)
• Stock options (post IPO or pre IPO?)
• Bonuses
  

• Quality of Work
  
• Choice of technology/domain. For those so inclined, the freedom to switch languages/technologies/domains/projects regularly
• Challenging work - whatever that means to you
  
• A say in project direction/architecture/technology
• Degree of exposure and learning - New concepts, technologies and ideas. If the organization is home to thought leaders and innovators and they are easily accessible, it's a huge plus


• Work environment
• Politics - the presence or absence of it. Some people thrive on it. Others hate it. I don't know if it is safe to say that developers in general dislike it...
  
• Management - what does a developer have to deal with in order to get something done? Are the managers former developers or technologists?
  
• Work timings - I think it's safe to say that flexible is good
• Work hours - how long is a work day? I have plenty of friends who think nothing of 14 hour days. One extreme case does 30 consecutive hours of work several times a month. He is paid the industry standard wage (around Rs. 15000/$350 a month) for a developer in offshore services with one years experience
• Commute - how long does it take and how exhausting is it?
• Location - is the job in a city I like? Do I have to relocate?
  
• Trust - how much trust exists in the organization. More is better. For example, is it high enough to offer unlimited sick leave to employees trusting them to not exploit it?
• Performance reviews - Who does these? Your manager? Your peers? How transparent is the process? How much visibility do others have into my review?
  
• Freedom of communication - how easy is it to talk to someone in order to get something done? Do you need to use e-mail even if the guy sits in the next cubicle and is on your project?
• Privacy - How much privacy do you have? As much as you feel you need? Or is it so high that it stifles free communication?
• Comfort - How much attention does the organization pay to developers comfort? Joel Spolsky obviously thinks it's very important. Anyone who has seen the photos of Google offices and pantries which are floating around the net would agree that Google is of a similar opinion
  

You may also want to read:

• Strategies for recruiting top notch developers in a flooded job market
• Be the nail that sticks out - how to get hired by an interesting company