The Software Chef - II

Imagine you are a music composer. Would you reel in a singer for your soon-to-be-a-hit song without having heard how they sing?

Now imagine you are a restaurateur. Would you have someone be your chef without having them cook something for you first?

Yet, we work in an industry where we seldom bother to ask a software engineer to write us a small program before we hire them. Why is that? Is software development deemed to be not creative enough? Not skill-heavy perhaps? Then why do we deserve these pay scales?

Your resume here says you can cook....

Some believe programmers can be "trained". All that matters is how intelligent and willing you are. This probably applies to our mass employers (need not name them here). Programmers are a commodity here.

Others believe it is inappropriate to ask someone who says they have been programming for 5 years to write us a program. Almost taboo. After all, programmers will have other opportunities where they are not required to write a program before they are hired.

It all boils down to what you are really looking for. Are you looking to add to your headcount because you told your client there must be 10, not 9, programmers on this project? Or, are you looking for someone who can fit right in and quickly start adding value to your team? Are you looking for someone who clearly enjoys programming, and would bring that same passion to the work they do for you?

The culture of programming

There is a culture to programming, just like with anything else where there are many ways to do something and many heads working together. That culture defines whether I put a space after the '=' operator, whether I use a typical loop or instead apply recursion, and whether I define my classes strictly by properties or by function.

Wouldn't it be useful if we had some idea of the programming culture a certain programmer is bringing into our organization? Does it suit your own programming culture very well? Would they bring a much needed breath of fresh air to your programming team? Or would your senior programmers end up having to constantly review their code so it all "fits in"? What would you have to live with, and what would you be able to welcome with open arms?

You do not necessarily need to use a programming test to weed out your candidates. But, there is so much to be learned from such a test about a candidate's programming acumen and style, that it would be absurd to ignore it. Does my chef candidate prefer to make their dishes too spicy? I'd prefer to know that so I could tell them before I hire them - "We like you. Your Baingan Bharta rocks. If you could just turn the chilli pepper down a notch for our customers.."


Cook me something...

Depending on your inclination to invest time in this, and the kind of team you are trying to build, one of the following testing styles should ideally suit you. The tests could be "offline" - the candidates do this when they can, while trying to balance their other responsibilities and their current day job. Deadlines could be extended on request.

Be My Sous Chef For Today: The ideal test is one that involves having your candidate do something you do on any typical day. That would involve sharing the whole code base with them, or have them work out of your own workstation. In fact, many startups do prefer this "spend half a day with us and do what we do" routine.

A Three-Course meal please: You could come up with an interesting problem that can be easily described in words, and that does not have a ready solution on the internet, and have your candidate solve it completely. Add bonus questions to see which candidates will push beyond the minimum requirements. Ideally, the solution should also have certain clear "culture" requirements like "use Object Oriented Programming" so that the candidate knows they will be assessed for this as well.

Cupcakes: The third best option would be to have them implement a helper routine or class you have developed previously as part of your own work. You should provide compiled classes that they will need (hopefully just a handful) as libraries to use, and perhaps even prepare a skeleton of the class they are expected to implement, complete with method names, arguments and even docstrings. This should be something they can do in a few hours.


Finally, you may choose to give them one shot at it, or provide feedback from their first submission and let them decide whether they would be willing to have another go at it. You will soon discover who is willing to go the extra mile simply because they want their programs to be "perfect" and "bug-free". (There is a reason I used quotes here)


I have made it a point to use programming tests as part of my recruitment process. If you try this out someday, let me know whether it worked well for you. What would you change? How would you make things easier?

The Software Chef

Imagine reading a 5-star Chef's resume. Now imagine this resume was written by a software engineer. The resume would typically have a section called "Skills" that would read something like this -

• Pots, especially flat-bottom ones
• Pans.
• Ladels. Expert in wooden ones.
• All kinds of ovens, including microwave.

If you now imagine yourself tasked with hiring a new 5-star chef for your restaurant, would this candidate be your prime target? No? What were you looking for in the resume? Did you expect the skills to read something like this instead?

• Expertise in sous vide.
• Learning and following traditional recipes.
• Baking
• Innovating with cooking techniques for fish
• Presentation of food
• Working under pressure on busy days

Then why do most resumes for software engineers read like nothing more than a laundry list of projects participated in and tools/languages utilized? Here's an example of a Skills section from a typical resume.

• OS: Windows XP/Vista/7, Ubuntu, CentOS
• Database: Oracle 8/9/10, MySQL
• Languages: Java, VC++
• Scripting: Shell script, Batch script, awk

Tell me about the journey, not the route
You worked on a project for the single largest bank in the world. But the team consisted of 50 people. Now how does one understand what your individual contribution was? You don't expect to be hired because you were on a team with 49 other people working on a huge bank project. Wouldn't you rather tell us what you learned along the way? What challenges did you overcome, either as an individual or as a team?

You worked 3 years on 15 DotNet projects for various customers. But how does one understand the challenges involved reading a description of the project in marketing lingo, probably pasted from the customer's website? What did you learn that you can apply in a similar project that requires using Python-Django-HTML instead of DotNet? How to design for scalability perhaps? How to interact with customers to improve usability maybe?

Think beyond the pots and pans
It would appear to be the single-minded focus on developing thousands of "workers", which is in the very nature of the software outsourcing industry, that is behind this fixation with brand names and technologies in a resume. Engineers are trained to become a Java Ninja or a MySQL Samurai, as opposed to becoming a Systems Engineer or a Database Architect. Eventually, with sufficient "rinse and repeat" cycles, engineers start associating themselves with the tools, not the problems they were intending to solve.

If you were really a 5-star chef, one would expect you to deliver nearly as good a result with the limited resources available in my humble kitchen at home as you do in your well-stocked restaurant. "Oh, but I can't do this without a microwave oven" will normally be treated with suspicion. Yet, I come across many a software engineer who say they are loathe to programming in Python after 5 years with Java.

"What happens to all those years I spent learning Java?" The simple answer is, if you spent 5 years learning how to use the sewing machine, then you might have missed out picking up the nuances in the art of tailoring.

Evolve, or dissolve
Are you prepared for a day where there may be no one using DotNet? Where the "Cloud" is the platform, and no one cares about an OS anymore? Where your software must run with similar experiences on a laptop or a tablet or a smartphone? Where all outsourced projects go to Vietnam or Phillipines, and we must build products for our own market instead? Where you are expected to be a problem-solver rather than a technician? After all, that is what an engineer was supposed to be, right?

What's The Objective?

Having read literally hundreds of resumes in the last few months, I have come to one definite conclusion. There is no value to the first thing candidates want you to read on their resume - The Career Objective. The Career Objective was intended to be a statement of your ambitions and expectations, yet it has turned into a chore for both the candidate and the recruiter. The candidate struggles to fiddle with adjectives, hyperbole and tenses in a desperate bid to make their statement stand out from the rest, while the recruiter is left with the task of demystifying a candidate from the Shakespearean prose that is facing them and to figure out how this one sentence differentiates this candidate from the rest.

I will be the first to admit that in my more youthful past, I have myself spent an hour or two sharpening the prosaic of the Objective of my career even before it had begun. It ended up being a melee of words like "challenge", "cutting-edge", "research" and "work-life balance". I will never know if that effort helped me land jobs or the interviews that preceded them. 

Most Career Objectives are a mash of the words "challenge", "skills", "growth", "organization" and of course "career". Toss them in a bowl with a random assortment of adjectives, whip up some hyperbole, and top it all with a dash of originality, and voila, you have an all new Career Objective. Here's a random sampling of a few that prove the futility of all the effort that goes into coming up with one -

• Peak of the bell-curve: "To pursue a challenging and growth oriented career where I can make meaningful contribution to the organization together with continuously enhancing my skills and knowledge."
• Slightly to the right: "To secure a challenging position where I can effectively contribute my skills as Software Professional, possessing competent Technical Skills."
• Slightly to the left: "To have a challenging and exciting career where I can explore my potential and become one of the best technicians and grow with the organization I work for."
• Remarkable: "To gain specialization in software development and establish myself at a remarkable position in information technology sector to efficiently contribute my skills forward the organization."
• Might as well add other obvious characteristics, like "I will wear clothes to work": "To pursue a career in software industry as an efficient dependable employee being resourceful to organization and affable towards my colleagues."
• Seeking a full-stop: "To pursue a challenging career in a fast growing software development organization that provides an environment for continuous learning, where hardwork, creativity and commitment are well rewarded and utilize the same for consistently rendering my service with enthusiasm in achieving the organization objectives and goals."
• Adjective attack: "To pursue an outstanding career and be a part of progressive organization that gives propensity to enhance my knowledge and skills which can be better extended for organizational as well as personal intensification."

  The most readable Objectives i have come across either look like this -
"Seeking Graphic/Web Designer position in an organization that provides innovative and challenging opportunities."
Or like this - "".

My intention here is not to poke fun at the Objectives people come up with. Heck, I came up with one such monstrosity myself in the past. Instead, I question the very objective of having to come up with one for yourself. Most of us use resumes from friends who just landed a nice, cushy job as a template for our own. This ensures our objectives in life have a hauntingly high correlation with those of our "successful" friends. Very often, the objectives themselves are written in flawless grammar compared to the more original remainder of the resume.

All recruiters soon come to the conclusion that most objectives have zero entropy. Why then do we still carry on with this pointless exercise of inventing a poetic vision of one's career and hoping someone will care about it? My sincere advice, for what it's worth, is to do away with inventing an Objective for your career. Let your work speak for itself. Your hyperbole and adjective are better reserved for any challenging work you have attempted and/or completed, and the skills you have developed doing them.