The Zen of Certification and the Microsoft Certified Master Program

The Revenant MCP

This week I became Microsoft certified this time by passing the SQL Server 2008 Database Development Exam (70-433) which bestows on me the privilege of calling myself a Microsoft Technology Specialist (MCTS).  I’m assuming this is the new and improved version of the Microsoft Certified Professional (MCP) certification that I remember from the last time I paid attention to these things.

Microsoft Certified XBOX 360 Acheivement

It has been almost a decade since I have devoted more than a passing interest in Redmond’s annoyingly mercurial certification programs. I fondly remember the feelings of validation, accomplishment, and relief upon completing the final exam of the MS Certified Solution Developer (MCSD) track one spring afternoon in 1999. I rode that high for several months before the e-mail arrived from Microsoft giving me the “good news” that I hadn’t finished a race, I had only reached the front of the treadmill.

Dear {Insert Name Here},
We think all of you who busted your hump to get your certification are swimmingly awesome! So awesome, in fact, that we are doing you a huge favor. We are going to make your certification even more marketable to employers by upgrading the program. Well, not exactly YOUR certification, but the one you would have if we hadn’t just put an expiration date on all the tests on your transcript.
Isn’t that just marvy?

The realization that certification was a journey and not a destination was a bit of a buzz-kill for me, to say the least. I started to ruminate on my motivations for becoming certified in the first place and ultimately concluded that it was primarily an effort to credential myself for career advancement.

Is it worth it to continually renew these certifications every time MS incremented the annum on their software?

What is an expired certification worth anyway?


As the tests that comprised my MCSD were gradually retired, and I assume my certification status along with it, I began to wonder about how to document my situation on my résumé.  Sure, it was expired, but it doesn’t it mean anything that I ran this gauntlet, even if I did it in last year’s chariot?

Sure you summited Everest, but what have you done lately?

It seemed only fair to continue to mention the cert on my résumé because, after all, I had earned it. I considered adding a qualifier (expired), but that felt like a stain that screamed “I don’t keep up with technology!”

But that wasn’t true. I was keeping up.  I just couldn’t justify the cost and effort to continually re-take the exams. So I didn’t, until now.

So why now?

The whole reason I am even thinking about MS Certifications again is that my employer realized that they were perilously close losing their MS Partner status and the associated software discounts.

They desperately needed to affiliate themselves with some certified SQL experts to meet the requirements of the program, so I volunteered to give up a few evenings making sure I knew in how to properly  punch myself in the junk using the new features in SQL 2008.

The extra effort to brush up apparently paid off because I scored a respectable 925 (of 1000) on the exam despite the fairly extensive and complex content of the exam that often ventured beyond the features of the platform relevant to developers.

Advice for those taking the 70-433 exam

Microsoft SQL Server 2008 Database Development Training KitThe primary resource I used to prepare for this exam was the MCTS Self-Paced Training Kit (Exam 70-433) from Microsoft Press.

I found the book did a pretty poor job at explaining some of the material and went in to way more detail on some topics than was necessary to prepare for the test. I consulted to various blogs and MSDN articles when I found the explanations from the book too convoluted  or terse to follow (i.e. frequently).

For example, the section introducing Common Table Expression uses an unnecessarily complex query involving multiple joins that made the example too noisy and harder to mentally parse out the syntax of CTEs.

The true value of the book was the framework it provided for studying for the exam than the narrative in the lessons., but the included practice exam, which was way harder than the real one, and the included 15% discount code for the exam registration fee were nice extras.

Some general tips to prepare for this exam:

  • Focus on the new stuff: New features/changes in 2005/2008 are disproportionately represented on the exam.
  • Hands on Practice is critical: Implement at least one example of each concept against a database you are familiar with, not just AdventureWorks.
  • Take the practice exam early: Even if you do horribly, it gives you a list links to MSDN articles for the topics you need the most work on. I wish I had seen it earlier.
  • The practice exam is MUCH harder than the real one: I never broke 65% on the practice exam, but still got 92.5% on the real one.

OCD (Obsessive Completionist Disorder) Takes Root

A few days after passing the exam, I get another of those congratulatory e-mails from Microsoft with a link to the special MCP site where I can see all the perks associated with certification.

That’s all fine until I notice the “Certification Planner” link that informs me that I am one measly test away from the “Microsoft Certified IT Professional” level.MCTS is for schmucks who can’t commit.

This “you are on step 3 of 4” type marketing scheme, is a particular weakness of mine. It is the sole reason I am completely addicted to Mafia Wars, despite the fact that it is a completely pointless game with no action or any real strategy to it.

Mafia Wars

27% ??? That Just won't do!

This is exactly why I’ll probably take that other test regardless of the fact that it really provides very little, if any, additional wow factor to my resume.

Somewhere in the Monk area of my brain, I just know it is a terrible thing for me to be 50% of the way to a MCITP certification for SQL, despite the fact that was perfectly happy at 0%.

What’s the harm anyway? My employer will probably pick up the tab for the exam fees and preparation materials and I always learn something new while preparing for these. Right?

Then I stumbled upon this…

The Microsoft Certified Master (MCM) Program

… crap …

The two tests for the MCITP certification along with 10 years of IT experience and 5 years of SQL experience make you eligible to apply to the mother of all  Microsoft certifications (MOAMC).

Interesting, tell me more…

I need to send a resume and get approved to even try for the certification?
That sounds super exclusive, cool!

A mandatory three week training program on-site in Redmond?
That might be a tough sell for my boss, but it would be cool to get a peek inside MS HQ.
Act now and get a $3,550 discount on the registration fee.
Wait a second, how much is that registration fee exactly?

Registration fee: $18,500.

Ready to Become A Master?

This MCM ad is a "save the queen" away from being an Evony ad.

Yeah. I don’t think my boss is gonna go for that, even with the helpful ROI calculation they link to in the FAQ. The boss does ROI calculations too and knows the smell of his own BS, and will probably recognize the scent of someone else’s.

So I am gonna be on my own dime and use all my days off if I want to pursue this? Or perhaps I could spend the same money and get an MBA at a mid-level school, which has a much better chance of increasing my earning potential and won’t expire when SQL 2010 is in vogue. It seems kind of like getting a phD in VCR repair.

The comparison to a college degree doesn’t stop there. Tell me this doesn’t sound eerily similar to a Master’s thesis:

The time it takes varies, depending on the candidate. However, the estimated time for fully qualified architects to prepare their documentation and prepare for the Review Board interview process is typically 80 to 120 hours, over a period of three to six months

Who is getting this MCM Certification?

It does appear that this is a pretty exclusive club based Microsoft’s fluff-laden marketing-speak description of the corpus of MCX recipients.

Worldwide, more than 300 Microsoft Certified Masters (MCMs) and Microsoft Certified Architects (MCAs) specialize in specific technologies, and more than 125 specialize in infrastructure and solutions. Those who hold these industry-leading certifications live and work in many countries and regions, including the United States, Europe, Latin America, and Asia Pacific. All have varied backgrounds, interests, and extensive experience.

In fact, on the very same page it appears to list every holder of this certification, which gives some interesting insight into the target candidates for the program.

Just from an eyeball estimate, it appears that MS employees comprise around 80% of the people who have this level of certification. I’m assuming they get a substantial discount beyond the $3,550 special.

For now, I’m gonna have to put this on the “Fat Chance” wish-list, and settle for the MCAD program or something more economical.

What do you think?

Is this certification the least bit enticing to you?
Have you even heard of the MCM or MCA programs, and if not is it worth the money if you have to explain it to a potential employer?

19 Tips for Recruiting Great Developers

1. The big job boards like Monster and Dice have become practically useless for hiring top tier talent.

It is easy to quickly obtain a pile of resumes using these services. However, this approach will have you shucking a heck of a lot of oysters to find a truly great Perl programmer. Several professional recruiters I know have given up on these boards except for staffing entry level positions like help-desk and phone support jobs. The odds of finding the proverbial rock star programmer on Monster are growing increasingly slim.

2. Niche job boards will get you qualified leads, but not very many of them.

High-end job boards like TheLadders charge a fee to the candidates and are as much a den of recruiters as the mainstream sites.  I find it hard to believe that top-tier talent is likely to pay to be listed on a job board.

Caveat: I have not personally used TheLadders as part of my recruiting efforts, but did briefly have a subscription as a candidate.

The really niche job boards like the one at JoelOnSoftware do a good job at pre-qualifying the candidates through self-selection, but maybe too much so.  I’ve listed a few jobs on this site for opportunities in Austin that generated almost no response. I suspect this is a better tool if you are in a bigger market like NYC or the silicon valley.

Actually Joel’s board does have a compelling strategy to draw higher quality candidates:

  • Trim back recruiter nonsense by forcing the advertiser to disclose in the ad who the candidate would actually be working for.
  • Asking advertisers to post their Joel’s Test score. Candidates who care about this are more likely to be passionate about their craft.

Despite my limited success with it, I’d still recommend the site given that there really is no financial risk.  I can personally attest to Joel’s “If it doesn’t work, you don’t pay” guarantee. We got our money back promptly with no hassle when the listing didn’t net any interview-worthy candidates.

3. Use LinkedIn Strategically

I have it on good authority that LinkedIn is a pretty strong source of candidates who are only passively looking and currently employed, which are generally traits of the better candidates. However, programmers don’t seem to frequent the job board on this site  as much as sales and management types.

That said, I  can’t really vouch for its job board when looking for developers based on my experience. However,  never before have you had such unprecedented access to the innards of another company’s org chart as LinkedIn provides. A few quick searches containing the name of  other companies in your industry will usually reveal developers with relevant experience in your industry.  This site is also used as a stealth way of looking for another job for people who don’t want their employer to catch them on a job board.

I was just NETWORKING, I promise!

4. The best candidates aren’t going to come to you.

There are exceptions to this, but I’m betting that you wouldn’t have read this far if you are recruiting within a company that the best programmers already yearn to work for. This advice is for the rest of us who don’t have the luxury of offering a job that would be a showstopper on a resume or turn heads at RenFest / Comic-Con.

Some managers, especially new ones, whose only experience with recruiting has been as a candidate desperately seeking an audience with a choice company, have the impression that their role as a hiring manager is akin to sitting atop a throne as candidates compete for their favor.  Not exactly.

There is a pool of candidates who are going to come to you, and their names will quickly become familiar because they will apply to every job posting you open even over several years. In most cases, there is a reason that someone else hasn’t snapped up these people and absent evidence to the contrary you probably don’t want to hire them either. If you aren’t willing to be proactive in your search and sometimes take on a more subservient posture when dealing with candidates, you are eventually going to force yourself to choose from this pool.

The top guns may only hit the open job market once in their careers, and from that point forward get subsequent jobs through networking, which brings me to my next point.

5. Networking is as essential for you as it is for the candidate.

Networking as a job-hunting strategy is a no-brainer, right? So what are you doing to make sure you are on the other end of that network for the right candidate?

Your existing team of developers is often a great entry point into a pretty substantial network of developers. Referral bonuses are the tried and true way to enlist employee help with the recruiting process, but often the prospect of working with a favored peer is a more powerful motivator.

Other benefits of this approach include:

  • The person who made the referral will to be invested in the success of the employee and likely will take an active role in bringing the new person up to speed.
  • Barriers to acceptance into the team will be reduced because the new person already has a relationship with at least one person.
  • You are more likely to get a true picture of what you are getting with the candidate without as much puffery as you might get interviewing strangers.

Warning: This doesn’t work so well with the mediocre programmers. The best developers try to hang with people smarter than themselves. Mediocre ones will seek out people to make them feel smarter. Don’t hire the wing-men.

6. Focus your search on finding developers, not job hunters.

Employers are going to hang on to their best people and keep them away from recruiters, recruiting events, and by extension you.

I’m not trying to imply that their bosses are actively prohibiting them from these types of contacts, but rather that they work hard to keep them happy and busy enough to not even try.

Developer conferences and user groups are a great way to contact engaged developers who may not be actively looking for work. They even triage themselves into sessions so you can more readily identify them by their area of expertise.

The best emissary to send to such an event is a development manager or supervisor. HR types are going to scare away the fish by being too sales-y and saying things like “Do you know Sea Pound?” and many programmers tend to be too introverted to make a lot of contacts.

I’ve a friend who recounted a tactic that had worked well at these events for him. He wore a t-shirt to the conference that read: “I’m hiring developers.”

7. Programming competitions

If you need a lot of developers and want them to triage themselves by skill AND aptitude, you might try sponsoring a programming competition. I’ve no personal experience with this approach, but I’ve seen a number of companies try it.

It definitely sounds good, but be careful to understand what you are looking for. These competitions seem to appeal to people who love puzzles, and those are types of programmers can often exhibit a pathology where they like tinkering and optimizing at the expense of getting a good-enough solution out the door.

8. Don’t expect to pay median salaries for top talent.

Often I see companies that claim to hire only the best, but their HR people argue that they should only have to pay the median salary as determined by salary surveys. Try that argument at a jeweler or sports car dealership and let me know how that works out.

How can you charge $200K for that diamond necklace when I can prove that the average piece of jewelry retails for $150?

If you want the top 10% of developers, you should expect to pay at least in the top 25 percentile, and you are only going to get off that cheap if you bring something else to the table like a cool product to work on,   good benefits, private offices, or some other perk.

9. Get the muggles out of the process as early as possible.

If at all possible, don’t force the candidates to endure even a phone interview with a non-technical person. If you can’t avoid it, at least strip out any technical questions from the interview script that the person performing the interview doesn’t understand well enough to talk about competently.

Let HR/Recruiters manage the scheduling, resume screening, benefits discussions, etc. , but don’t give them a phone interview script with technical questions and let them lose on the candidate.

10. Be flexible with your requirements.

If you need a .NET developer, don’t be a stickler for C# or VB.NET. The best programmers can become quickly proficient in just about any language, make sure that the person screening resumes understands what keywords are acceptable substitutes for the ones in the job description.

11. Branding is not just for cattle and marketing.

Branding is the act of creating and maintaining a positive image to grease the skids for selling people on your team or company. It is often confused with advertising, but it is a distinctly different animal. Branding is about managing your reputation and advertising is just one means to that end.

Creating an identity for your team that is attractive to potential recruits not only helps with sourcing candidates, but also adds ballast to your side of salary negotiations.

Brand characteristics that resonate with developers:

  • We have and hire the best developers – Top developers want to work with other top developers.
  • We work on cool products that your friends and family will be familiar with.
  • Our company is a meritocracy that values technical know-how above politics.
  • Our team keeps up with the latest technology and invests in training for developers.

Some techniques for advertising and reinforcing your brand:

  • Sponsoring developer conferences and events
  • Developer Oriented User Groups – Often you can get a plug on the cheap by buying the pizza or contributing a few give-away items like t-shirts or books.
  • Support Open Source Projects under the name of the company.
  • Offer unusual perks that appeal to programmers and then submit a press release about it to local media outlets.

12. Understand your needs and recruit for that.

This seems too obvious to mention, but is probably the easiest mistake to make. Clearly define what you expect the new hire to do every day and hire someone that can do that job every day and enjoy it.

Some guidance in this area:

  • Don’t hire based on interviewing skills unless you need a sales guy.
  • Don’t hire based on management skills unless there is potential for them to lead or manage in the near term.
  • Don’t hire a clone of yourself or your best employee, you already have that. Hire someone that complements what you already have.
  • Hire for what you need NOW, not what you think you will need later.

13. Ignore your instincts during the interview

Your tendency during an interview is to form an opinion quickly at the start. Your mind is wired to preserve its own worldview and will often fight against all evidence to protect that initial judgment.

To remain objective and overcome jumping to conclusions, consciously decide to go harder on the people you like and easier on the ones you don’t. Otherwise you will be inclined to do the opposite and just reinforce a your initial impressions and waste a chance to learn more about the person in front of you.

14. Trust your instincts when making the final hiring decision

Trust your gut whenever you are the slightest bit uneasy.  At my own peril I have several times learned the hard way that losing a good candidate is far preferable to hiring a bad one. For the dozens of people I have hired in my career, there have been a number of people I was sure would be great and turned out to be just so-so, but  I have never hired someone that I was unsure about that turned out to be a great employee.

At each step of the process separate your candidates into two piles:

Yes: From what I know so far, I could hire this person without reservation.

No: Everyone that doesn’t pass the criteria for the yes pile. Includes anyone who is a “Maybe” or a “Yes, but…”

15. Just say no to puzzle problems.

First, see item 7  about the problem with logic puzzles.

Second, these things tend to annoy really good programmers who don’t like make-work or meta problems.

Don’t kid yourself that “you just want to see how they think.” Knowing that someone can come up with a clever way to estimate the number of boat trips required to determine which switch turns off Mt. Fuji is fun conversation, but a waste of everyone’s time.

Alternative approaches to evaluating a candidate:

  • Rough-out an application architecture on the white-board for this scenario.
  • Role-play with them a troubleshooting scenario for a challenging problem you have worked through.
  • Get code samples.
  • Ask them to describe an application they have built and ask probing questions to make sure you understand their level of contribution to that project.

16. Write an interview script and test it on your current team

Write interview scripts (for each job title/level) and keep your notes for each candidate.

Good reasons to use standardized interview script

  • Less room for ad-hoc questions helps you avoid favoritism (see #13).
  • Documentation of  equal treatment of candidates to defend against potential hiring discrimination claims.
  • Easier apples-to-apples comparison of candidates..

Tips for refining your interview script

  • Test it on current employees – Did it draw out the important positive and negative aspects of that employee? Tweak it until it does.
  • Get current employee feedback on the script – Any offensive/insulting questions? Do they think it would help or hurt the perception of the company for the interviewee?
  • Review your interview notes one year after the hire. Were there any surprises? Tweak the script to prevent similar surprises next time.
  • Review your script for and remove questions that require  specialized knowledge that only a current employee would have.

17. Don’t leave people hanging.

If your company’s recruiting process is interminably slow and out of your control, take it upon yourself to call your short-list candidates and frequently re-assure them that things are progressing. The best developers are going to be highly recruited. Don’t assume that just because someone submits a resume that they are somehow locked-in and will be forced to give you first right of refusal.

I’ve heard and been part of stories of companies calling back EIGHT MONTHS after a resume was submitted to ask for an interview. This is crazy. Even if by some miracle that person was still on the market after that long, clearly they have been passed over by just about everyone else in the interim. Why would you even want them after so much time has passed?

18. Recruit former employees

Face it, your top people get recruited heavily and eventually will jump ship to see if the grass is greener, even if it isn’t.

Good employees that have left your team in are a great source of new hires for several reasons:

  • You know what you are getting and so do they.
  • Previous employees can become productive much more quickly.
  • You can recoup some of your previous training investment.

Even if you can’t convince them to come back, the fact that you want them back is an ego boost for them and will often create some goodwill and improve your branding by creating an advocate that works with a lot of other developers who you might be interested in recruiting.

Some preemptive steps to increase your  odds of re-hiring a good employee later:

  • Give them a final chance to give honest feedback about the aspects of the job they didn’t like and communicate your desire to fix those things for the rest of the team.
  • Organize a happy hour and give them a great send-off.
  • Give them a souvenir of their employment to take with them that will remind them of their friends at the job.
  • Keep in touch, and not just when you need something.
  • Call to ask how their new job is going and solicit advice on things they like about the new job that you could try.
  • Continue to make sure they are invited to happy hours to keep the ties with their former co-workers strong.

I have re-hired several employees during my career as a software development manager who have turned out to be some of the best programmers on the team.

19. Mind your karma and don’t make enemies

Don’t be an ass when developers leave the company, whatever the circumstances. It doesn’t matter if you never want to see this person darken your doorstep again. Also, treat every candidate who took the time to apply with respect, even if they were completely unqualified. Word of mouth is a powerful thing and this industry isn’t as big as you might think. Chances are that these people will talk to someone about your company that you one day will want as an employee or customer.

The Programmer’s Guide to Getting Hired: Cover Letters

The good news for job seekers, at least if you trust this poll, is that the requirement of a cover letter appears to be waning somewhat. This most likely has a lot to do with the shift towards sourcing by querying resume databases in lieu of the traditional correspondence directly with a hiring manager approach.

Here is some advice from my perspective as a technical hiring manager regarding cover letters.  Understand that this advice is completely based on my own experience and perspective and may not apply in all situations. Hiring managers and HR people are unique individuals each with their own preferences and biases that may differ from my own.

Send a cover letter when…

  • The job posting specifically requests it.
  • You have names to drop: Someone referred you, or you have a connection at the company that can vouch for you.
  • You are a really good persuasive writer and showcasing your writing skills in a document other than a highly formatted resume will help your chances.
  • You want to call out something specific on your resume.

Things to avoid:

  • Never apologize for things or call out negatives.

“The 2 your gap in my career was because…” – Bad

“I don’t have this skill you were asking for, but…” – Bad

  • Don’t write a thesis. Hiring managers have enough to read. Have a point and get to it quickly.
  • Don’t bother saying you are a perfect fit for the position, everyone says that and it just wastes space. Demonstrate it by mapping the job requirements to your experience.
  • Never send a cover letter than looks like a template or form letter. It should look like you wrote it in response to the specific job you are applying for. Those templating tools for cover letters on and Dice where you can apply to a job with one click are the Devil.
  • Never address them to “To whom it may concern.” Do some digging and find out who the hiring manager is. In the age of LinkedIn it isn’t all that hard.

Things to consider:

  • If you feel you must include a cover letter, but don’t have any value to add in it, keep it very short (transmittal letter style).

“I would like to be considered for the XYZ position that I saw posted on Attached is my resume. You can contact me at…”

  • Have someone proofread your cover letter, not just your resume.
  • Getting a proofreader is doubly important if the cover letter isn’t in a language that you are extremely proficient in. Broken English resumes do untold harm to candidates.

Further Reading

This article is part of  a the  “Programmer’s Guide to Getting Hired” series.  If you enjoyed it, you might also like these:

Poll: What factor is most likely to or has driven you out of a career as a programmer?

In my previous article,  “Programmers: Before you turn 40, get a plan B”  several of my readers pointed out the staleness of the NYT article that I cited along with its citation of a joint NSF/Census Bureau study*  indicating a high dropout rate for software developers.  Further, the original study utilized some questionable sampling methods by  focusing on programmers with a CS degree, which is not a prerequisite for a programming career.

* [Citation Needed] If anyone can find a copy of this study on-line, please send me a link.

Although I don’t claim to be a journalist, it doesn’t excuse my sloppy journalism. As an act of penance, I am going to attempt to collect some fresh data to test whether this theory still holds and investigate the causes of attrition in our business by polling my readers. Please help me maintain at least a modicum of scientific rigor and only respond on the polls that are relevant to your specific situation.

I’ll post the results and discuss them in an upcoming article, but the impatient among you can see the results by clicking on the link at the bottom of the poll.



BTW: Sorry the Polls are formatted so wonky. I’ve gotto find a better poll widget provider than PollDaddy.

What Programmers Should Be Learning in College


I officially graduated last weekend ending an undergraduate effort that started at the University of Texas at Austin 20 years ago in 1989 and stalled in a hiatus that turned into a full-time career. 

With the help of my employer’s generous tuition reimbursement plan and the flexibility of the distance learning program at the UMass I finally managed to not only wrap things up and earn a BS in Information Systems, but in doing so earned the Chancellor’s Medal for Academic Achievement. Who knew I had it in me to graduate at the top of my class for my college?


The experience of going back to school so many years later has been eye opening and has provided a lot of context to my recruiting efforts for greenhorn programmers. That is, I’ve walked a mile in their shoes and seen what is currently being taught in college level Information Technology programs.


The Good News

Contrary to my expectations forged from my previous collegiate experience, the problem of professors teaching outdated technology and theory has been remedied to a considerable degree, at least in the UMASS program. Many of the classes were taught by adjunct professors that worked at least part time in the real world in addition to their academic duties.  This made the lessons much more relevant and practical. Also, I’m glad to see they have moved on from Turbo Pascal and 68000 Assembly, but then I am dating myself.


The Bad News

The curriculum is still very centered on learning specific technologies and was conspicuously weak on best practices or practical preparation for aspects of software engineering outside the scope of software construction.  Given the relatively small percentage of time that a working programmer spends on writing code versus other elements of the software construction process, this is not ideal.

 As a hiring manager, I’d greatly prefer graduates with a good grasp of basic software construction and project management skills than proficiency in a specific programming languages. Software platforms exhibit such a short half-life that I’d question the long term value of them anyway aside from the foundational ones like C++.

Concepts such as those described in the canons of programming literature like Code Complete  and The Mythical Man-Month, can provide more lasting value over the life of a programmer’s career.


Proposed Curriculum for Software Engineers

The following course of study is a recommendation based on the skills that I’d like to see when I interview entry level software developers. I am not saying that existing programs don’t include some or all of these elements, but I rarely see many of these skills when interviewing recent college graduates.  I’ve broken the topics out for clarity, but clearly some should be combined or split into multiple courses.

Freshman Year – The fundamentals

  • Overview of Operating Systems:  Working knowledge and exposure to at least 3 of the most commonly used operating systems, i.e.  Windows, Linux, OSX, etc. The ulterior motive is to derail platform bigotry before the mental cement dries.
  • Overview of Programming Languages:  Exposure to a variety of languages by writing very basic programs in each. (C#, C++, Ruby, VB.NET, Perl).
  • Scripting 101: Familiarity with the most basic programming concepts such as variables, methods, control structures, etc. without the overhead of more advanced programming concepts to provide a comfortable “wade-in” point for those new to programming.
  • Application Architecture: Become familiar with common application architectures, associated issues, and relevant technologies. (Desktop, Client-Server, N-Tier, Web, Embedded, AJAX, etc.)
  • Intro to Electrical Engineering: Hardware level programming as an analog for software development. Boolean algebra, basic circuit design, logic gates, etc.
  • Database Design Principles and Theory: Set Theory, Normalization, OLAP, ROLAP, etc.
  • Networking Basics: Topics including, networking hardware, topologies, the OSI model, basic signaling, and protocols.

 Sophomore Year – Filling the toolbox

  • Reporting Tools and BI: Crystal, Cognos, SQL Server Integration Services
  • Database Query Languages: Query language and  technique in ANSI-SQLsome coverage of PL/SQL and t-SQL.
  • Programming in <Student’s Choice>: In depth programming course in the language of the student’s choice.
  • Source Code Control Tools and Best Practices
  • Technical Writing: Best practices for creating of software documentation and help systems that are useful to real people.
  • The Build Process and Change Management

 Junior Year – Sharpening the tools

  • Programming for a Diverse world: I18N, L10N, Unicode, etc.
  • Writing Secure Code: Common application security vulnerabilities and how to avoid them (SQL Injection, XSS, Buffer Overflows, etc.)  Suggested Text – “Writing Secure Code
  • Programming Technique: OOP, Design Patterns, Refactoring, Coupling Cohesion.
  • Usability / User Experience: Suggested text – “About Face 2.0: The Essentials of Interaction Design

 Senior Year – From machinist to craftsman

  • Designing Software: Requirements Gathering, Use Cases, Prototyping.
  • Software Project Management and Estimation: Agile, Waterfall, etc.
  • Team Programming: Code review, pair programming.
  • Testing Software: Tools and technique (Unit, Automated, Load, Regression, Integration)
  • Profiling and optimizing code: Static/Dynamic code analysis, Big-O Notation.
  • Debugging/Troubleshooting:I am amazed at how impressively bad a lot of working programmers are at this. Suggested Textbook: “Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems.”
  • Problem Solving in Code: Problem solving and more in-depth exposure to the programming language of the student’s choice.

Programmers: Before you turn 40, get a plan B

Welcome to geezer town, junior.

While researching my recent article, “Age discrimination and Programming Jobs” , I discovered a 1998 Op-Ed piece from The New York Times that cited some startling statistics from the NSF and Census bureau about the longevity of a software engineering career.

[S]ix years after finishing college, 57 percent of computer science graduates are working as programmers; at 15 years the figure drops to 34 percent, and at 20 years — when most are still only in their early 40’s — it is down to 19 percent. In contrast, the figures for civil engineering are 61 percent, 52 percent and 52 percent.

RetiredProgrammerButtonI find the defensive tone of the article and the use of dubious sampling of only computer science graduates to support its conclusion undermines its credibility. In a lot of ways, the Government has been very slow to grok the software engineering trade. In this study it completely ignores the significant number of working programmers who either earned their degree in another discipline or never finished college.


 Still, smart money seems to concur that the software engineer depreciates only slightly more slowly than the machine he or she toils behind as exemplified in this 1996 comment from Craig Barrett, then President and Co-founder of Intel.

The half-life of an engineer, software or hardware, is only a few years.

Sure, the guy’s a suit, but more importantly he was (at the time) a 57 year old former engineer publicly reinforcing the discriminatory notion of expiration dates on other engineers. It’s scary as hell to think that such an influential industry insider thinks that a programming career is roughly the same as a professional basketball player’s.


My take on the issue

Considerable accusatory ink has been dedicated to the age discrimination problem in technology, but I suspect it may be an inevitable consequence of the rapid pace of change that defines this field.

Consider the following:

  • The market value of an employee is primarily determined by experience in technologies relevant to the employer.
  • Software engineering reliably undergoes a major technology shift at least every 10 years.
  • While a technology shift doesn’t completely negate the skills of veterans, it certainly levels the playing field for recent grads.

Now put yourself in the shoes of a prospective hiring manager using a newer technology like Ruby on Rails for which nobody other than David Heinemeierhas more than about 5 years of experience.  Sure, that extra 10 years of C++ experience is a positive differentiator for the veteran over the upstart with the same 3 years of Rails experience.  All things equal you’d naturally hire the guy with more total experience.

However, all things are NOT equal. Those 10 years of C++ experience made the veteran candidate progressively more expensive as they leveraged the value of that experience in jobs requiring C++. The problem is that the marginal utility of that extra experience must exceed the marginal cost of hiring the veteran to justify paying the premium.

Herein is the source of the problem. The more irrelevant experience a candidate has, the more lopsided the utility/value equation becomes, and this presumes that the manager even has the luxury of paying extra to get that experience.

Even if the veteran prices himself competitively with a younger candidate, the hiring manager has to consider the implications of bringing in someone taking a big pay cut. Will they have morale issues from day one? Are they going to change their mind after a month that they really do need that extra cash and leave? It’s a sticky situation.

The unfortunate truth is that unlike other forms of discrimination that are more arbitrary and capricious, age discrimination can often be a result of objective and sound business justifications. I’m not trying to justify it as an acceptable practice, but just trying to describe the pickle it puts the manager in trying to make a sound business decision without compromising the ethical and legal obligations of the company.

So what’s your plan B?

Assuming you aren’t fabulously wealthy, accepted to clown college, or the fatal victim of a Red-bull induced heart attack by 40 a mitigation strategy is in order. Here are some viable options.


Work for the one person who would never discriminate against you.

No. Not your mother. You! If you aren’t the entrepreneurial type, consider a consultancy. For some reason that I don’t completely get, a little gray hair and a smattering of experience in different technologies can create a beneficial bias for companies when they are renting brains instead of buying them outright. It may have something to do with the tendency for consultants to be vetted from higher up in the management chain where the silver foxes live.




Give in to the dark side and go into management.

I’d argue that a career in programming does precious little to prepare someone for management, but clearly management thinks that everyone including technologists harbors a deep longing to “graduate” into their ranks. I think it a fallacy that no one would continue to design and build software for 20 years unless they had no ambition or growth potential. However, people like me that respect such dedication to the craft are in the minority. Maybe it is best to just stop fighting it, but consider the following before taking the plunge:

  • Mid-level managers often make very little more, if not the same as high level engineers.
  • It gets progressively harder to keep up with new technology because you don’t work directly with it.
  • Meetings, politics and dealing with unrealistic requests will pretty much become your life.
  • You may try to avoid it, but management-speak will creep into your vocabulary (did you notice my “paradigm” comment earlier?)
  • Even when it isn’t your fault, it’s your fault.
  • Even when you make it succeed, your team should get the credit.
  • Being the wunderkind as a technologist is much easier to do in technology than management, you’ll have to check your ego at the door.
  • You will be forced to make decisions that affect people’s personal life (pay, bonus, firing, etc.) and this is hard to stomach sometimes.
  • It is very empowering, enjoyable to be able to set the agenda and sometimes say, “No. We ain’t doing that shit.”
  • Computers are predictable, people are complicated. You will eventually fantasize about robot employees.
  • Mentoring can be very rewarding, but also very challenging.

The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment.
-Theodore H. White.

You’ve got a cash cow, milk that sucker!

I know you love programming because you like technology, so this may go against your very nature, but no one says you’ve got to jump every time some snot-nosed kid invents a new way to run byte-code. You have invested a lot of time and energy mastering the technology you use, and your experience differentiates you. Money follows scarcity, and snow-birding on an older technology, if you can stomach it, may just be the way to protect your earning potential. The industry turns on a dime, but is slow to retire proven technology. It is highly likely that you will still be able to earn some decent coin in the technology you know and love even after a few decades.

Why “I’d just Google it” is not an acceptable interview answer

Going out on a limb

In my previous article, The Code Sample, I ruffled the feathers of a few readers who objected to my implication that  “I’d just Google it” is not an acceptable answer during the technical part of an interview. To be fair, the derisive sentiment in that post was directed specifically at interviewees who abusively name drop about Google to dodge answering any technical questions.

…candidate that thinks “I’d just Google it.” is an acceptable answer to any technical interview question…

Still, I am going to tempt fate and take it one step further by and say that it is almost never a good idea to use this “phone-a-friend” lifeline in a real interview.

Let me explain by addressing the obvious objections to the premise.

Objection: I’ll be able to Google things on the job. It’s unrealistic to test me in a hypothetical Google-free universe.

It’s true that everyone expects that you will need to look things up to do your job, and  that it completely unreasonable to expect a programmer to have an encyclopedic knowledge of every aspect of even their best tool.

Here’s the rub. You are at an interview, not working at the job. On the job, the goal is to solve problems and get things done using any tool at your disposal. At the interview, the goal is to demonstrate why they should hire you instead of one of the other candidates who also have access to Google.

A job interview is a competition, not a pass-fail test.

The REAL hypothetical universe is the one where a job is filled by an interviewer talking to single candidate then making a decision based on whether that person can do the job or not.

Objection: What about Interviewers who ask hyper-specific technical questions?

Look, we all hate these types of questions. I’d even argue that many interviewers use them more to prove how smart they are rather than to evaluate the candidate (even though they probably Googled both the question AND answer).

As an early weed-out tactic, I really hate these types of questions. Sometimes, however, an interviewer faced with 20 candidates of which 15 could competently perform the duties of the job just needs a final jeopardy tie-breaker round when the race is too close to call.

I know this may spark a debate about how unfair  these questions are, but try to be pragmatic. The only agenda you should bring to the interview is closing the deal, not changing the way the interviewer thinks or conducts their business.

If you are really determined to make a difference, discuss the interviewing tactics with them AFTER  you have secured the job and have been working there a while. They are more likely to be open to your input when you aren’t in a position to directly benefit from them accepting it.

Sometimes “I’d Google it” is an immediate fail.

There are times when this response is going to pretty much end the interview as demonstrated in this example lifted from TheDailyWTF.Com.

Q:  What is a class?
A: I do not know, but I would look it up.

Q: Okaaay,  moving on to another question. What is a SQL join?
A: I do not know, but I would look it up.

Almost every question we asked yielded the same response.

This is a funny example, but I have heard very similar responses from  real candidates who actually proposed in response to situational questions that they’d Google things like “How to optimize code” and “how to normalize a database.”  I could probably be convinced to soften my position on technical trivia, but never-ever-ever invoke Google on a situational or general approach type question.

In fact, it is arguably better to wing it than admit ignorance on a question like this. You are probably dead meat if you can’t answer the situational questions anyway,  so you might as well go down fighting.


If you ignore my advice, at least understand this

I’ll concede that invoking Google in an interview is rarely a deal-killer on technical questions when I do interviews, especially if several candidates can’t answer the same question and lead me to suspect the question might be too trivial to be fair game. It is also very uncommon for me to make a decision on a candidate based on a single technical question.

That said, don’t delude yourself into thinking that you actually answered the question when you appeal to Google.  Whether you like it or not, the the interviewer is thinking one of two things:

“I’d Just Google it.” == “I don’t Know.”

Or worse…

“I’d Just Google it.” == “I don’t Know, and I’m not willing to admit it.”

The second inference is much more damaging to your chances.  It is probably safer just to say “I don’t know,” because you are in effect saying it anyway. That is, unless you imagine the interviewer doesn’t think you are aware of Google. If that is the case you’ve got bigger problems.