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.
SDE One (SDE I)
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.
SDE Two (SDE II)
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).
Coding
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.
SDE Three (SDE III)
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
- Databases are black boxes
- Networking is a black box
- Data Replication across different clusters is taken care of
- Horizontal scaling works, as long as there are other DevOps managing it
- NoSQL is better than RDBMS
- 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.