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.

Resume Critique #1 (Subject: HJS)

In my previous article, Your Resume, It’s the little things that hurt, I extended an offer to provide feedback on programmer resumes for anyone brave enough to take some criticism in a public forum as a pedagogical tool.  The first victim will be known as HJS for the purpose of this analysis in an admittedly feeble attempt to provide him with a shred of anonymity despite his insistence that it was not necessary.

Disclaimer: My critique will consist of my raw, uncensored opinion and thought process as I read through the resume from the perspective of a technical hiring manager looking for a programmer. In some cases, I may make comments that indicate bias or other things that it is illegal to consider when screening candidates, at least in the US.  I want to clarify that in the execution of my duties as a manager, I make every effort to make hiring decisions based on objective facts, endeavor to treat all candidates equally, and follow affirmative action principles as part of our recruiting methodology. 

As I discussed recently in “Age Discrimination and Programming Jobs,” it is my strong belief, however that acknowledgement of our bias and that of others is critical to combat unfair recruiting practices.  As such, I am going to call out things in my analysis that the candidate could proactively do to minimize the potential for discriminatory practices by unscrupulous managers. None of the material in this article represents the policies or practices of my current or previous employers.


Candidate “HJS”



Phone: <Censored>

email: <Censored>

The multi-line address at the top of the resume in a giant font is taking up hugely valuable real estate. Put it in a single line on the footer to reduce the vertical real-estate.
Re-purpose the top of this resume to succinctly create a branding statement that shows my job is the one he is looking for “Experienced Web Developer” or something like that.

Summary of Qualifications

  • § Experienced Software Team Leader. How experienced? Quantify it with a number of years and maybe a title 
  • § Fourteen years of software engineering experience. Good start. Experience is a key differentiator, I like how you get to this quickly. 
  • § Master of Science in Information Systems. Normally I wouldn’t feature a degree so prominently, but in this case it is a powerful selling point, because it is an advanced degree and relevant to the job.
  • § Languages: C, C++, Java, Python, Javascript, Erlang, HTML, XML, SQL, Unix shell, Perl.
  • § Web applications, Communication Protocols, Linux, Client/Server, Distributed Systems, Parallelism and Concurrency, J2EE, EJB, TCP/IP, RPC, SNMP, Network Management, Element Management, Multi-threaded. Too specific, doubly so for summary section.
  • § Development Tools: Eclipse, make, ant, Apache, Subversion, XML-RPC, RPM, Installshield. These are not enough of a selling point to feature them in this section. Move to separate “Skills” section.
  • § Experience in an organization certified at SEI level 5 and ISO 9001. “Experience in an organization”… emphasises your employer, not you. re-word “organization” out of it.
  • § Software engineering techniques: Requirements, design, OOD, OOP, UML, project planning, Fagan inspections, configuration management, change control.
  • § Native English, good spoken and written Hebrew. If you are applying for a job in the US, they are going to assume English, mentioning makes me want to doubt you speak it well. Unless the job desires/requires Hebrew, dump this fact.
  • § Enthusiastic, innovative, organized, motivated, adaptable and a quick learner equipped with broad technical knowledge and excellent people skills. I skim past statements like this that are subjective and on every single resume.  This just wastes space.


Giant Steps NETWORKS                                                                                     2003-Present

Software Team Leader, NMS Division

  • § Currently leading a team of 2 engineers working on Apache module in C++. Don’t be specific about the number of engineers if it isn’t impressive.
  • § Currently developing J2EE distributed application deployed in Amazon Elastic Cloud. Sneak in some keywords/acronyms here to enhance search-ability (EC2, AWS, Cloud computing)
  • § Multiplatform NMS (embedded Linux, Windows 2003 Server). Web-based using C, C++, Python, Openlaszlo (Flash), Java, SQL. Using SNAP protocol over RS232/RS485, HTTP, PPP, Modem control. Move these to skills section and reference them more generally here.
  • § Managed and developed a 3 person project to develop a three-tier management system for Fiber-Channel SCSI switches. Technologies: Java, C, ant, XML-PRC, RPC, rpcgen, make.  Move to skills section, too detailed for this section.
  • § Developed a document processing engine in C# and Managed C++.NET (Microsoft .NET). Analyzed, designed and implemented the software. Planned and managed the project teamincluding activities of other team member.
  • § Developed and deployed a Client-Server Element Management System in Java(J2SE, Swing), XML-RPC and SNMP.
  • § Designed and Implemented CSP-SMS protocol layer, SMS application layer for a Java(J2ME, MIDP) Instant Messaging application. Reduced code size by 25% while improving performance by refactoring the design. Was your original design that bloated and slow? Might not want to claim you invented it and then stress how much room you had for improvement.
  • § Deployed (and continuing to administer) company wiki (Moinmoin). I wasn’t familiar with this Wiki software, you might want to be more specific what Moinmoin is. Also, emphasize your role in implementing a wiki. The wording makes it sound like it was someone else’s idea that you just implemented.


Motorola                                                                                                                     2000-2003

Test Lead, Vancouver PCS System Test Team (2002 – 2003)

  • § Molded the Vancouver PCS System Test team by creating test plans, mentoring and training junior team members and resolving technical and project management issues. Molded?
  • § Increased customer satisfaction by completing test cycles 20% ahead of schedule by estimating work packages, re-planning activities and optimizing test procedures.  I don’t get the connection to customer satisfaction, it stands fine without that prefix.
  • § Reduced escaped defects while reducing cycle time by 50% by establishing and then optimizing an Integration Test Plan. What is an escaped defect? Also, once again you created something (the plan) then had to go back and optimize it. You are creating subtext that you don’t get things right the first time through.
  • § Created a System Test team in Turin, Italy by identifying and training a team lead, developing initial test plans and training team members. Created is probably the wrong word unless you gave birth to them.

Software Engineer, GPRS SGSN (2.5G) Core Platform and Availability Team (2000 – 2002)

  • § Reduced software defects by representing the Platform team on Change Control Board for problem reports and design changes. Analyzed, assigned and tracked problem reports.
  • § Resolved system stability and availability problems with high customer impact. Traveled to Europe on two different occasions to successfully resolve major availability problems.
  • § Supervised and mentored co-op students. Assigned tasks, monitored progress, evaluated performance.
  • § Received three “Bravo” awards for exceptional performance. Tell me more about the circumstances of the award.

Forward Software                                                                                                  1996-2000

Contract Programmer/Analyst                                                                                                        

  • § Developed ERP software using Progress 4GL and RDBMS. May be true, but it feels like an exaggeration. You did this single handedly?
  • § Worked on payroll, accounting, manufacturing and “data mining” software packages. Turn this into an accomplishment. I don’t want people that “work on” stuff, I want people that get stuff done!

Placer Dome                                                                                                               1993-1996

Systems Administrator, Campbell Mine (1995 – 1996)

  • § Administered a mixed UNIX and Novell PC network. Any accomplishments to note other than filling a chair?

Programmer, Vancouver (1993 – 1995)

  • § Implemented database (what platform?) inventory system from design documents. Too specific, remember that the little things hurt when you call too much attention to the obvious.
  • § Tested third-party software. Say what? This seems vague and doesn’t indicate an accomplishment. Anyone can do, you need to show excellence.


2008            M.Sc in Information Systems at Athabasca University. Essay Project titled “Concurrent Programming – A Case Study on Dual Core Computers.”. Completed courses include Distributed Systems, Project Management, Human Computer Interaction, Enterprise-wide Network Architecture, Data Structures, Systems Analysis and Design. (Separate degree onto separate line from details to highlight it)

1991            B.Math in Pure Mathematics from University of Waterloo, after 2 years study in Electrical Engineering.  Graduated on Dean’s Honours List.  Received Engineering Entrance Scholarship, Descartes Fellowship. (Separate degree onto separate line from details to highlight it)


5NINES training – Sounds promising, give more detail!

PowerPC programming – Is this programming on a particular type of computer? Is this relevant to the job you want?

LynxOS device drivers – What about them?

Inspections training Fluff – This is meaningless outside your current firm.

Inspection Moderator training  Fluff – This training helps someone at another company, how?


Disposition: Promote candidate to phone interview stage.
Initial Impression of Candidate: B+

The Code Sample (The Programmer’s Guide to Getting Hired)

Why you are being asked for a code sample and what it says about the employer.

At some point during the developer recruiting process, any hiring manager with the remotest concept of due diligence is going to attempt to get a preview of what to expect from the applicant either by requesting a code sample or asking them to write some code during an interview. In furtherance of my ambition to minimize my resemblance to a jackass and to do my part to optimize useless effort out of the universe, I tend to forestall asking for code samples until I have arrived at the short-list of candidates that I would seriously considering hiring. Unless I have more than five or six really solid candidates (very rare), I’ll generally ask for the code sample at the end of the phone interview if it has gone well, and ask the candidate to e-mail it or bring it with them to the in-person interview.

Although management styles differ, I think it is a safe bet that a code sample request is a strong indicator that you are progressing well through the recruitment process and so far have made a favorable impression. I base this on the assertion that few managers are going to be willing to wade through dozens of code samples from marginal candidates in hopes of finding a diamond in the rough unless they are having a really hard time finding candidates because they have a lot of positions to fill quickly or need someone competent in a niche technology.

It’s a good thing, I promise!

I definitely understand that competency tests like this during the recruiting process are stress inducing for the candidate, but take heart that a request for a code sample can be a very positive sign for the candidate. Not only is it a sign of interest, but it also shows that the company is the type of place that carefully vets their technical people. Believe me, you do not want to work somewhere with lax recruiting standards. There are a number of reasons that companies hire without scrutinizing candidates thoroughly and almost all of them are bad news the person who ultimately gets the job.

  • They have a backlog on recruiting due to high turnover as they desperately try to replace people who are running out the door.
  • Lazy hiring managers who would rather over-hire and then weed people out on the job.
  • Supervisors that don’t understand technology and are afraid to ask questions because they wouldn’t be able to interpret the answers.
  • Lots of under qualified co-workers who are a continuing source of bad code that you’ll have to debug, and no mentors in sight.

Dissenting opinions and my rebuttal

If you have spent any time in message forums that focus on job-hunting for techies, you have no doubt come across a certain vociferous element that despises employers who request code samples and/or certain types of interview questions. While I empathize on the abuse of puzzle questions, extremely obscure technical questions, and extreme pressure interviewing techniques; the arrogance exhibited by some of these people frankly amazes me. In a separate article I discuss to the type of candidate that thinks “I’d just Google it.” is an acceptable answer to any technical interview question, but for now I’ll to address the fallacy of arguments like the following:

“Can you believe they asked me for a code sample? I have 10 years of development experience on my resume and four certifications. I’ve earned my stripes and shouldn’t need to prove myself to anyone. They are probably just trying to trick me into doing work for free. I’m not a monkey who is going to dance for their amusement!”

Unless this guy is Bjarne Strousup, John Carmack, or some other luminary of technology, he is wrong. Professional programming is the type of gig that has very few celebrities. If I could identify the most skilled programmer alive today, chances are that you wouldn’t recognize him or her. Even for those few programmers that you might recognize either their name or work, it will often be only because of the high profile projects they worked on and not necessarily their code-fu. The simple truth is this, most programmers are anonymous, even the really good ones. Before you start commiserating with complainers such as the one in my example, be sure to read some of his other posts about how there are simply no jobs out there evidenced by the fact that, despite his obvious skill, he has been out of work for 8 months already. Recruiters can spot attitude problems like this a mile away and know enough to put a second mile between themselves and these head-cases for good measure.

The bottom line is that you shouldn’t take efforts to validate your qualifications personally. Hiring managers have just learned through hard experience that they can’t blindly trust anything on a resume. There are simply too many people applying for jobs with puffed up resumes full of certifications yet they couldn’t code their way out of class PaperBag:Bag. It’s just the process, not an impeachment of your abilities. If you are still not convinced, consider what you would assume about a supposed “rock star programmer” who was so hesitant to show off his code. It smells fishy, and managers don’t want fishy when making decisions that will cost 5-6 figures per year plus benefits.

Code sample requests encourage “failing-early” in the recruiting process

Before I even look at the code sample provided by a candidate, I have effectively screened out three types of undesirable candidates that won’t submit the requested sample.

  1. The angry egoist described above.
  2. The resume padding exaggerator with no programming skill who has just realized that I have called their bluff.
  3. The tire kicker, who isn’t really interested in the position, but is applying on the off-chance that I might be able to give them a $50K salary bump.

The hidden agenda

The request for a code sample has a side benefit, in that it lets me test something beyond programming skill without being completely overt about it. In many cases I’ll add some special requirements on the code sample request, for example specific languages, length limitations, or submission instructions. This is an excellent way to detect candidates who refuse to follow directions or jump into solving problems before attempting to understand the requirements. Closely reading the instructions presented by a prospective employer, asking relevant questions as needed, and re-checking against those instructions before submitting will get you further than at least 25% of the candidates that make it to this stage.


No excuses – give up the sample

There are a number of reasons people give for providing a code sample. In my opinion, none of them are acceptable. I’ll address the two most common here.

“All my work related code is proprietary. I can’t betray my current/former employer’s trust by showing it to you.”
Good for you. I definitely respect your dedication towards protecting your employer’s intellectual property. In fact, it would probably color my opinion negatively of you as a candidate if you submitted a code sample that looked like it might contain trade secrets. However, that doesn’t get you off the hook. Many candidates mistakenly presume an implicit requirement that the code sample must come from your professional work experience. Unless you were specifically told this, this assumption is usually not valid. Whether it is fair or not, I interpret these responses as “I can’t send you any of my existing code, and I’m not interested in the job enough to bother writing anything new.” Do I really want to hire someone with the attitude, “I have to write code? Bummer!”

“I am a student and only have code from academic work.”
Again, I don’t care why you wrote it as long as it is your own work and it meets any requirements I specify.


Even if you do have some previous professional work that you are not restricted from sharing, I’d strongly advise you to take the time to write something fresh to use while you are interviewing for a programming job for a number of reasons:

  • Your coding skills should be improving over time, thus your newest code should be the best you have ever written.
  • The code you have already written was probably created under constraints that won’t be apparent to the hiring manager. You don’t want to submit code that requires an explanation or apology.
  • In most cases, you are free to write code to do whatever you want for the sample. You rarely get a chance to choose a problem that you are good at solving, take advantage of it.
  • Your existing code was written to solve a work problem not sell your skills. Different objectives require different approaches.
  • You have a chance to write code that matches the technologies/tasks that match the job description.

That last point is important and applies to other areas of the recruiting process. Anything makes you seem more familiar to them will help your chances because it encourages them to start thinking of you as an insider. Unfortunately, I also think this tendency is also the source of a lot of unintentional and illegal discrimination during the hiring process, but good managers have learned to recognize their own natural biases and find ways to remain objective about candidates.

Code sample ideas

For the truly stumped, here are a few ideas for programming tasks that can be solved in just about the right amount of code that works for a code sample, yet aren’t so trivial that they undermine your credibility.

  • A utility class for logging events and errors either to a file or the system event logs with a configurable level of verbosity.
  • A set of stored procedures for maintaining and searching data in a hierarchical tree structure.
  • An implementation of the singleton design pattern to serialize access to a resource file.
  • A calculator function that takes a single string of input that includes numbers and operators and returns the numeric result of the equation. Don’t forget input validation, error handling (divide by zero), and operator precedence concerns!
  • A method that takes a URL to a web site and a local path and downloads all image files based on <IMG> tags.
  • Create a method that takes a keyword, message, and login credentials and uses the Twitter API to respond to post the message as response to any friends of the account specified.


Best practices for preparing a code sample

A request for a code sample is like a take home exam, and there is no excuse to not ace it. Although code samples are more frequently used to identify potential problems than recognize programming skill, there is still some opportunity to score points with your submission. Making sure the code is highly readable is one of the best things you can do to improve your standing through the code sample. Although some of these items should not be considered a best practice for actual programming work and many of them are not even practical when you don’t have total control of the problem you are trying to solve, they are great ways to increase the readability of code sample submissions:

  • Separate logical blocks of the code with extra blank line. Whitespace is your friend.
  • Avoid line-wrapping as much as possible.
  • Method and variable names need to be meaningful at face value without reading the code that calls or implements it.
  • Reduce the number of parameters to functions you write, and avoid passing in optional parameters as much as possible.
  • Variables should be single use only.

Dim loopCounter as integer
For loopCounter = 1 to maxPages
‘do something with pages

For loopCounter = 1 to maxDucks
    ‘do something with ducks

Dim PageCounter as integer
For PageCounter = 1 to maxPages
    ‘do something with pages

Dim DuckCounter as integer
For DuckCounter = 1 to maxDucks
    ‘do something with ducks

  • Use variables instead of inline function calls

fooResult = foo(subfoo());

fooResult = foo(subFooResult);

  • Put in at least a few comments to show that you know that you are supposed to. However, follow best practices and don’t overdo it.
  • Show the code to another programmer and ask them to tell you what it does and how as quickly as they can. If you get even the slightest urge to explain while they are reading or they ask questions, rework it to make it self explanatory.

Don’t forget the quality control

You did have five of your best friends QC your resume and cover letter before you submitted it, right? Isn’t the code sample worth the same scrutiny? Understand that the code sample is used more often as a NEGATIVE differentiator than a positive one. In case you don’t speak marketing, this means that the person reading your code sample is using it to weed out bad candidates not find good ones. Here are some suggestions to keep your resume out of the trash-bin:

  • Compile the code – It is just plain lazy to give them code with mistakes that are so easily caught.
  • Spell check your comments and identifier names – Yes it is silly, but don’t give them chances to take cheap shots at you.
  • Unit test the code thoroughly to make absolutely sure it does what it is supposed to. If the job posting lists TDD you might even consider submitting the unit tests for extra credit, but be sure to confirm before doing this if it forces you over the code size they asked for.
  • Check for and eliminate any code that is borrowed or even looks like it might be. Hiring managers sometimes Google unusual identifiers and method names to make sure exact matches don’t come up for your code. You might want to do this too to see what comes up.
  • Find the smartest programmer(s) you know and ask them to tell you 5 problems, no matter how nitpicky. This prevents them from trying to be polite or lazy and not looking too closely. Getting the job is more important here than protecting your ego.

Other tips on preparing a code sample


  • Keep it short and simple. They are looking for ammo to filter you out. Don’t give them a lot of code to find fault in.
  • Don’t use clever coding tricks. They decrease readability and rarely impress anyone.
  • Use the code sample to demonstrate your knowledge of technique (Design patterns, generics, OOP, TDD) and specific technologies (AJAX, Web Services, XSLT, SQL DMO). Use the job description for cues for what things you might want to include.
  • Avoid controversial approaches such as Hungarian notation whenever possible. You don’t want to be forced into a confrontational posture with a zealot from a different camp that has pull on whether you get the job.
  • Don’t use comments to plead your case or apologize to the hiring manager as shown in the following counter-examples:
    /* I am really good with OOP as shown in this class! */
    /* Normally I would add error handling here if this were production code, but since I’m not taking this seriously… */

Your code sample and the interview

Even if you get a callback for an in-person interview after submitting your code sample, don’t rest on your laurels yet. For managers that work with a system similar to my own, there isn’t usually a round of cuts between receiving the code sample and the formal interview. Usually I just briefly scan the code sample for obvious deal-killers and don’t really read them carefully until the day of the interview so the candidate has a chance to defend it, if necessary. You can and should expect the code sample to be a topic during the interview, so be prepared.

Know thy code: You should know the code you submitted backwards and forwards, have some ideas about other approaches you could have taken, be ready to optimize it, and talk intelligently about all of the technologies you used. The code sample is fodder for under-prepared interviewers who are digging for something to ask about. “Interesting, you used the Fizbah protocol here. Would that work over IP too?”

Defend thy code: A lot of interviewers like to use a technique that involves contradicting the candidate in some way, such as questioning the approach in a code sample. You absolutely must defend your approach unless the interviewer has pointed out an indisputably better or more correct approach. Do not concede the point unless you understand the counterpoint thoroughly. A common trap is for an interviewer to play devil’s advocate just to see if you will fold under pressure. For example you are sunk if you bite when the interviewer makes a claim he knows is false, like “You shouldn’t have used the StringBuilder class here, it doesn’t work with Unicode.”

…but not dogmatically: When defending your code, however, you have to be careful to not give the impression that you are closed-minded or that you think you know everything. For example, if you got the StringBuilder/Unicode question and weren’t sure if the interviewer had a good point, you might say something like “Are you sure about that? I am pretty sure that isn’t the case, but it is a very valid concern. I’ll double check the documentation and follow-up with you in an e-mail later this afternoon.” This answer helps dissuade the notion that you might be a pushover, shows that you care enough in your craft to dig a little deeper, and that you are the type who likes to share knowledge of new discoveries.

…, and show that you know how to listen: When an interviewer criticizes a code sample or an answer to a technical question, many candidates turn off their ears as soon as they get detect a negative tone and start to cogitate on their rebuttal. Unfortunately this often causes them to completely miss the subtle clues that interviewers drop to help the candidate navigate the objection. It is critical that you practice active listening skills during an interview for this very reason. It looks bad when you make mistakes in an interview, but it is far worse to continue to flounder on a technical issue when the interviewer has thrown you a lifeline and you didn’t recognize it.