Here are some of the realities of India’s graduating students:
- India graduates 1.5 million engineers, less than 17% of these are employable in any IT firm, a much less percent are equipped to work in startups and product companies.
- Number of software engineering job, or IT professional job, is way less than this number.
- A graduating class of CS/IT from a typical tier2/3 college has almost equal number of male and female students. However, the entry-level engineers in a large number of companies are male-dominant.
These are not new information, Aspiring Minds’ survey data above came out around 2012 and these statistics haven’t change much since then.
My point is: you have beaten lots of odds to get this opportunity to work in a software company, and you have been found capable to do so. Why are you not doing the best you can to make the most of this opportunity? Because my experience suggests you are not. You are being lazy, or naïve, or both.
I have been interviewing software engineers (0-6 yrs. experience) for quite some time. Over last 6 months, the pace of these interviews have picked up considerably and so some impressions from the interviews have stayed with me for much longer than I would like. This post is to share some of these impressions, and offer some advice to people who may find themselves in similar state (as described below).
Here are some of the signs that you may be lazy, or naïve, or both, as far your handling your own learning and growth are concerned.
- You have been working in a pattern of work which asks you to do the same thing again and again – project over project, release over release, year over year. It is the same kind of UI elements to be added on different pages, adding simple CRUD operations for different objects, coding a screen which is almost same as this other page you did last time.
- You hardly engage in discussion about problem-solving and design, either in the interview or on the job. Data structures, algorithms, design patterns, object-oriented thinking, etc. sound like alien academic stuff not relevant for your job. You talk of a lot of technology buzzwords, but don’t know the concept behind most of them and have no idea if you are asked to do them from first principles.
- You are not very articulate in interviews or at work – you either talk a lot without substance, or talk very less, or talk unrelated stuff. You can’t clearly explain your own accomplishment in a way that an interviewer or someone outside your work can understand, many times you can’t clearly explain (or don’t know) what business problem or goal is being served by your work.
- You have not worked on non-functional part of the code – it is hard for you to visualize scale, performance, operability, quality, security and other non-functional concerns about software since you haven’t been exposed to it
You may also realize that while your company and job probably didn’t require you to do any of these, but you too didn’t spend your own time to work on these.
Why is this a problem?
I have spent quite some time reflecting on these and why my interviews have gone on similar lines with so many people. And I know I have seen an extremely small subset, there are a lot of people out there in similar state in their software engineer career journey.
In my mind, all of this boils down to one fact: these individuals haven’t paid attention to the reality that they are not learning or growing in their job. And this is a big problem, because there is no career to be made if there is not enough learning and growing in initial foundational years.
As I had written a long time ago in one of the posts ( Workplace Reality #1: Organizations care for value, not you), organization most of the time will not care about whether employees are learning and growing on the job or not. It must be the responsibility of the employees themselves to care about it.
If you are not working on a more complex problem today than what you were doing yesterday, you are fooling yourself into thinking you have mastered your skills and hence the work is easy now.
If you are not paying attention to how many bugs are being discovered in your code and getting better accordingly, you are becoming less valuable to the company.
If you are not increasing your ownership from code to design to problem-solving, from tickets to features to modules to projects, from development to engineering to customer to business, your impact to the organization is reducing on a relative scale since a more junior engineer may be doing the same as you at lesser cost to the organization.
Of course, it may be the environment as well that makes this happen – IT companies operate in similar ways and you may feel trapped into them. But it doesn’t matter – since you are the one who sufferes because of this, you still have to do something about it.
So if you are not aware of this, or are aware but not doing anything, rest assured organization is not thinking either.
This is a big problem, for you. You need to do something, starting now.
So what can you do?
Here are a few things you can do:
- Evaluate your work pattern and see how much of it matches the signs above. If they do, try to understand why is that the case. Sometimes it is because you haven’t try to ask for a different kind of work. Most other times, it is because company has gotten comfortable with you doing it this way, and you haven’t demonstrated that you actually have other skills that make you more valuable.
- Reflect on the skills you have that you are not using. If you keep working on front-end, see if you have API development skills, or SQL skills as well, for example. If you work on mobile apps, maybe you also have skills in web front-ends. There is a good chance that you have lost some of those skills, in which case you should brush them up by picking up a side project, enrolling in an online course, etc. If you do find a skill you still have, do talk to your manager in your next 1-1 to see if you can make more use of it going forward.
- Evaluate your problem-solving and design skills – there are lots of design problems out there, google them, try them out and see if you are good at those. Read up about strategies for problem-solving, design patterns, data structures and algorithms etc. and see how they apply to your work. It is very unlikely that you don’t find their application, it is just that you haven’t thought of your work in that way.
- Find a mentor, within the company or outside, who can help you as you evaluate yourself and have questions about it or need guidance. It is easier to get a mentor than you think – there are many people who will be willing to help if you can demonstrate you are serious about using their time judiciously.
- Evaluate your written and verbal communication skills. Enroll in courses if you need to – most software engineers do not focus on this but communication skills are key to being effective at workplace and beyond. And these are easier to acquire than some of the technical skills you may have already learned. So make an attempt to keep getting better at them.
All of this starts from the acceptance that there is a problem that needs to be fixed urgently.
Acceptance is the absolute first step. If you take that, other steps are way easier and totally within your reach.