I Apply Therefore I Am

"An engineer is a professional practitioner of engineering, concerned with applying scientific knowledge, mathematics and ingenuity to develop solutions for technical problems." - Wikipedia.

Application. Problem Solving. That is precisely what engineering is about.

In the 4 years that I spent studying engineering however, there were few examinations that actually required solving problems ingenuously by applying knowledge acquired during the course of studying the subject. The only knowledge engineers in India need to possess is the fact that if you spend enough time practicing questions from the last 5 years' papers, you will emerge unscathed into the next semester.

So exams as a medium of testing application is thrown right out of the window. There used to be a saving grace however - the Final Year Project. Your one chance as a future engineer to completely embrace and understand a problem, design and implement it (if you are lucky, with valuable guidance from an able guide), and then proudly present to a jury what you have accomplished in one year.

Revelation

Over the past few months, conversations and interviews with young software engineers have woken me up to a reality apparently everyone else already knew about - no one does their Final Year Project on their own anymore. Well, almost no one.

Open a candidate's resume, find the Final Year Project title, and a quick Google search will reveal two things -

1. There is a paper published in an IEEE journal with the exact same title.
2. The project is available for sale at one of the local software training centers.

Teams of four are still formed to "execute" a project, but their members contribute more in terms of chipping in to the pool of money that will be used to purchase a neatly prepared, gift-wrapped project, complete with printed theses and presentations.

Bring the project up in an interview, and 2-3 basic questions later, it is already clear the candidate has no clue how to solve this problem. An excuse or two about amnesia later, the truth bundles out. This is followed by the familiar adage of "everyone does this".

How the examining jury does not realize this project was bought off the shelf like candy is beyond me. Perhaps they have also bought in to the "everyone does this" routine.

Certified To Be Trained

The monolith that is the Indian IT industry has long ago accepted the fact that engineering degrees count for little, and that every single fresh hire will need to be put through the paces of a training regimen. This has in turn lulled our future engineers into the belief that they do not need to apply or prove anything in their 4 years.

Why bother when you will undergo training in DotNet and Java anyway once you have been selected? Focusing on spoken English, aptitude tests and a decent score-sheet tend to pay off more handsomely in these interviews.

Solution At The Root Of The Problem

While not placing the blame squarely at the door of the Indian IT monolith at large, it is hard to see beyond it to find where the problem begins. Being a services based industry, it requires tens of thousands of employees each year - something that has obviously not gone unnoticed with ambitious parents who wish to bring up engineers, and the mushrooming new engineering colleges across the country. This has led to a side-industry of helping students push through the 4-year hurdle of getting a degree - first came the coaching classes, and then the "project training centers".

Instead of, or perhaps in addition to, running enormous training facilities for new hires, why do the behemoths of the industry not actively encourage final year students to take up projects with them? This has the triple impact of improving the quality of the engineer that passes out, while at the same time selling your organization to them and giving you prime access to the cream of the lot.

There are logistical issues to work out, but who is to say that students who can fund their purchases for off-the-shelf candy cannot instead spend on frequent visits to the closest office of a behemoth? Cash spent on grand recruitment schemes could instead be diverted to attracting more students directly from colleges to work on projects and prove their worth on the job, without having to pay them. This is not even close to being an original idea, but I am surprised it isn't more actively utilised.

No More Free Lunch

I like to repeat this. The day isn't very far when just like work migrated on the outsourcing silk route to India, it will migrate further to cheaper locations. When that happens, we either work on projects demanding a lot more application and problem-solving or build products for our local market, that again demand application and problem-solving experience. Both our behemoths and our engineers need to gear up for this eventuality. It has probably already snuck through the door and is hiding behind the couch.

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.