Just Landed

An Outsider’s Perspective From The Inside

  • About Just Landed

    Just Landed is a part of the ever-expanding Blandings Media Empire.
  • Write Me

    justlanded AT blandings DOT com
  • Archives

  • Categories

What We Look for in CS Grads

Posted by anandrr on August 25, 2008

I recently visited our old alma mater, NIT Calicut, for a round of campus interviews for our company. While I was there, I met with old professors who had had a hand in teaching me and we spent some time discussing what we were looking for, and I was asked to write it up, so this write up would be that write up. We were interested only in students of Computer Science and we take some not insubstantial pride in the quality of engineering talent we already have at our company and the quality of incoming talent and our rigorous process for inducting this talent. I’ve personally interviewed hundreds of candidates over the last few years, and like to think that I have some key insights into what makes a successful engineer and what doesn’t. At any rate, I have keen insight into what makes an engineer employable at our company and what doesn’t. In all my discussion here I am thinking only of students just completing engineering school, people who in India are termed “freshers.”  In a future post, I will discuss some more about non-engineering graduates and graduates in general, but here the discussion will be strictly CS grads from our best engineering schools (EF will be participating in campus recruitment at a couple IITs, IIIT Hyderabad, NITs Calicut and Trichy, and the top engineering colleges in Chennai, Bangalore and Coimbatore). Follow me after the jump, if you still care about what I have to say about all this.

Nasscom believes that about 25% of engineering graduates in India are employable. If we restricted ourselves to just CS engineering graduates being employed in the field of their choice (i.e., as software engineers, ops engineers, QA engineers), I believe the number would be more like 50% of engineers graduating from the top schools, or less than 5% of all graduating CS engineers. With some training, that 5% number might rise to 10%, with some substantial training, the 10% number might go up to 20%. But if we restricted ourselves to employable out of the gate as soon as they receive their degree, 5% is a generous estimate. (When we say employable, we mean in software engineering, employable as a telemarketer doesn’t count). To give it some context, the equivalent number for the US is probably about 50%. Which basically means that India might be graduating 10x as many engineers as the US, but since the quality fraction is off by about 10x, the number of employable engineers is about the same as the US. This would explain why salaries of Indian software engineers is rising so dramatically. There are so few good ones that they have great leverage against their employers. Just to be clear, graduating as many employable engineers as the US at 1/5th of the cost is still a game-changing situation whichever way you look at it. On the other hand, consider the opportunity cost! All those resources spent educating and training 95% of our engineers is completely wasted. Infosys for instance spends serious resources re-training many of that 95% just so that they can have a workforce that will keep their business moving forward. And we aren’t speaking here of serious on-the-job-vertical-specific training, we’re talking about the basics: stuff they should have learnt in school but simply didn’t.

EF India is a seriously great place for young graduates just getting started in their careers. We are a technology company, so our engineers work on real technology problems and help build a great product. We didn’t divvy up our efforts as core work in the US and shit work in India, the teams that work on our product span our offices, so folks here are working on the same team and products as folks there, they just happen to be in different countries. We pay reasonably well, about average for an MNC, all employees get options, they all get to visit the US office for training and integration with the teams, it’s a casual atmosphere, free dinner everyday, the works. In short, it’s a great place to build your resume and strengthen your experience, while you have fun doing it.

We like to think we attract some great talent, put them through their paces, and if they make the cut the pleasure of hiring them is entirely mutual. What exactly do we look for? Let me restrict myself to just software engineers for this discussion.

The first thing to understand is that we recruit engineers and not technicians. In our opinion, engineers understand the fundamentals and are able to think abstractly and apply their learning and thinking to the problem at hand, additionally, engineers do not need to be trained every time a new technology is to be used or when they are moved from one product group to another. Technicians on the other hand are very comfortable with the few things that they have been trained to do and are very unlikely to perform well outside their comfort zone. A well trained engineer for instance, would not have to be trained on Python today because that’s what all our infrastructure code is written in, and then have to undergo rigorous Java training tomorrow because that’s what all our front end code is written in. All computer languages after all are only special cases of a generic class, anybody who has taken and understood a Principles of Programming Languages course should be able to think about all languages in the abstract and easily move from one language to the next. It might take them a day or two to get comfortable with the syntax, but that is as long as it should take. Similarly with whether the engineer is dealing with Oracle, MySQL, PostgreSQL or any other database. A technician on the other hand would have to be retrained when we moved him or her from language to language or database to database. In addition to the added cost of retraining, this betrays an inability to indulge in abstract thought.

When we hire software engineers, we look for three things: He/She should have a strong understanding of the fundamentals of Computer Science,  he/she should have spent real time at a computer (preferably running Linux or other Unix variant) writing and running code, and he/she should display a certain curiosity about how things work (should be true of all engineers surely, not just software engineers). Our selection process attempts to test for all these. I’ll discuss each of these in turn, and try to provide examples to illustrate what I mean.

Taking it in order, a good software engineer should have taken and aced courses in:

  • Theoretical Computer Science
  • Computer Organization and  Architecture
  • Principles of Programming Languages
  • Discrete Mathematics
  • Mathematics
  • Compiler Design
  • Operating Systems
  • Data Structures
  • Databases

Obviously CS courses cover a lot more ground, but an engineer with a grounding in all of these is probably ready to take on the real world. Even the Databases course requirement might be overkill, we do a lot of DB work ourselves, but I’m not going to hold it against an engineer if he/she is weak on databases (same with other courses like Networking, Advanced Architecture, Graphics etc.). We test for this requirement via questions about regular expressions, grammars, time complexity of algorithms, etc. My interviews sometimes involve a discussion about the best way to implement a set data structure and the tradeoffs involved in each of the available choices. There is no one right way to implement a set, your implementation should obviously depend on the problem at hand, but a good engineer should be able to talk intelligently about all the available choices: linked lists, binary trees, hash tables and so on and talk about the implications of each choice.

Notice that I don’t list any languages in the list of courses. No requirement of C# or ASP.Net or Java or whatever the flavour of this month is. A CS course should teach students one language, I recommend C, in their first year. After that, they should be empowered to learn new languages and technologies on their own. Perhaps at some point when they learn the Lambda Calculus it might make sense to teach them Scheme or Lisp, but that is as far as a course should go in teaching students new languages. Many times course administrators chase the latest fad, imagining that teaching their students these fads is making them more employable, after all this is what the industry wants. But this doesn’t help the students or the industry. Refer to what we said about training technicians as opposed to engineers. All of these “technologies” are simple things, it should take a well trained engineer no more than a day or two to pick up any single one of them. By spending entire semesters training students in specific languages and technologies we do them a disservice by training them only in these specific areas at the cost of teaching them abstract concepts that will let them understand any of them easily with little external help except available documentation.

The second thing we require is that students have spent real time in front of a computer writing and running real programs. The employee will spend almost all of his/her time doing exactly that. To this end, the student should have to take a lab component in most of their courses and should be required to pass the lab component to pass the course. This includes courses on data structures, algorithms, compilers and operating systems. We sometimes come across students who seem to meet the first requirement: they clearly aced all their courses; but who break down completely when asked to write code. It quickly becomes obvious that passing their courses didn’t involve going to a computer lab. This happens either because the school does not have the resources to invest in a computer lab, or because the school is lax in enforcing the programming aspect of the courses, and considers its work done when it has taught the students the contents of the books. The result is terrible: graduates who are completely unemployable. Perhaps theoretical knowledge can be picked up from reading books, but there is really no alternative to hard practical knowledge. And if we wasted four years of school not getting this practical knowledge, the graduates are now going to have to find a computer lab elsewhere and get the same practical knowledge. The result of this lack of practical knowledge is that an entire industry has arisen to serve this need. NIIT and similar colleges proudly offer supplementary courses for engineering students who don’t learn much in school. However, the infrastructure at these schools isn’t much better, they are money spinning machines just as much as the original school that the student is going to. The net result appears to be that a whole lot of people are getting rich allegedly making our CS students employable but leaving them just as pathetically unprepared as they already were.

Finally we come to an intangible: a curiosity about the world and how things work. I am tired of asking students a simple question: What is the maximum memory size that a Pentium processor can address? And finding that the student seems to have no idea of how to approach the problem. This tells me first that the student didn’t pay attention in class, and second that although almost every one of them seems to have a computer at home, none of them has opened up his/her computer to look at its innards, nor have they investigated to find out anything about the computer that they already have, so as to understand how it relates to all these computer architecture classes they have been taking. I don’t know if this can be taught, but it would be nice for a change to talk to students who have spent time just poking at computers to understand how things work and how they relate to what they learnt in class. How for instance does grep work? Can I install Linux on my computer, and if so how would my life change? What I would give for a student who just spent a few hours sitting and reading man pages (or its modern Internet equivalent) and serendipitously discovering how to make the computer do things they hadn’t thought of!

When I write later about all higher education and not just CS education, I will write about how we are churning out people who have not been taught any fundamentals but merely taught to pass examinations. In the CS case this is still true but presents an additional moral twist. Our BSc courses are rightly belittled and parents across India seek to get their kids into Engineering schools, especially into Computer Science engineering degree programs. The result is that our best and brightest students are all being marched off into programs that do so little to help them become good software engineers. Indeed, we are wasting four years of the most productive time of their lives and not preparing them in any way for their future careers. If we want our CS graduates to be stuck maintaining old cruddy software, coding HTML pages, or providing technical support we are doing a good job. If we expect them to turn into software engineers who are able to  create new technology and products and are in a position to change the way things work, we have a huge gap between what we’re turning out and what we need.

Advertisements

4 Responses to “What We Look for in CS Grads”

  1. […] What We Look for in CS Grads […]

  2. K Murali Krishnan said

    Nicely articulated.

    The root of the problem is recruitment and training of teachers in engineering schools. Very little is invested on teachers. As a result, insturction and evaluation process lacks quality, kills the inquisitiveness and creativity of the student (4 years in a bad school can demolish an individual) and results in production unempolyable and “untrainable” engineers, Masters and even PhDs.

  3. Rakesh said

    Very informative post… all prospective grads should have a look at this

  4. […] What We Look for in CS Grads […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: