Tuesday, September 30, 2008

Larger Company vs. Smaller Company

Another career choice you might face is whether to go work at a smaller company, perhaps a startup, versus a larger established company. If you have not worked for both types of organizations, here are some gross generalizations of the differences you can expect.

True to the stereotype, larger companies often do have lots of red tape and organizational inertia. It can take a long time and many approvals to get anything done, and you might find yourself fervently negotiating with various people to get the tools, accounts and machine permissions you need to do your job.

On the other hand, large companies often have larger budgets for hardware, software, etc., and can afford to throw more bodies at a problem (for better or worse). In most large companies you’ll see large numbers of business analysts and project managers, whose job it seems sometimes is purely to create and manage red tape (I jest… maybe). But they can also be a useful resource and help you deal with the red tape and bureaucracy.

Large companies also typically pay better, at least in terms of starting salaries. They also provide more opportunities for advancement just through their sheer size and natural turnover. However, large companies also typically have strict guidelines on things like salary raises and promotions.

Smaller companies are more flexible in many ways. They may not have as much of a process in place, which can be both good and bad. Such an environment may give you the freedom and speed to do your work more efficiently, but it can also lead to chaos without close coordination, especially as the organization scales up. Not to mention which, resources may be tight, in terms of both money and people.

So which type of organization should you pick if you have a choice? I’d recommend that you get experience in both types of companies. Only then will you be in a position to decide which environment is the right one for you.

Thursday, September 25, 2008

Job Hopping

It used to be that being labeled as a Job Hopper was the kiss of death. If you had too many stints of less than 2-3 years each you were considered unreliable and a risky bet. Perhaps you couldn’t hold down a job, or maybe you were just flighty. Both attributes were frowned upon by hiring managers, and your resume was more likely to end up in the circular file. But times have changed.

More and more I see resumes where people have been in their current or most recent jobs for less than a year – and I’m not referring to contractors, either. I last saw this phenomenon during the dot com boom of the late 90’s, when it was the norm for people to change jobs every 12-18 months. Some say that we’ve been going through another boom with Web 2.0 (though the recession may have spoiled that party).

During both booms there were more opportunities than qualified people, and the candidates that were in demand found it rewarding to change jobs more frequently. The goal was not just to increase their pay, though that was certainly a factor, but also to find better companies and more challenging opportunities. Of course this was not good for the companies that spent time and money hiring and training people, only to see them leave just when they were becoming most productive.

So here we are in 2008 and I’m faced with resumes of people with multiple short stints. Do I think any less of such candidates? That they might develop wanderlust and bolt after a year? Of course that’s a concern and a risk, and certainly one that I have to weigh. But If I believe that my company is an attractive one, and that it’s likely to continue to be attractive vs. other companies, I think it’s worth taking a risk.

So how have my gambles played out? My record is probably subject to selective recall and analysis, but I believe that the vast majority of my hires have stayed on for at least two years. If they stay for only one year I’d consider it a failure, but after two years I’d say we’ve gotten a clear net benefit from them.

Tuesday, September 23, 2008

Lateral Moves vs. Stepping Stones

In general, making numerous lateral moves is not good for your career. It makes recruiters and hiring managers think your career has not been moving forward.

Still, there are cases where lateral moves are warranted. For instance, one obvious possibility is if you lose your job, or are on the verge of losing your job. Any port in a storm, as the saying goes. But let’s put that scenario aside for the moment. What other reasons are there for making a lateral move?

One is when a lateral move is not just a lateral move but a stepping stone. Perhaps you have a certain desired job in mind, but it’s difficult to get there from where you are at the moment. For instance, you’d really like to become an ASP.NET web architect, but you are currently a C++ desktop application developer. Realistically you are not going to achieve your goal in your current job, or most likely, even in your next job.

In a situation like this you may have to take one or more baby steps. Fist, you’ll need to transition out of your C++ desktop environment to a .NET web development shop. And since not too many web shops will take someone with minimal experience in the area, you may have to make a lateral move into a position at a less than stellar outfit, just to pick up the skills.

Once you’ve earned your chops at web development you might set your eyes on the prize, that of web architect. But then, your job as a CRUD web developer at JoeSchmoe, Inc. may not provide a path to a Web Architect position. In fact, your CRUD web shop may not even have architect positions at all. Hence you’ll have to try to land a position at a more attractive web organization, one which has an architect track.

But wait, that glamorous web company obviously won’t hire you on as a web architect, coming as you are from some no-name CRUD shop. They may take you on as a web engineer, however – another lateral move. But now at least you’re in the major leagues, there amongst the pros – and you have a chance to prove yourself. So all you have to do now is show you’re smarter and better than everyone else there, people who’ve been doing serious web development for half their lives. Piece of cake, right?

Wednesday, September 17, 2008

Other Career Tracks

If the senior developer /architect and dev manager tracks don’t appeal to you (and assuming you don’t want to go into QA), there are still a couple of other career tracks you can pursue: Project Management and Product Management.

Project Managers, aka Technical Project Managers, aka Program Managers, are the ones who ‘drive’ projects. They create schedules, track progress, coordinate with other teams, and identify and mitigate issues and risks. Typically however they do not have any technical resources reporting to them.

The actual scope of responsibilities for the various flavors of Project Mangers varies widely between organizations. At Microsoft for instance Program Managers are quite technical and behave more like Dev managers; at other companies Project Managers may be non-technical people who have never coded a day in their lives.

Project Managers often have a difficult and thankless job. Not only do they lack direct authority over the people they need to do coordinate, but many people see Project Managers as unnecessary overhead. Still, some people thrive in a role juggling spreadsheets and Gantt charts. And if they’re fortunate, they might end up in an agile development organization where Project Managers can take a more central, albeit nontraditional, role (e.g., Scrum Masters).

Product Managers by contrast determine product requirements. They may or may not have coding experience, often coming from a creative or business background. What’s important for them is having their finger on the marketplace and being able to see things at a higher level. They are often the ‘face’ of the product or its features to the public and to top management.

Product Managers can specify what needs to be done without worrying so much about how it is to be done, though feature negotiation will still be required with Project Managers and Development Managers. So in many ways a Product Manager position is easier than a Project Manager one, and carries with it more glory and exposure with less of the accountability.

That’s not to say that Product Management is all milk and honey. Product Managers usually have to field countless questions from developers, questions they often cannot answer. And at smaller companies Product Management is often considered a niche position without a full career path like development or even Project Management positions.

Of course, it’s possible for you to move back and forth between the developer, dev manager, project manager, product manager, and even QA (gasp!) roles. This happens more often than you might think, especially at larger software companies.

So my recommendation if you have to make a career decision away from development? Choose Product Management if possible. It’s good work if you can get it.

Monday, September 15, 2008

Development Track vs. Going Into Management

At some point in your career you will face a choice: continue on a technical track or move into a management role. Some people express the desire to do both, but generally that’s not possible, at least not in the long run.

At less desirable companies the technical track usually stops at something like a “Senior Engineer” level, and to advance much further in pay you have no choice but to become a manager. But the better companies will provide a purely technical track with plenty of advancement potential so that engineers not interested in management can still continue to grow.

The advanced technical track may go something like this:
  • Senior Engineer
  • Principal Engineer
  • Senior Principal Engineer
  • Architect
  • Senior Architect
  • Chief Architect
The exact structure and titles will vary by company; many places skip the Principal Engineer grades altogether. Also, the relative equivalent of an architect position to a management position will vary by company. At some places an Architect title is comparable to a Director level management position, with comparable pay; however, at other places an Architect may be nothing special – kind of like how at investment banks everybody and their brother is at least a Vice President.

If you are torn between continuing on a technical track vs. a management one, you should ask yourself what really interests you. Are you drawn towards learning new technologies, coding for hours on end, and solving complex technical problems? Do you love to whiteboard and talk tech with colleagues? You might want to aim for an architect track.

If on the other hand you enjoy the idea of building up a team, assigning resources to tasks, working with product managers, and in general dealing with the bigger picture, management might the path for you. Oh, and it helps if you have pointy hair.

Thursday, September 11, 2008

QA vs. Development Track

If you are a fresh college graduate, or even a few years into your software engineering career, you may be faced with a fork in the road: go into development or QA.

There is sometimes a sense of superiority amongst developers since they are not ‘stuck’ doing testing like the QA people. Hence QA is sometimes seen as a dead-end field, and there is a bit of truth to that stereotype. Once you start in QA the tendency of most companies is to keep you there, and it’s not so easy to switch over to actual development. Which is not to say that transferring out is not impossible, of course -- but you shouldn’t count on it.

If you do decide to go into QA, bear in mind there are often two separate tracks. In one, you’ll do feature testing, usually manually. You run programs, click on buttons, fill out forms, etc., and check that the system behaves as expected according to a set test procedure. This is called “Black Box” testing. It can be rather tedious and unglamorous work. If you’re lucky you may get to write some scripts to automate some of your testing. This position is commonly called a “SQA Analyst”.

Another track is where you are actually involved with the source code. You may review and critique code written by the developers, and you may write test harnesses to exercise the components the developers write. This is called “White Box” testing. You may also be heavily involved writing automated testing tools and scripts. This type of position is sometimes called a “QA Engineer”, and is more highly regarded; it can and often does lead to positions on the development side.

Friday, September 5, 2008

Certifications

Some web developer candidates think that getting a professional certification (e.g., MCP, MCSD, MCSE, etc.) will be the golden ticket into that great job. They may spend hundreds or thousands of dollars preparing for and taking these exams. So are the certifications worth it?

Personally I’ve seen many candidates with certifications and many without. And frankly, I can’t really tell that the people with certifications know any more than those without them. It could be that people take coursework or study for these exams and then promptly forget the material afterwards, kind of like what I did all throughout college. Hence I’ve learned to pretty much discount certification on resumes for the most part.

My advice? The certifications may be a good approach if you are a new developer just starting out and need to learn the material anyway. Or else if you are an experienced engineer but have no real distinguishing characteristics on your resume, the certifications may make a difference with some hiring managers. But if you are an experienced engineer with a solid work history, you shouldn’t bother with them -- they’re just window dressing.

Wednesday, September 3, 2008

Diploma Mills

In case you’re not aware, a Diploma mill is a place that will give you a Bachelor’s degree (or beyond) with only the barest pretense of a formal education process. Often it’s Cash & Carry for a degree.

Some diploma mills are online operations, but that doesn’t mean that all online degree programs are diploma mills. Still, online degrees often carry a bit of a stigma, fairly or not, of being degrees in name only.

There are also some brick & mortar schools which technically are not diploma mills, but which provide something less than the 4-year college experience. I’m thinking of places like DeVry, ITT, and the University of Phoenix. It may be unfair to lump these organizations in with diploma mills, but that’s a common perception, for better or for worse. I’m not addressing those institutions here, only the true diploma mills.

Fact is, the looser the standards at these institutions the more risk you’re taking by putting them on your resume. When I skim your resume I may not recognize the school name (e.g., “Central Intercontinental School of the American Pacific”), shrug, and move on. But the lack of a real education may come through in the interview. And even if you pass the interview, the true nature of the school will likely be revealed during the background check.

My advice? If you want to put a degree on your resume, you should make the commitment and sacrifices necessary to graduate from a well recognized school. If you can’t do that, you should not bother at all with the diploma mills. You’re ultimately only fooling yourself.