Software Developer

Yearly Reviews - The good parts

The yearly or half yearly performance reviews are the things every one looks forwards to, loves and hates. This is the only process where people get emotional and the details are personal. There are companies which only do only self reviews and those who add a 360° feedback. On the other hand there are startups where this process is cranky and screwed up( err., not so well organised). We hate the tools the HRs choose and the way the tools get stuck to on the last hour when everyone is trying to submit/finalize their reviews.

The self review feedback where I have from couple of friends that the feedback is only between you and your manager. This usually is biased since its only important what your manager thinks and your alignment with him along with the goals. Your manager does this for all others in the company. Your manager “may” get feedback from others, but “may” not be included. This is how startups or small companies which care of deadlines usually think. Its good for the employees short term since they only see what their manager wants them to see. (*depending on the manager).

Introducing the 360° feedback, startups transition to this when they usually want to have “changes” in policy and when they feel that 1-1 / self review feedback has had enough biases and see reports people are unhappy or when someone in the chain is unhappy. There are downsides to the 360° feedback as well. This does not work so well for introverts since they may not like to work well with others especially on the communication part which is crucial. If you are a senior developer, you get lots of requests. Middle Managers and Product Managers usually tend to get much more than 40 since they deal with many people.

About the financial aspect of things, is where different companies try to show different tactics. Some have fixed component based on your “rating” across 5 levels and decides how much increment you are eligible for and the bonus part of it also changes based on the currently vesting stock options(from previous years that have been granted) and some stock vesting grant for the future. Some companies tend to payout as a “variable” bonus which the employees look forward a lot to.

(getting side tracked here, open “details” if you want to read more)

In the current generation of corporate sector, the people are in a state where they “feel bad” if someone your experience is getting a higher salary than you or worse if a fresher makes even a penny more than you. Companies are okay with employees moving around (the iteration) and they care more about money given to employees than the amount of money kept to retain them. (This is only about local companies established with a sense of money and not a damn about people like the standard service based companies which employ freshers and fake them as 5yr experience to clients who blindly accept them. Not any two companies are the same. some suck more than others)

The “screwed up” process based companies (where I have experienced in a proclaimed “furniture startup” which does e-commerce) tend to work that every employee is responsible for the revenues the company make and cut your bonus based on that. This is the SOP in Indian based service companies where your actual take home is 70% of your CTC (after taxes). Even though you are not responsible directly or even indirectly for your company’s sales or pace of growth and if you want to do something to increase it, you will have to spend your own time to do it since you are busy with by existing deadlines and last minute feature creeps which did not exist 1 hour ago. I will explain how choosing such a company has impacted me and how you can avoid making the same mistake. I think I can write a PRD about how a company should not be, but I think I will limit it a post.

The good parts about the feedback reviews at companies is that, I really liked the way it was done at Amazon. Amazon has 15 principles. Any business decision you do is usually backed by it. There are some conflicting principles, but they really really help cover many parts of what you tried to do. Amazon Leadership Principles. If you are a developer, some code/features or design changes you have done may not fall into any of the categories. Your code does not have meaning till it solves a business problem or solution.

Every company should have such or similar principles where you can link any business action you have done which gives you a clear idea on what is right and what may be wrong in the decision you have taken. There are points for being wrong or right, which means that there are points for “trying” and being responsible.

Amazon Leadership Principles

I don’t currently work at Amazon anymore, but I love their principles. The amount of clarity it brings to you when you are reflecting on your previous year and the actions you have done is immense. Even if you are very small company or a startup, you should start using your feedback reviews with your company’s principles. I don’t see startups doing this, but it’d make a hell lot of a culture stick to your employees on what the CXX thinks and the company aims for.

Culture is created by what you publicly reward, not what you say

What Do SDE Levels mean?

When developers join a Product Technology company, they get confused by all the different types of roles in a company. I will start describing from the SDE job family. A job family has multiple levels. These levels are awarded to the employee based on their current skill. It usually corresponds to the salary as well.

Being knowledgeable about the levels at Amazon, Flipkart, I will consider Flipkart job levels since the company has been a golden standard in the Indian tech industry.

Software Development Engineer are usually at 5 levels, there is SDE I, SDE II, SDE III, Architect, Principal Architect. Its usually the company’s policy to keep salary ranges for each of the level separate as well as the bar. The bar indicates the level of the candidate according to various evaluations the company wants and how well the candidate can think.

Its a general intend for everyone to look at the money in the next level and try to jump fast to the next level along with the knowledge they can acquire by working with “Senior” folks in the team. This is the only way people feel like they learn. Teams or companies need to maintain a pyramid structure with more people at lower levels being mentored by higher levels. You see a range of people with different interests.


When you learn the basics of Computer Science and graduate with some interest in programming, you usually get into an SDE-I role . If you have 2-3 years of experience in another company, you would be mostly considered for SDE I only.

The candidate is assumed to have basic knowledge of computers with intent to learn anything s/he is told and follow orders with reason and do them whether s/he likes them or not, but does them. Following SOPs (Standard Operating Procedures) is the bare minimum expectation, finding solutions from StackOverflow is perfectly tolerable as long as they understand what they actually copied and gets a code review which matches existing code styles.

During this phase, engineers usually start with bug fixes and writing test cases( yes, this is usually missed in most Universities). You are looking at classes or functions and probably confused why the classes are organised in a highly meaningless way.

One of the strengths should be Problem Solving. When a bug is reported, able to reproduce the bug, identify the bug with help of log messages or tools and understand what has caused it and work with a team member to fix it.

To grow to the next level, it requires lot of hard work along with understanding of domain knowledge, identifying problems, writing solutions, understanding design to an extent.


When you are within a company, you get opportunities to solve problems and contribute to showcase yourself and grow the knowledge. It may take upto 1-3 years to move up from SDE I to SDE II.

Getting interviewed from outside is different from growing within the company. You get one day (apart from 2-3 rounds of telephonic) with 3-5 rounds. The reason I feel Algorithms, Data Structures, Problem Solving and Coding is asked is that they cannot ask you show your old code or spend time for a week with the team and share their proprietary codebases. (There are few companies which actually do these too).


They see how you write code given a problem. They would slightly tweak the requirements to see how you’d end up modifying the existing code. Here is where your knowledge of Design Patterns come in. All the rest of clean code, test cases, separation of concerns, DRY(don’t repeat yourself), abstractions and assumptions. What usually people do wrong in an interview is that they start coding immediately, you need to clarify anything you feel is amiss in the requirement provided.

Problem Solving

Given a problem you need to understand what may fail and why. This is part of the code you write above, but when you are at SDE-II, you need to think about Non Functional Requirements(NFR) as well. You need to think about identifying bottlenecks, identify what caused an outage in your codebase what caused the outage and pinpoint the code region (at the least).

Breadth of Knowledge

Usually a bread of knowledge is required not just in your code, but other libraries you use, may be in the infrastructure components your team uses.

What is expected out of you?

At this level, you may be in the limbo state of multiple solutions with pros and cons for each, I tell you that is a normal state to be in.

Thinking about Application Security, SSL etc., Ownership, Auth

Roles and responsibilities include mentoring SDE-Is or similar level in other job families. This the toughest position to be in, since you are neither not-experienced nor highly experienced and its tough to decide to give a new project to you and too easy to decide to give a bug fix. This is how you get to become an SDE-III by learning patience, understanding existing problems and pitch to solve them. With all these problems you face, this may be a right time to show case leader ship strengths too.


This is a very tricky level to be interviewed for, this is where engineers are supposed to be mature in taking decisions since usually it takes 5-10 years to get to that stage of maturity, knowledge, depth, breadth in your knowledge of applying solutions, dealing with NFRs, problem solving, dealing with components other than your code.

This is the level where Databases are not a black box. I have had many phone interviews to screen candidates at this level. The standard problems they face are

  1. Databases are black boxes
  2. Networking is a black box
  3. Data Replication across different clusters is taken care of
  4. Horizontal scaling works, as long as there are other DevOps managing it
  5. NoSQL is better than RDBMS
  6. Ability to keep an open mind

I will go over each of the reasons behind each of these in a separate blog post on why they don’t work.

SDE III is apart from other things is about understanding about Distributed Systems. Its important since you live in a world of SOA. This is required badly when you think about building scalable architectures and one wrong step and the team goes ‘Boom!’.

Showcasing patience at this level is important since you are the decision maker and have to deal with other SDE-Is and SDE-IIs in your team when they come in for advice.

There is system design, low level design, gathering requirements, understanding things you did not know existing or cared about the previous week like saving costs by changing hardware, identify resource wastage, building systems which all teams in your company may use, able to present your opinion in the right way to showcase The Good, The Bad and The Evil of approaches, respecting lines, understanding positives and negatives of a framework, ability to differentiate between various programming languages, anticipating problems which you may hit and differentiating between short-term and long-term.

Thats for becoming an SDE-III. Get here and ask me for what it requires to be an Architect or you may have figured it out at the scale of dimensions people work on.

I have been given an advice. With influence/privilege you can be put at a higher level than you are at, but you may not survive that level because you may not understand what is happening. I have failed an internal exam to be put into IIT (in 2003), they separated IIT classes from regular classes. I was devastated. An administrative guide who worked at the college told me this advice that he has seen people put in IIT section, but had to get downgraded after trying for 3 months and wasted them and were stuck in a limbo state.

This is the same with levels at companies as well. If you think you are at a higher level, your boss or colleague (a mature one) can tell you why you are not. There may include some political reasons or financial reasons for not promoting you if you deserve. Startup type companies will give you roles even if they can’t afford the money along with recognition. We talk about political youth party leaders who do not deserve where they are right now. Try not to be that person in your team.