Are Engineers’ Minds Wired Differently?

Back during the dot-com boom of the late 90’s a lot of people jumped into the IT field because they saw plenty of jobs offering good pay. And for a while they did fine, at least until the bottom fell out. Then many of those people washed out of the industry, leaving mostly the ‘core’ engineers with stronger technical skills and programming abilities. And in fact another version of that shakeout is also occurring today as I write this article.

So why did people who entered the field from outside ultimately not fare as well? Or more generally, why do some people succeed in software engineering, while others flounder? It can’t be a simple matter of comparative intelligence since smart people exist in all fields, and there are many smart people who just don’t ‘get’ programming. Even people you might think of as ‘nerds’ don’t always perform well in the programming realm. So what separates two people, both of them smart, but where one of them can program well and the other can’t?

It’s been said that engineers’ minds are wired differently than other (normal?) people, and this most likely applies even more to software engineers. Some will point to Meyers-Brigg and other personality tests to evaluate a person’s suitability for analytical tasks. However, just what does it mean to say that a task (or a person) is analytical?

I like to think there are two types of people in this world -- and I don’t mean those who like to categorize people and those who don’t. One group is interested in outcomes, and the other in the mechanics. Computer nerds might compare this to declarative vs. functional languages, if that makes any sense to you. An analogy is when a person admires a new car. Do they appreciate its aesthetics and comfort, or do they digest the specifications and performance numbers? Of course the two are not mutually exclusive, but people sometimes lean towards one or the other. Also think music fans vs. audiophiles.

Beyond the personality differences, there are also very real skills required to be successful in software engineering. Some of these skills can be taught, but others are innate. For instance, there is the ability to see patterns and complex relationships in large systems. Some people can easily juggle highly abstract, non-visual concepts in their head. They can read or hear about a concept and instantly see how it can be applied in a myriad of problems, and also understand where the approach might not be appropriate.

These people can look at a screenful of text (source code) and envision a program’s flow of control and spot logical errors. They can think of the possible potential and combinatorial ramifications of various decisions without resorting to a “let’s see what happens” approach. Like a good chess player they can foresee how various scenarios and branches will play out, evaluating them to a depth and level of detail that would overwhelm most people.

If you remember as far back as the 80’s you might recall the first time you saw a Rubik’s cube. Solving it (at least at first) posed an immense challenge, requiring the ability first to experiment, then figure out how the contraption worked. Thereafter you’d have to evaluate patterns and visualize how you would interact with the cube to get the configuration you wanted. Most people were so daunted by these things that they dropped the cube after a bit of experimental play, but others stuck at it and discovered its secrets. In a way, good developers have the vision, cognitive skills, and perseverance to stick with problems like these and solve them.

I hope this discussion makes some sense to you. I’ve spent a lot of time wondering why some people have better aptitude for software engineering than others, but I still can’t say that I’ve fully cracked the code.

What Makes an IN-effective Engineer?

When I ponder this question I think back to the various engineers I have worked with whom I would consider failures in their field. Unfortunately there is no single archetype of an ineffective engineer. Tolstoy once said that all happy families are alike, but every unhappy family is unhappy in its own way. Likewise, you could say that each failed engineer is a failure in his or her own unique way.

I had one employee who could not accomplish anything unless they had all the minute details of their project answered by management. How big should this button be? What should the exact text be for this label? Should I put this code into two files or just one? Perhaps they were trying to please, but they gave the impression of being unable to accomplish anything without excessive handholding.

Another engineer was an avid musician who did his day job just for the paycheck. He would do the absolute minimum work necessary to get by, and his teammates often found themselves having to fix his bugs and generally clean up after his mess. When confronted with the inadequacies of his work, he was a veritable fountain of excuses and blame. He refused to take responsibility for anything, and showed no accountability for his work.

There were also a couple of engineers who were just argumentative by nature. When there were the slightest little details that someone let slip by, these people would pounce on them. And where there were no controversies or disagreements they would manufacture them, just so they would have something to argue about. They did this in the name of generating healthy discussion, but in reality they just liked to argue and waste everyone’s time.

Then there was the fellow who had exhibited decent technical skills and quality, but who just rubbed everyone the wrong way. He was openly critical and dismissive of other peoples’ work and ideas. He was especially hard on non-technical people, all in the name of ‘honesty’. His influence was like poison on the team, and no one wanted to work with him – not other developers, product managers, project managers, QA, or anyone else.

Of course I’ve also had those employees who where well meaning and positive but yet just weren’t quite there technically. A few bricks shy of a load, as the saying goes. Not playing with a full deck. The lights are on, but nobody’s home. The elevator doesn’t go all the way to the top floor. A couple of fries short of a happy meal. But at least I could manage around these employees by assigning them simpler tasks and giving them more time to develop (hopefully).

You may wonder which of these people were eventually let go. Ultimately that’s not important; what is important is that you take away from these stories some qualities to avoid, both in yourselves and any people you might be involved in hiring.

Seven Habits of Highly Effective Engineers

I want to expand on my previous article and describe effective engineers in another fashion, one that borrows from Stephen Covey, author of “Seven Habits of Highly Effective People”. I read the book a long time ago and while I couldn‘t tell you what all the seven habits were, it still seems like a good way to organize a list of positive traits I’ve seen in effective engineers.

1. Be Proactive – I’m pretty sure this was one of Steven Covey’s items. Rather than waiting for others to take care of things, do what needs to be done. Volunteer to take on new tasks, to help others, and in general do the things that no one else wants to do.
2. Follow Through – If you are asked to do something, follow through and report back on your success (or lack thereof). If there’s one thing managers hate, it’s requests that disappear into a black hole. If you are asked to do something, acknowledge the request and report back on it within a reasonable period of time.
3. Manage Up – Engineers are often notorious for being overly optimistic with work estimates. But they need to be realistic and let management know when too much is being asked of them. This is often referred in management-speak as “push-back”. Otherwise the engineer runs the risk of overcommitting and disappointing everyone.
4. Always be learning – Even if your job doesn’t offer a way to learn new skills, and especially if your job doesn’t offer a way to learn new skills, you have to work to keep your technical skills current.
5. Share your knowledge with others – Some think that keeping their knowledge to themselves, whether in the technical or business domain, is a means to job security. Instead, it makes you an impediment. Those who share their knowledge with others will be regarded as subject matter experts and people will turn to them for advice, making them highly valued.
6. Share the credit, accept the blame – Give credit where credit is due. Make it known whose hard work helped to make things happen. People will return the favor to you someday. Likewise, be wiling to accept the blame – if you screw up, don’t be afraid to fess up and fix the problem. And if you can’t do this because you’re in an environment where making mistakes is severely punished, well -- perhaps you shouldn’t be working there.
7. Be positive – this may sound trite, but it’s not. Negativity is infectious, and it spreads through the team like a poison. Fortunately, positive energy is also infectious. By this I don’t mean a Pollyanah-ish type of naivete, but rather a “can-do” attitude. Negative people are often quick with excuses why something is not possible, but positive people will find ways to make those things happen.

What Makes an Effective Engineer?

Strong technical skills alone do not make for a great engineer. Believe it or not, coding is not necessarily the most important thing that an engineer does. It takes great communication skills, people skills, drive, and initiative to make a truly successful engineer.

This is not to say that technical skills are unimportant. Of course you need to understand the technology, and you need a solid foundation in the principles of computer science. But this is merely a prerequisite for success, not the full requirement. Technical skills alone are insufficient for true success.

Great engineers don’t just point out problems and expect others to fix them, or worse, just ignore the problems and hope they go away. Rather, they dive in and investigate the problems themselves, even if it’s in someone else’s code. They’re not hung up on finger pointing or on getting credit; they are just interested in getting things done. You can call it initiative, or call it being conscientious – I prefer the fancy term “a bias for action.”

Also, in any decent sized organization engineers will not be working alone in a vacuum. They need to work as part of a team developing features and products, and the entire team needs to be on the same page. To some extent such coordination is the responsibility of the dev or project manager, but each team member’s ability to work well with their teammates contributes to the overall effort. This is what people talk of as ‘teamwork’.

When I talk about teamwork I’m also referring to sharing information. Does the person speak up and volunteer information when they should, or do they stay quiet and withhold key knowledge? Or do they instead talk too much and soak up everyone else’s time? Are they able to split up a task and coordinate work with another engineer? These are important considerations in judging a person’s teamwork skills.

In addition, engineers will often have to work with other people outside of the team. This may involve other technical teams as well as product managers, senior management, sales, etc. These may be less technical or non-technical people, and the way the engineers interact with them can spell success or failure for the project (not to mention the engineers’ careers).

The best engineers are able to communicate with non-technical people in a productive manner, explaining technical issues in a clear and simple manner that everyone can understand. They are able to distill a problem down to the essential points instead of getting bogged down in technical details. i.e., they can explain clearly what the issues mean to the decision makers so they can take meaningful action instead of ending up confused.

Hence to be truly successful an engineer needs to work as part of a team, not just within their immediate group but also within the entire organization. They need to communicate well and spread understanding beyond just the engineering organization. This kind of interaction and communication skill set is not taught in school, nor is it necessarily innate. It’s something that can be developed over time, but unfortunately one that some people either do not understand or refuse to pick up.

Does Your Company Need Rock Stars?

A lot of companies, if not most of them, think they need to hire rock stars. It’s perfectly legitimate to want to hire the best, but where do you make the cutoff? Many companies insist on hiring only the top 10%, or the top 5%, or even the top 1%. If all companies thought like this then it’s a wonder that most people get hired at all.

“The Mythical Man Month” is a seminal work in Software Project Management, written over 30 years ago. It contains many ideas, some of which are controversial, and some that are dated, but one that I like is that of a “Surgical Team.”

A surgical team is led by an experienced surgeon who is assisted by more junior surgeons, anesthesiologists, nurses, and other supporting personnel. Transposed to software development, this model means that an architect or other senior engineer works on the most critical portions (i.e., architecture & design) while others support the architect by working on supporting tasks (i.e., coding & testing).

This model is attractive because it requires only a few rock stars compared to supporting characters. If you only need 1 out of every 10 engineers to be rock stars, that makes hiring a lot easier. Of course, the proportion of rock stars in the developer population is probably a lot less than 10%, but perhaps for some teams you could substitute a medium level star instead. So instead of a top rock act, you might have a good cover band instead.

Finally, consider the possibility that you may not need rock stars at all. CRUD development is a favorite whipping boy of mine, perhaps unfairly. But the fact remains that there are a lot of projects out there that do not require rock star level talent. And if rock stars were to work on them, they might quickly become bored and disillusioned.

Boredom in this case may result not just because such projects don’t use leading edge technology. It may also be because those projects actually rely more on other skills, such as project management, internal marketing & selling skills, political negotiation, and people management. Those are not necessarily the skills that rock star engineers possess, yet they may be essential to the success in the organization.

Are You a Rock Star?

I sometimes like to say that many people think of themselves as rock stars when they are just roadies. And no, I don’t consider myself a rock star either.

“Rock Stars” are a phenomenon that is not unique to software development; politicians like Barak Obama are often called rock stars, as are some top professors, and even (gasp) rock musicians! If you are at the top of your profession, any profession, “Rock Star” seems to be the requisite title. But that’s not a title you can award yourself, alas. It has to be bestowed upon you by your peers.

Detecting a potential rock star in a job interview is very difficult. Just because someone can answer all the technical questions in an interview does not mean they are a star; it just means they are knowledgeable. And as to whether they can learn their job quickly and perform all the duties of that position to a standard that significantly exceeds expectations, that’s something that only time can reveal.

That doesn’t change the fact that a lot of people consider themselves to be rock stars. And certainly just about everyone considers themselves to be above average, just like the kids in Lake Wobegon. But of course that's statistically impossible, just as no more than say 10% can be stars, and no more than 2% can be superstars. And yes, I just pulled those numbers out of a hat – but I think I’m accurate to within an order of magnitude.

So how can you tell if you are truly a rock star? Here are some signs:

• Are people constantly coming to you for help or advice? (on technical matters, not just to shoot the breeze)
• Is your calendar filled with appointments, half of which you cannot attend? (technical and design discussions, not pointless BS meetings).
• Is your boss always giving you more work than you can handle? (and not just busywork)
• When a crisis occurs, are you the first one they ask to troubleshoot? The go-to person? (and not as the fall guy)

Any of these qualities could be meaningless on their own, but combined they might point to you being the next Mick Jagger -- or Keith Richards. But hopefully not Ron Woods.

If these things don’t happen to you, you can kid yourself all you like but you’re not a rock star. Alas, you might even be a great performer worthy of the title but stuck toiling away in obscurity – rock stars unfortunately don’t thrive in caves. You should learn to sell your achievements to others, or at least get a good promoter.

What Qualifies Someone as ‘Experienced’?

The term ‘experienced’ is a nebulous one. I call to mind former Democratic presidential candidate Hillary Clinton (no hate mail please), who claimed that she had “35 years of experience in government.” Which was strange, since I seem to recall that as of 2008 she had only served eight years in either elected or appointed office.

Likewise, just saying you have 5 years of .NET experience doesn’t make you an experienced .NET engineer. You might have spent all of those 5 years on CRUD apps moving controls around on WinForms. Not that there’s anything wrong with that, but that kind of work does not make for a well rounded .NET engineer.

To me, someone experienced with a technology has had enough depth and variety in assignments to have explored most of the features available in that technology. For instance, if you say you are experienced with.NET, does it mean .NET version 1.0? 1.1? 2.0? 3.0? 3.5? Have you used, or at least understand, collections? generics? multithreading? delegates and asynchronous I/O? garbage collection? If not, you can’t truly call yourself experienced in .NET.

Some may quibble that I’m using a trivia contest to the question of whether someone is experienced in a technology. However, there’s experience and then there’s experience. To me you’re only qualified as experienced if you can confidently discuss the technology in depth and apply it readily to problems. To do this you have to know the ins and outs of the technology, what it’s capable of, and what its limitations and weaknesses are.

Also just as important, if not more so, than the number of years with a technology is what you have done with it. Did you maintain an existing system and fix bugs? Play around with scripts? Or did you actually participate in specing out, building, releasing, and supporting an actual system? There is a huge difference between designing and coding up something from scratch versus just patching holes in it. You will most likely not be considered ‘experienced’ unless you have gone through at least one full development cycle, and preferably several.

What Makes for a Senior Engineer? An Architect?

At larger, more established companies an architect is typically a highly experienced engineer who has distinguished himself/herself during at least 15-20 years of work experience. At other companies, typically smaller, younger ones, the architects may be engineers in their 20s who developed the original systems, however good or bad those systems might be.

So obviously you cannot compare a 45 year old architect with a PhD who has worked at six companies to a 23-year old architect who wrote the first version of their company’s website using Perl and SQLite. The first architect is likely to have a wide breadth of experience in a variety of technologies and design approaches; the second architect will likely have superb in-depth knowledge of how his company’s site operates and the tweaks needed to keep it healthy. Both skillsets are important, but they are not equally transferable.

The same issues apply to the title “Senior Engineer”. An engineer may achieve that title through many years of experience, or because they just happen to be among the most senior members of a very young team. In both cases they are likely relied upon to provide leadership for the more junior engineers, which may be more important than the actual number of years they’ve been working. Still, giving a “Senior Engineer” title to an engineer with 2 years experience is somewhat of a silly game.

The bottom line? Do not place too much weight on titles. An architect or senior engineer at one company may have less experience than a junior engineer at another firm. Just remember that titles are relative, and a fancy-pants architect at one company may flounder at another company. It’s kind of like how someone who skis black diamond runs in the Midwest might get themselves in way over their head trying to do the same in Colorado.

Job Titles

I talked earlier about the term ‘IT’ being used in different contexts. This can be a problem because people often have different notions of what IT is. It can be a general term to describe the technical field, which is how I use it, or it can also refer to internal corporate IT departments. I tend to refer to such departments as ‘IS’ or ‘MIS’ rather than IT.

Similar confusion abounds when it comes to job titles. What exactly is the difference between a computer programmer vs. a software engineer vs. a developer? Or an analyst vs. a systems analyst vs. a programmer analyst?

To a large degree this is a game of semantics. In theory all people who write software should be considered software engineers, in the sense that engineers are people who apply scientific and technical knowledge to real world problems. However, in practice there are real distinctions between the various titles that can lead to differences in pay, prestige, and more than a bit of elitism.

A (business) analyst (or systems analyst) is commonly one who translates business needs into software requirements. This type of position exists mostly at internal IS organizations; software companies in comparison tend to have product managers who fill such roles. At any rate, analysts and product managers both tend to stay out of the purely technical realm, except perhaps for those designated as “programmer analysts”.

As for programmers vs. engineers, that distinction came about in large part due to the different educational programs that many universities provided. Students often had a choice between undertaking a computer science degree offered in a school of engineering versus a CS degree from a math or liberal arts college. If you undertook an engineering track, you were exposed to more hard sciences (think chemistry / physics / calculus); in comparison, the math/liberal arts curriculum was seen as a less hard core approach (think more ‘softer’ classes like English Lit.).

To some degree this is an unfair distinction between two very similar programs, but the distinction has still stuck in many people’s minds. So much so in fact that some people saw a ‘programmer’ title as being inferior to an engineer title. As a result, even people who did not have a true engineering degree started calling themselves “software engineers” just for the added prestige. Some saw that as a cheapening of the title, but others felt entitled to the designation due to the nature of their responsibilities.

As for the term ‘developer’, it gained popularity with the advent of the web when people who put together static HTML pages started being called web developers. Some of these people eventually moved on to write some Cold Fusion or PHP code, but the title of web developer stuck with them. Unfortunately this has led to the term becoming somewhat ghettoized in certain circles, such that a “web developer” is thought to be someone who doesn’t write any ‘real’ code, at least not in the classic O-O sense.

My point of view? Call yourself what you like – developer, engineer, programmer. I don’t care, as long as you produce results. But if pressed, I’ll use the term ‘developer’ to avoid the programmer / engineer title controversy.

Thankless Tech Jobs

I’ve mentioned working in a CRUD position at a cost center as a job you should avoid. But there are plenty of other jobs that are likely much worse than the one you’re in now. So the next time you feel tempted to tell your boss where to shove it, you may want to pause and thank your lucky stars you don’t have one of the tech jobs below.

IT Helpdesk – answering phones all day helping corporate lusers open Outlook or change their password is not my idea of a career.

Customer Support – Neck and neck with Helpdesk in terms of mindless work dealing with clueless people. Often a stepping stone to QA Analyst.

QA Analyst – Repetitively testing the same software day in and day out and pointing out problems is probably not what you had in mind when you spent four years to get your computer science degree.

System / Network Administrator – The only time you hear about them is when something is broken, and then it’s always seen as their fault.

Project Manager – Often a role where you have the responsibility to get things done but not the authority to get people to do the work. You need influencing skills, otherwise known as cajoling, begging, pleading, pestering, conniving, threatening, yelling, and bribing.

Game Developer – Working 80+ hour weeks is expected in this field, and the pay’s not even that great. If you like games, then play them; don’t throw away your youth making the game companies rich.

Junior Recruiter – Despite the negative feelings I may sometimes have for hungry junior recruiters, I fully understand it’s really a high-pressure sales position. Usually it’s sink or swim in the first 90 days. Their choices are to cold-call prospects who hang up on them or else get yelled at by the managing partner who sees them as dead weight.

CRUD Jobs

If you’re not familiar with the term, ‘CRUD’ is an acronym for Create / Retrieve / Update / Delete, which are the basic database operations performed by a typical internal IT system. From that history the term has evolved into somewhat of a pejorative for boring, monotonous development jobs, typically involving applications with forms tied to databases with nothing much else interesting going on.

Of course, there are plenty of people happily doing CRUD work, so the stereotype is not always accurate. Still, the conventional wisdom is that CRUD work is not where you want to be if you are interested in leading edge technologies.

BTW, this contrast of CRUD vs. non-CRUD systems is analogous to my earlier cost center / profit center discussion, and it just so happens that most CRUD development is done in cost centers.

Unfortunately, the cold truth is that the vast majority of software work out there is done on CRUD systems. You see it everywhere – payroll, CRM, ERP, loan processing, etc. These types of applications far outnumber the more glamorous Google / Facebook type positions (although websites like Facebook could also be considered CRUD applications!).

Note also that some people use the term ‘IT’ or “Information Technology” to refer to CRUD jobs in general. However, I like to use the term IT as a broader description of the software engineering industry. So when some people put down IT as a dead-end function, make sure you understand what they’re referring to. Chances are they’re referring specifically to CRUD jobs in internal MIS departments (i.e., cost centers).

As a candidate you may have a choice between a seemingly stable CRUD job vs. a faster paced position at a software company or website. In these cases I’d generally recommend you choose the software company, all other things being equal. You’ll most likely learn more, have a more rewarding career path, and work with more challenging and leading edge technologies.

Working for a Cost Center vs. a Profit Center

Being an organizational profit center means the work you do generates revenues for the company. Conversely, being a cost center means you are costing the company money; i.e., you amount to overhead. So obviously it’s better to be thought of as a money maker than a money loser. Companies tend to invest heavily in profit centers, whereas they’re always trying to cut costs in a cost center, especially in an economic downturn.

So what kind of developer jobs will land you in a profit center? Typically, product development in a web or software company is associated with a profit center. To put it another way, if your company’s customers pay money to use what you are creating, or if your work generates revenues in some other way (e.g., advertising), then you are part of a profit center.

On the other hand, if you write systems that are used internally, whether by Accounting, Sales, or anyone else, you are most likely working in a cost center. It would behoove you to transfer to another department or to a new job that is associated with a profit center. Even if your internal customers are singing your praises, it may only take some downturn in business before the company decides to engage in belt tightening and the grim reaper visits your department with pink slips.

OOP and Programming Language Snobbery

I grill all candidates on Object-Oriented Programming skills even if they are purely front end developers. After all, ASP.NET does provide a separation between markup and logic (and also presentation, via CSS). Hence the logic portion in the C# codebehind needs to be written with proper object oriented design principles in mind.

Unfortunately some people who got their start in classic ASP have bad habits as they were accustomed to writing snippets of C# or VB.NET code directly within the ASP page markup. <% This is bad! %> They may have never needed to use O-O principles or design patterns, and hence never felt the need to develop such skills.

If candidates do not have direct experience with C#, I look for experience in C++ or Java -- languages with OO characteristics. That’s not to say that Smalltalk, Lisp, Pascal, etc. are not OO languages, but they are more academically oriented and less directly relevant to the kind of development we do. Even VB.NET, which is pretty darned close to C# nowadays, is often looked down upon, fairly or not.

Does it really matter whether a person has programmed in the O-O paradigm, or more specifically in a C++ style language? Or that they can properly describe a C# class, an interface, or a delegate? Perhaps some will see such questions as a trivia contest. However, it really does matter that developers know this stuff, so that they don’t make wrong decisions such as passing parameters by value instead of reference, making unnecessary copies of objects, calling components out of proc vs. in-proc, etc. These things do matter, and wrong design decisions have consequences.

Some people may also wonder whether this is a case of language snobbery. What’s wrong with a candidate having a background in something like VBScript, Python, or Perl, if those languages can get the job done? Why, nothing, of course. But the more (non-O-O) spaghetti code that’s created, the less maintainable the code base becomes. Plus, such an approach definitely does not scale. And maintainability and scalability are the key requirements of successful software engineering.

Generalist or Specialist?

Continuing on the topic of learning new technologies, should you learn as many skills as possible or should you specialize in a few? Which will make you more marketable?

In my world view there is no such thing as an IT handyman. Actually, come to think of it that’s not a bad analogy. If you are constructing a skyscraper would you want a team consisting of an architect, a general contractor, and skilled tradesmen – or would you hire a bunch of handymen? The obvious answer is that you’d want specialists who are experienced in their fields. There’s no way that a single person can be an expert architect, draftsman, mason, carpenter, plumber, electrician, etc., all in one, regardless of what they might like to believe.

The situation is not too different in the technology world. In fact, IT presents an even wider array of skills for people to learn and master. While it’s true that good engineers can pick up new technologies fairly quickly, it still takes years to become an expert at most of those skills. So when I see a resume from a candidate that claims expertise with ASP.NET, J2EE, LAMP, Ruby on Rails, C#, C++, VB.NET, PHP, Perl, Python, TCL, Flash, SQL Server, Oracle, etc. -- naturally I’m more than a bit skeptical.

My recommendation is to pick a single track and become as good as you can with that skillset. You can (and probably should) supplement those skills with other technologies, but when the rubber hits the road you need to show real competence in a particular area. The tracks might include:

Front End Web Development:

• ASP.NET / C#, or
• PHP, Python, or Perl, or
• Java / JSP / Struts / Spring MVC, or
• Ruby On Rails

Middleware / Data Services:

• C# / WCF / ADO.NET / SQL Server, or
• Java / Spring / Hibernate / Oracle, or
• MySQL + various ORMs

Infrastructure

• IIS / Windows Server, or
• Apache / Linux / Solaris

This is obviously not a complete list, and there are many possible technology combinations, but it does highlight a number of possible specialization tracks. Many of the tracks are complementary, but it’s unlikely most people could be experts in more than one or two of them.

You might be wondering, does this advice conflict with what I said earlier about learning lots of different technologies? Not at all; my philosophy remains the same -- you need breadth as well as depth. Show that you are familiar with a range of technologies, but pick an area of expertise and learn that set of technologies inside and out.

Following ‘Hot’ Technologies

To maximize your marketability, should you learn .NET or LAMP? Or Java? C# or VB.NET? PHP, Perl, or Python? Flash/Actionscript or Silverlight? Ruby on Rails? Or something else? What technologies will be hot a year or two from now? Or in five years?

There is no easy answer to this question. The marketplace is littered with corpses of technologies that were once considered ‘hot’ but which are now shunned. I’m thinking for example of (in no particular order) CGI, EJB (v1), MFC, TCL, etc. Going back further, you might remember such fallen stars as Delphi, PowerBuilder, and Sybase. Heck, if you go back far enough, I still remember when Turbo Pascal was considered hot stuff.

Even now there are technologies which were recently hot but which are on the wane. I’m thinking of things like Cold Fusion and classic ASP. There is still some demand for these skills, but I foresee that declining in the future as companies transition to other technologies.

Looking ahead though it’s impossible to see what technologies will ‘prevail’. Most likely there will be several technologies that thrive within their respective segments; there’s no reason that a single technology has to dominate everything.

Right now, I’d say that .NET, Java EE 5, and LAMP are all good choices for a career in web development, with the ‘P’ in LAMP being PHP, Python, or Perl. Internal IT departments seem to favor .NET and Java, while most startups lean towards PHP. Ruby on Rails is also becoming increasingly popular, though a lot of people remain skeptical about Ruby for large scale applications. Of course in five years the picture may be very different.

My advice? It’s similar to what I posted last time. Pick an area of specialty, whether it’ s.NET, Java, LAMP, or RoR, but read up and stay current on the other technologies. In this fast-moving technology world (and a fast-changing economy), you want to hedge your bets wherever possible.

Keeping Your Skills Up-To-Date

How do you keep current on the latest skills when you are not exposed to it in your day to day work? I suggest you get good books on new technologies and read them at work or home when you can. If you don’t have much free time you could read a chapter during lunch or other breaks.

It’s important that you keep up on new skills even if your job has you working on the same things every day. In fact, learning new things is especially important if you work with the same technologies every day, as your job won’t provide you with much learning opportunity.

To illustrate, let me recount my own story (Warning! Old fogey nostalgia alert!). Over the years I’ve had to learn a new set of skills and technologies every few years. The progression went something like this:

1. BASIC: This was ‘classic’ BASIC, not the ‘Visual’ kind, and certainly not VB.Net. This was how I learned to program back in my high school days, tinkering on an Atari 800. There was also a bit of 6502 Assembler thrown in for fun.
2. Pascal: I learned this in my first college programming class, using Sun UNIX workstations. Some old timers still remember when Turbo Pascal was the hottest language around for PC development.
3. C: I learned this in on the job, in fact in my first job out of school, reading Kernighan & Ritchie. We were still using Sun UNIX boxes at work.
4. Windows (3.x) development: Around 1990 I taught myself this using the original Petzold book, the bible of Windows programming. Back then we still had to worry about programs fitting into 64K in the small/tiny/medium memory models.
5. C++: In the early to mid 90’s I taught myself this language using books like Stroustrup’s ARM (not the best learning material, BTW).
6. Win32 API, MFC, Sockets, SQL, VB: I learned these standard tools for desktop & client-server development during the mid 90’s.
7. COM/OLE, STL, ATL – Thick books taught me these highlights(?) of traditional OO design and programming in the late ‘90s.
8. C# / .NET, ASP.NET, HTML, CSS, JavaScript – Re-tooling my skills for the web and .NET after 2001.
9. XML/XHTML, AJAX, WCF – The latest and greatest .NET stuff circa 2007. Also learning Java EE5 on the side.
   

I would consider each of these to be distinct generations (or epochs) of technologies. That means that I’ve gone through nine or so different generations of skills, and I’m most likely not done yet. In a few years I might have to learn a whole new set of technologies; perhaps it will be LAMP or Ruby on Rails, or it could be a new set of technologies that have yet to be invented.

The point here is that you need to constantly update your skills every few years as they will inevitably become outdated over time. Hence as a software engineer you can never really afford to stop learning, unless you want to exclude yourself from the jobs that demand the most current skills.

Considering a Position with a Startup

Earlier I discussed valuing stock options for a startup. Your mileage will vary, of course, but how exactly will it vary? Joining a startup may provide you with tremendous opportunities, but it could also leave you out on the street within a year. Hence you need to go in with your eyes open.

An early stage startup may have less than 10 employees and you may very well be one of the first technical people brought on board. You will likely get a pretty good stock option package but only a modest salary. The company at this point is probably running off on seed or angel funding, or possibly financed by the founders themselves -- so there’s not a lot of excess cash floating around. The company needs desperately to make the first version of its product work well enough to attract additional rounds of funding. And of course it goes without saying that you’ll be spending the vast majority of your waking hours chained to your desk.

Joining a startup at this point is undoubtedly a risky proposition, but it also offers the greatest potential reward. As the company grows you will likely benefit from several promotions, and if you have a successful exit you may be able to cash in your options for a healthy profit. On the other hand, it’s just as likely, if not more, that the company will wither on the vine or crash and burn spectacularly.

There are many reasons why an early stage startup can fail. A poor product is certainly one obvious reason, but it’s only one factor of many. Poor management is another common one, along with a lack of clear product vision, or a poor understanding of the market. And of course luck and timing also plays a factor. Woe to you if you launched your Internet startup in early 2001!

Hence when you interview with an early stage startup you should ask hard questions to the top management (whom you’ll definitely meet). Ask about their previous experience managing startups, the funding situation, the investors (both angels and VCs) and their connections, the board of advisors, etc.

With a later stage startup, the organization will likely have gone through a few rounds of financing and should have a product already in the marketplace. This type of company probably has 20-100 employees and is looking to bolster its engineering capacity to ramp up product development. They should also have a marketing and sales organization in place, or the beginnings of one.

With such a company you should be able to get a fairly decent sense of how well they are doing. When you interview the senior managers they should be willing to tell you outright whether the company is profitable. If they hem and haw, or say “that depends on how you define profitability”, that should raise red flags.

Still, a company at this stage has shown that they are capable of raising funding, and they should have a decent revenue stream, even if they are not exactly profitable. Hence just by virtue of the organizational inertia your risk of being laid off six months after starting is low. However, your chances of getting rich off stock options are low as well, since at this point they will most likely start getting stingy with their stock option grants.

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.

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.

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?

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.

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.

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.

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.

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.

Should I Get an MBA?

Some technical professionals wonder if they should get an MBA to kick-start their career. But unless you are specifically looking to go into management (dev management, product management, or project management), it’s largely a waste of time and money. In fact, even if you do decide to go into a management field it may still be a waste. And this is coming from someone who holds an MBA.

Some may claim that having an MBA from a prestigious school looks great on your resume and opens doors. Sure, that’s certainly the case – if you’re looking for a job in investment banking or consumer product marketing. Otherwise it’s just another shiny star on your resume that attracts attention, but which usually won’t help you make the sale.

So then is an MBA valuable for the things you learn in the program? That depends on whether you actually end up using the material taught there, which is a combination of the following:

• Economics
• Finance
• Marketing
• HR & Organizational Behavior
• Information Systems
• Corporate Strategy
• International Business

If you come from an engineering background you may be surprised by how lightweight most of the MBA coursework is. Perhaps the most difficult classes are in Economics and Finance, and even they do not begin to approach the difficulty of a freshman Computer Science class. Back in business school I found it funny to see Liberal Arts graduates complaining about how difficult our classes were; obviously they did not stay up nights in college trying to digest 1,200-page engineering texts full of partial differential equations.

So if the value of an MBA is not in the coursework, what else is there? Well, some people talk about the added perspectives they gain from the broader business education, but that is a nebulous benefit at best. Nay, the real benefit is something they don’t necessarily tout up front; it’s the interaction skills that you gain from group assignments, and the relationships that you develop with your fellow students.

The value of such skills and networking is difficult to measure, but it is definitely tangible. Still, is it worth the significant opportunity cost of taking two years off of work and going hopelessly into debt? Only you can answer that question. But if you can manage to take an MBA program part time, or better yet, have your company pay for it, that will make the decision much easier.

Do I Need an Advanced Degree?

I’m seeing more and more candidates with Master’s degrees, and even a few with PhDs. Does it make a difference to the hiring manager?

Not a whole lot. I evaluate candidates based on their performance, not what degrees are on their resume. If their Master’s Degree of PhD helps them answer the questions better, then great, but otherwise it doesn’t make much of a difference.

One possible exception is that with H1B candidates with foreign degrees, I may look more favorably upon people who have completed a Master’s Degree in the U.S. I think the more time they have spent in the U.S. the better, as it helps them adapt to the cultural aspects of this country. And if that time was spent studying technology in a degree program, all the better. I don’t particularly care that they might have done it just to get a visa.

Some people feel that there is a kind of degree inflation in the market. At one time you were considered well educated if you had a bachelor’s degree (or even an Associate’s), but now since everyone has a bachelor’s degree, you need a Master’s to stand out.

I don’t fundamentally disagree with the notion that Bachelor’s degrees are becoming commonplace. However, if a Bachelor’s degree is sufficient for a career in software engineering (which it is), then there is really no need to try and distinguish yourself with an advanced degree. It can be expensive, it takes a year or two of your life, and in the end that same amount of time spent in a job may look just as good on your resume.

Do I Need a Degree from a Prestigious School?

If you are reading this blog chances are you’re far beyond the age where you have to decide what college to attend. Still, you might have kids who are facing that situation, or young people might be coming to you for sage advice (hardly likely in this day and age, but you never know).

I once worked at a company that only hired people from the top schools. Places like Harvard, Yale, MIT, Stanford, Brown. Which made me wonder how I ended up there, as my Ivy League credentials were nonexistent. But in any event, what was the result of such selective hiring? Was the company a stellar development shop?

Not really. In fact, it was a dysfunctional organization that produced rather mediocre code. That was the result of their policy of hiring the smartest people from the best colleges regardless of their degree, resulting in physics, math, and psychology majors doing software development. Sometimes that worked okay and sometimes not so well. Pair that with a lack of formal processes, and you had a mess on your hands.

Anyway, as for the pedigree of your educational institution – the fact is, the longer you are out of school the less your alma mater matters. You can still highlight it on your resume if you’re proud of attending that top notch school, but at some point your experience and work accomplishments begin to matter much more.

Still, this doesn’t mean that getting a degree from Podunk State is just as good as a degree from Cal Tech. Your choice of school will matter earlier on when you are just starting out your career. Since you don’t have much of a track record by that point, companies will ask you where you went to school, what your major was, and inquire about your GPA. Any advantage you can wield at this point can be important in getting a first great job and laying a good foundation for your career.

Do I Need a Degree in Computer Science?

Some people ask whether they should get a degree in Computer Science, or perhaps a comparable degree like Computer Engineering or Information Technology. Or would a Math degree be sufficient? How about one in Physics? Or Civil Engineering? Or for that matter, English Literature?

I have seen plenty of successful engineers with degrees in non-computer related fields. That shows that CS-type degrees are not strictly necessary to do well in this field. Software Engineering is not a tightly regulated field like accounting, law, medicine, or even architecture. Software Engineers do not need a license, nor do they need to pass any exams to work in the field. There are certifications they can get, but the value of many certifications is questionable. Hence it’s fair to ask whether people with degrees other than CS can be just as qualified as CS graduates. There is no simple answer.

On one level, some companies, especially large ones with formal training programs, like to take in the smartest people regardless of their college majors and train them on their approach to software development. For the type of relatively standardized work these companies do, this may be a perfectly valid approach.

At other companies however, formal training is a luxury and new employees are expected to come up to speed quickly. And in these environments the lack of a formal computer science education can be a distinct disadvantage.

Why is this the case? After all, aren’t there lots of teenage kids hacking away and even starting their own Internet companies, all without a CS degree? So why can’t a smart, college educated Political Science major do just as well in software development?

Well, my answer is that people who have focused their studies in non-CS fields are not likely to have the grounding in basic computer science concepts that are necessary to be successful right away in a software engineering environment. Sure, they can pick up these skills and knowledge on the job, but typically that happens in dribs and drabs, and they never get the solid grounding they should have had in the first place. I’m talking about skills and knowledge like the following:

• Data structures: linked lists, queues and stacks, B-trees, graphs, etc.
• Algorithms: Sorting, Searching, Recursion, Design Patterns, Big-O notation
• Object oriented design (Encapsulation/Abstraction, Reusability/Inheritance , Polymorphism)
• Databases (Table design, Normalization, Indexing, SQL Queries)
• Discrete Mathematics (Switching theory, Binary logic, Numeric algorithms)

These are not necessarily esoteric, ivory tower concepts; many of them are things that may be used in the context of a developer’s daily tasks. You’d be surprised how many people I interview who have 10+ years of programming experience but do not understand these basic concepts. And not surprisingly, many of them do not have a formal CS education.

Do I Need a College Degree?

Many large companies will list a B.S. or similar 4-year degree in Computer Science or a related field as a job prerequisite. No CS degree and you don’t get to play, for better or worse.

At smaller companies the requirements are often not nearly as strict. I’ve seen startups with senior employees (even executives) who never even completed college – and I’m not just talking about Microsoft, either. And in fact not too long ago I hired a fellow who did not have a college degree (but was working on it part time).

As to whether college is worth it for the personal edification – well, I can’t really answer that. It’s true that in many ways you can learn more on the job than in school; however, pursuing the right kind of college education will teach you the fundamentals of computer science that are all too easy to gloss over if you are self taught.

So if you are weighing whether you should head off to college after high school, or return to school after some time off, or just stay in school and finish up that degree, I would heartily recommend it. It opens up more doors for you, and if you don’t do it now you might regret it later in life. And as you get older it becomes exponentially less likely that you’ll actually go back and finish up a degree.

So my bottom line? If you have a chance to get or complete a bachelor’s degree, do so if at all possible. It may open many doors for you that might otherwise be closed, and you’ll also make yourself proud.

Advice for Those Just Starting out of College

If you are a new or recent graduate, you might ask yourself whether you should work for a large, established company or take a chance on a smaller company or startup.

If you have a large, well known and respected company like Microsoft / Google / Oracle / Sun on your resume, you are more likely to stand out than if you worked for “JoeSchmo Savings & Loan” or “Mom & Pop’s Web Shop”. Also, the fact that you were employed by such respected companies means that you’ve already passed through some tough screening processes. And finally, you may also learn more at the larger companies, especially since they are more likely to have formal training programs and knowledgeable employees.

Also, larger companies typically pay better to start with than smaller companies, as they have more financial resources.

On the other hand, people who work at smaller shops are more likely to acquire a wider range of experience. For example, at Microsoft you might work on one small component for Internet Explorer; however, at a small web shop you might be responsible for writing the HTML and CSS, the ASP.NET codebehind, JavaScript on the client side, and ADO.NET in the business layer, as well as setting up and maintaining a SQL Server box and an IIS box. You would never get that breadth of experience at a large company, as that work would likely be divided up amongst at least four or five people.

Plus, at a smaller company it’s possible that you’ll advance faster – if the company grows, that is. Larger companies often have more prerequisites for advancement, such as time spent in a position, advanced degrees, etc. Larger companies may also have restrictions on things like pay raises. Smaller companies are less likely to be burdened by such policies.

So the choice is yours: a better looking resume, or more hands-on experience. Not an easy decision by any means.

Back to Blogging (and rambling)

Well, I'm back after being on break for a couple of weeks. Anyway, starting next week I'll resume blogging about recruiting, interviewing, and management issues.

In the meantime, I realized something the other day. Among my circle of friends I do not know of a single smoker. Not a one. Of course some of those people might have smoked back in the day, but none of them do now. And I don’t think I’m a statistical oddity in this, either, at least here in California.

And yet, at my last company I saw a lot of our engineers hanging out in front of our building and puffing on cigarettes. Many of them were people I never expected would be smokers – not that there is really a smoker profile, of course. Still, in my experience most engineers I have met do not smoke, as far as I'm aware. So it was a bit surprising to me that so many of my colleagues liked to take a drag every few hours. And not only that, they were some of the brightest people at the company!

You might ask, what does this have to do with recruiting? Well, very little, actually. Except that once I ran across a company that required candidates to sign a statement that they were not smokers. I think it had to do with getting a discounted group rate on health insurance. Now INAL, and I don’t know if this is legal. It’s entirely possible someone might claim that a smoking habit is a disability and is federally protected. Still, the company seemed to be not so subtly discouraging smokers from applying.

Anyway, I began to wonder why people smoke nowadays, especially engineers. It should be abundantly clear to everyone by now that smoking can cause serious medical harm; even the tobacco companies have admitted it. And I expect that engineers are pretty smart people as a whole. So I asked myself why they would make a conscious, rational decision to continue smoking in the face of all the evidence that smoking is bad for them.

Then I finally realized (after someone bluntly pointed it out to me) that there might be an upside to the smoking habit. Our smokers regularly gathered outside the building and spent time not just smoking, but also shooting the breeze about what was going on in their respective parts of the organization. And in a large(r) company, current information about what was going on organizationally was like gold. And perhaps this information, and the relationships built with their fellow outcasts, was in some small part a contributor to their success within the organization.

Now of course I'm not suggesting that anyone should take up smoking just to build connections and improve their knowledge acquisition process. But this example points out how social networks (the in-person kind) can form under perverse conditions and create bonds that might not have existed otherwise. And it also shows that trying to screen out smokers in the recruiting process may be a bit counterproductive.

Interview Suit Advice

Earlier I blogged about my recommendation to wear a suit to interviews. However, not everyone may be familiar with the intricacies of wearing suits, especially since most of us technical folks rarely have occasion to dress up in our daily lives. So if you do decide to get all decked out, how can you best dazzle the interviewer with your keen fashion sense? Well, to keep you from having to pick up a copy of GQ, here is my “Interview Suit” advice. Of course, if such metrosexual topics don’t interest you, or if you just don’t’ believe in wearing suits to interviews, feel free to skip this blog post.

As I noted earlier most of us wear suits only to interviews, weddings, and funerals. This means you really only need one suit. Or possibly two, if you do lots of interviews or go to lots of weddings (but hopefully not lots of funerals).

Your suit(s) should be dark. Black, dark blue/navy, and charcoal gray are good options. These colors are the most traditional and most reliable. Avoid bold pinstripes and loud patterns.

The jacket should have a conservative cut with two or three buttons. Three is typically considered more traditional and two more stylish. The fashion industry seems to go back and forth over time on the two vs. three button question, but you really can’t miss with either.

I prefer no vents in the jacket but some people prefer a single center back vent. No problem either way. Just don’t go for two side vents; that just screams, “Bond, James Bond”.

The suit material should be wool. No polyester or other man made fabrics. The difference is obvious in the drape, the way the garment hangs. And besides, wool garments last much longer than synthetics.

No matter where you buy your suit you should have it altered to fit. Not just the sleeve length and pant hems, but the jacket itself as well. A lot of young people tend to be lean (yes, even engineers), but jackets are generally cut fuller to accommodate a variety of body types. You should have the jacket taken in so it doesn’t look like a tent hanging from your shoulders.

Here is a page with some good advice on how to select a suit for your body type:
http://www.ev-said.com/2007/08/men-suit-your-shape.html

Now here’s the important part. If at all possible, don’t buy your suit off the rack! Considering that your suit (or suits) is an important investment, you should consider getting a custom tailored suit. Not bespoke, necessarily, but custom tailored (aka “made to order”).

What’s the difference between the two? Well, a bespoke suit involves a tailor who takes your measurements, cuts custom paper patterns, and brings you back for one or two fittings where the suit is tweaked to perfection. Such a process results in a wonderful suit, but it also costs about $4,000 and up, which few people can afford.

The alternative is to go to a tailor who will take your measurements and send them off to lower cost cutters and tailors in Hong Kong, who then assemble the suit to your dimensions. The intermediate fittings are skipped, and you get back a ready made suit in a couple of months. The fit won’t be as perfect as with a bespoke suit, but it will still be far better than anything off the rack, even those that have been altered for you.

These (semi) custom made suits will cost in the neighborhood of $1000, which is within reach for a lot more people. And $1000 is really not that bad for a suit, especially if you are only going to have just one or two made. These suits will last you for years, possibly decades, so you can consider them an investment rather than an expense. And remember, for comparison there are some off the rack designer suits that can cost $2000-3000 or more.

One last piece of advice – if you do decide to shell out $1000 or more for a suit, be sure to keep it stored in a tightly sealed garment bag. Otherwise the moths might decide to feast on the fine wool (which they love), and you’ll be left crying over the newly found holes in your most expensive garment.

Blogs I Read

Here are some blogs I read for my own edification, inspiration, or just plain amusement. This is not an endorsement of the points of view on these blogs; I just find myself reading them regularly.

Joel On Software: http://www.joelonsoftware.com

Hiring Technical People: http://www.jrothman.com/blog/htp

Recruiting Blogosphere: http://www.ere.net/blogs/recruiting_blogosphere

Manager Tools http://www.manager-tools.com

Mini-Microsoft: http://minimsft.blogspot.com

High Scalability: http://highscalability.com

TechCrunch: http://www.techcrunch.com

The Old New Thing: http://blogs.msdn.com/oldnewthing

The Dilbert Blog: http://dilbertblog.typepad.com

Why I Blog

I see plenty of blogs by recruiters and HR, but I have not seen many blogs that represent the hiring manager’s point of view -- or the candidate’s for that matter. I have been both a hiring manager and a job candidate many times, so my goal is to share my war stories and lessons learned for the benefit of others.

Having said that, I don’t want to completely give away all the secrets of the hiring manager’s trade. I won’t say what I think a fair wage is for an X, Y, or Z position, as that information is highly subjective and dependent on many factors. I also try to avoid naming specific companies I’ve worked for or recruiters that I’ve worked with. Although, depending on how you got to this blog you may have figured out much of that information anyway.

Still, if you’d like to read about specific topics I haven’t covered, or want me to go into more depth on a topic I have discussed in passing, please let me know.

Just What Does HR Do, Anyway?

Someone who has been waiting anxiously for an answer after an interview might be justified in wondering what exactly it is that HR people do all day. After all, how long can it take them to make a decision and process the paperwork? For that matter, is it even in HR’s hands at this point? Probably not.

In most cases HR is only a conduit, a partner with the hiring manager. They may do some light screening of resumes, schedule the interviews, and yes, handle paperwork. And if you do not hear back from the company, it’s most likely because of corporate policy and not the fault of an individual HR person.

I’ve said earlier that if you don’t hear back from a company it’s not because they’ve forgotten about you. Some individuals claim that such things do indeed happen, and that it has happened to them. I won’t dispute that; I can imagine that key people might go on vacation or leave the company, and paperwork might get lost. But I would say that if a company is careless enough to let an applicant fall through the cracks, chances are the candidate is not at the top of the “must hire” list anyway.

Some people have a dismissive attitude towards HR. They consider HR to be clueless gatekeepers who stand in the way of your getting to the hiring manager. And this attitude is seen in both candidates and outside recruiters. This is unfortunate and an unrealistic view of most companies.

At most tech companies HR generally does not consist of technical people. Some of them may have a technical degree, but most are far removed from technology. Still, they are not drones; they are key resources critical for implementing and managing the company’s strategy, work environment, and internal policies. They are often called “HR Business Partners” for good reason; they help technical managers navigate the often treacherous waters of hiring and managing employees.

Not Hearing Back After An Interview

Sadly this practice is becoming more and more commonplace. It used to be in the old days that you would actually get written rejection letter from companies; back when I was in school we’d almost proudly show off the “Ding Letters” as badges of honor. Alas, most companies no longer send even an e-mail rejection letter.

There are two primary reasons companies do not get back to candidates. One is simply that it’s uncomfortable to tell someone they didn’t make the grade (although this was apparently not a problem in the past); another is potential liability. Personally I’ve never heard of a company being sued specifically for sending a candidate a rejection letter, but in our litigious society it’s easy to imagine it happening. People feel aggrieved and victimized for all sorts of reasons, and based on the wording of the rejection letter some candidates may see themselves as victims of discrimination.

My rule of thumb is that if a week goes by after your last interview and you haven’t heard anything back from the company, you should write them off. It might make sense to stretch this to two weeks if you know they are interviewing lots of candidates.

Waiting much longer than a couple of weeks to hear back is fruitless and likely to give you an ulcer. If that much time has gone by and you haven’t heard a peep, they’ve most likely decided to pass on you. If they had been interested in keeping you in the running they probably would have e-mailed you with some apology about the process taking so long.

Some people wonder whether it’s okay to contact the company if they do not hear back after an interview. Generally it’s fine to do this, but I’d predict that 99% of the time you’re not going to like the answer you get.

Signing Documents Before Starting Work

Most companies will require you to sign various agreements before you start work. Before you blindly scribble your John Hancock on anything put in front of you, you should take a moment to see what you’re signing and what rights you’re giving up. And don’t forget, INAL – so this advice is worth precisely what you are paying for it.

Non-compete clauses are a silly business, especially since they’re generally not enforceable -- at least in California. Generally they are only meant to scare employees away from running into the arms of a competitor. Still, if non-competes concern you, you should ask at the time of the offer whether you’ll have to sign any such forms to work there.

Intellectual Property Protection is where you promise you will not take IP from the company when you leave. The IP can include source code, designs, specifications, and any other documents that may reveal the company’s secrets. This should be reasonable enough; the general understanding between companies is that departing employees can walk out the door with only what’s in their heads.

The Company will also likely want ownership of all your work while you are employed. Beware this can also include your side projects if they are relevant to your company’s field. So for instance if you work for a pest control firm and you design a better mousetrap on your own time, hoping to strike it out on your own and make it big – well, that design may actually belong to the company.

Many companies also forbid working on other for-profit ventures while you are employed with them. This may include consulting gigs on the side, running a micro-ISV (Independent Software Vendor), or serving on boards of directors. However, most will accommodate you and grandfather in any side ventures you already had before joining the company.

Finally, while this is not specifically a document to sign, some companies will ask you to submit to a drug test. This is a sensitive topic, and one that some people have strong feelings about. Personally I’ve worked at a couple of such companies and done drug tests for both of them, so my view should be clear: I wouldn’t let a drug test keep me from taking a job with an otherwise great company. Others may disagree, and I respect their views. But this being a free country, companies are free to test for illegal substances, just as candidates are free to walk away from nosy companies.

The Exit Interview

Some companies conduct exit interviews and some don’t. Some do it purely as an exercise. Some do it religiously but only to cover the logistical details, such as ensuring that all company property has been turned in, that they have the person’s mailing address, etc. In all of these cases the companies are missing out on some useful information.

In my experience it’s not at all uncommon for departing employees to hold a grudge against their former employer. Perhaps it’s even the norm at some companies. It would behoove those employers to find out what’s eating away at these employees, as excess turnover is expensive and disruptive.

Some companies have the departing employees do the exit interview with their managers, which defeats the entire purpose of the exercise. The employees really need to have such discussions with HR or some other third party to ensure that they can be forthright and candid about their experiences.

As a departing employee, what should you say or not say in an exit interview? Well, there’s really not a whole lot of damage you can do at this point since you’re already leaving the company. Of course there is a slight possibility that you might return to work there again someday, but that’s not likely for most people. Still, you should remember what I’ve said about burning bridges. What you say to HR seemingly in confidence may very well get back to your manager, so avoid the temptation to incinerate that bridge, no matter how strong the urge.

If you really must get some things off your chest, I’d recommend that you genericise your complaints and not associate them with people, especially your old boss. Refer to them as organizational issues that should be addressed, not personal faults to be thrown back in the face of your superiors. You want your parting comments to sound like constructive feedback for the company, not the mad ventings of a disgruntled troublemaker.

The Good-Bye e-mail

When you do leave your job it’s customary to send out a good-bye e-mail. I’d recommend that you trim the distribution list to just the people you know personally. And be sure to BCC: everyone instead of listing out their names so as to avoid any whiff of politics or favoritism. Keep the letter professional, thank everyone for all their help, and provide a permanent e-mail address where people can contact you.

Keep in mind that just because you’re providing your contact information it doesn’t mean you’re offering to answer people’s incessant questions or provide free consulting. It may be courteous of you to answer some basic queries, but don’t feel bad about turning down any requests for extended help.

One thing the good-bye e-mail should not contain is a list of grievances. If you have to things to get off your chest, leave that for an exit interview.

I once had a colleague who wrote us a classic goodbye e-mail, although it’s not one you should necessarily emulate. It went something like this:

“When I left my last job, my teammates gave me as a parting gift a bowling pin with the label ‘AMF’ on it. They told me the letter ‘A’ stood for ‘Adios’, but wouldn’t tell me what the ‘MF’ stood for.”

“I wish I had a bowling pin for each of you.”

Giving Notice & Burning Bridges

I recommend people not give notice at their current employer until they have a written offer in hand from the new company. This may seem a bit silly, since 1) In most cases a verbal offer should be sufficient, and 2) Even with a written offer the new company can terminate your employment at any time, at least in an Employment At-Will state. Heck, they can even withdraw the offer before you start; it’s been known to happen in cases where companies suddenly engage in belt tightening. Still, having a written offer in hand can give you the confidence to psychologically break with your current employer.

Once you give notice it’s natural to mentally check out of your job. However, it’s important to stay focused on your responsibilities during the transition process. Your boss will likely want you to do a brain dump to fellow employees, or perhaps document everything you know.

It may be tempting at this point to thumb your nose at your employer, particularly if you feel like you have been mistreated in the past. However, it’s important to not burn bridges. And this applies not just to your boss but also to the colleagues you work with. Even if you only have light contact with a coworker they may still remember you when you cross paths again in the future. And you want them to recall you in a positive light.

Not burning bridges also applies outside of the resignation scenario. In this industry it’s not uncommon for someone who reports to you to one day to later become your boss, or vice versa. At one job I had a fellow team member who was a sort of my mentor, then became my subordinate, and later became my boss. It’s important to keep on good terms with as many of your co-workers as possible. Or at the very least, don’t piss them off.

Having Second Thoughts

I’ve discussed in the past what a bad idea it is to renege on an offer or accept a counter-offer from your current employer. However, people do sometimes still have second thoughts. And as flaky as people can be (especially here in California), I’ve seen candidates slip away even after accepting an offer. Hence the hiring manager cannot rest easy with a new hire until they actually start on day one.

Speaking from the hiring manager’s perspective here is a list of things candidates can do, ranging from merely annoying to the most truly obnoxious:

1. Trying to start a bidding war (before accepting an offer)
2. Trying to renegotiate the salary after accepting
3. Reneging on the offer for a better offer
4. Reneging on the offer for other reasons (e.g., didn’t want to relocate after all)
5. Accepting a counteroffer from their current employer
6. No-show on the start date – yes, I’ve had this happen!

Some of these actions, especially the ones lower down on the list, are likely to ruin any chance you might have of being hired at the company again in the future.

The Counter-Offer

If you are at all valuable to your company they will most likely try to keep you onboard by making a counter-offer. However, career advisors are nearly unanimous in that you should never accept a counter-offer. It won’t change the things you were unhappy about at your old company, unless the source of that unhappiness was your salary.

And even if money was the issue, and even if it’s addressed by the counter-offer, your boss will immediately start looking for a replacement for you. Make no mistake about it, you have been tagged as disgruntled, disloyal, and unreliable, and you are living on borrowed time. Your employer just wants to keep you on to reduce any disruptions until they can find someone else to fill your shoes.

The fact is, you will most likely be out of that job within six months one way or another. That’s how it is with most people who accept counter-offers. Even if you think the company won’t hold a grudge, chances are you’re less likely to get promotions and big raises in the future, which will only cause you to start looking again.

Accepting the Offer

Most companies these days will give you a day or two at most to accept an offer, or perhaps the weekend. They generally will not give you much more than that out of fear you may shop the offer around.

So what do you do if you a better offer comes in after you’ve accepted? That decision is up to you. There are no hard and fast rules about reneging on an offer. Obviously it doesn’t look good, and it reflects poorly upon your character. Most likely you can kiss any possible future employment at that company goodbye. You will also embarrass and alienate your recruiter as well, if you worked through one. Only you can determine whether such ostracism is a cost worth bearing.

Contrary to what some people in tin foil hats believe though, there is no industry blacklist that companies share about people who have reneged on offers. Some recruiters might keep track of such things internally, but most companies have better things to do than to maintain such lists. So I wouldn’t worry about word spreading too wide about your ill behavior. Still, the more often you pull such this type of stunt the more people are likely to hear about it. Consider it a cumulative stain on your reputation.

In any event, when push comes to shove I would not recommend reneging on an offer unless there is something clearly superior about another offer. If the two are similar except for a few thousand $$ in pay I’d say it’s not worth it, especially since things will generally even out in the long run. But if you are genuinely excited about the second offer and really dreading reporting to work at the first company, then you may just have to go with your gut.

So here’s another scenario; what if you are in the process of interviewing at another company when an offer comes in? Assume that the offer is okay, but you’re really more interested in the other company that has not yet made a decision. You can try asking the offering company to give you a week or two to decide, but most likely they’ll balk at that idea.

In this case (and I’m ABSOLUTELY NOT ENDORSNIG THIS IDEA) you might accept the offer and ask for a delayed start date. This will give you time to complete the interviewing process with the other company, and if you ABSOLUTELY have to, you can accept the other offer if it comes in and renege on the first offer. However, this would be VERY BAD behavior, and one I would not expect the readers of this blog to engage in – right?

The Background Check

If you are fortunate enough to earn an offer many companies will make you a verbal offer first, contingent on a background check.

Along with reference checks, companies are increasingly relying on background checks. Usually this is contracted out to a third party; they will check things like your employment history, education, criminal background, and less commonly, your credit history and salary history.

In my company’s case our candidates are told up front they will be put through a background check. They also have to sign a consent form that outlines just what will be checked, and I believe that includes salary history. That may or may be sufficient to extract salary information from previous companies - I don't know since INAL (I’m Not A Lawyer). However, people can't say that they haven't been warned. They are free to decline the verbal offer before the background check begins.

Some might claim this is a violation of privacy, but I don't think it's any worse than Intellectual Property Agreements, Non-Compete clauses, or even affidavits that you are a non-smoker (for insurance reasons). These are all things that many companies require you to sign before you can work there.

And besides, if you really want to talk about a violation of privacy consider that some companies expect you to take a drug test before you start. Fortunately for the 420-friendly readers out there drug tests are becoming less and less common amongst employers.

In any event, the increasing use of background checks means that you can no longer blatantly lie on your resume or exaggerate your salary. This may seem Big Brother-ish, but it should really be seen as a good thing -- at least for those who are trying to stay honest.

References

More and more companies are doing reference checks these days, and it’s a cause of nervousness for some. Still, you should not be too worried about this.

For one thing, companies will generally not contact your references until they are ready to extend an offer. So your references won’t be bothered until the very last stage.

One exception is if recruiters ask for references up front. They have no business doing this, and often they do it to go fishing for new candidates and leads. In those cases you can simply tell them that you can provide references when you get to the offer stage.

Another thing to keep in mind is that reference checking is in most cases a mere formality. Companies do it just to cover their behinds (aka “Due Diligence”), and will usually ask very little of substance to the reference they’re contacting. They might ask how they know the candidate, the candidate’s dates of employment, etc. But if they try to ask about the candidate’s performance, most companies will stonewall the questioner out for fear of liability. In fact, many companies have a policy of referring reference requests directly to HR, who will in turn only confirm things like dates of employment.

So if you are asked for references, who can you turn to? Obviously you wouldn’t want to ask your current boss (although I’ve actually heard of that happening, believe it or not). I’d instead recommend looking to a trusted colleague, or else seeking out a boss from a previous job, one you’re still on good terms with. Generally the hiring companies will not accept your brother, pastor, or drinking buddy as legitimate references – how annoying.