Jayanth Kumar's Blog, page 2

The Technical Engineering Interview Guide

Why, what and how?Prologue

Every organization, today is relentlessly pursuing to attract the best talent out there and to be the best employer, and the most diverse, inclusive and equitable place to work after all,

Good leadership requires you to surround yourself with people of diverse perspectives who can disagree with you without fear of retaliation. Doris Kearns Goodwin

I generally, have received a lot of interests to join my team during my leadership roles at various past start-ups/unicorns like Goodhealth, Delhivery and now, currently at Amazon and I have helped my organizations to always strive to hire and mentor the talent, along with helping it to achieve the goal to be one of the best employers.

Talent is the multiplier. The more energy and attention you invest in it, the greater the yield. Markus Buckingham

Introduction — Why interviews are a good protocol for hiring?

So, with my journeys and experiences as a part of the hiring committees and thus, guiding and driving the hiring initiatives and the processes at different places at different levels with different capacities, interviews as a standard process for hiring across different Software Development roles feels the right protocol to me personally.

Given, a large applicant pool on top of resource constraints in terms of hiring panel and their time, standard interviews for hiring across different roles goes a long way to give the best experience to the applicants with the aim to standardize the way of selecting the talent without any bias, with a smaller number of false positives.

As an interviewer and also, the part of hiring committees, my goal through interviews always has been to hire the right talent first and not reject upfront due to any bias. The interviews focus on evaluating the applicant fitment with us and my organization’s principles, so that after hiring the candidate, I can help set them up on the path to success in my organization with the right mentor-ship and coaching as a leader.

Also, read my article on the right approach to software engineering .

An organization, no matter how well designed, is only as good as the people who live and work in it. Dee Hock

This document serves as an interview guide for technical engineering positions, specifically targeted towards Software Engineering roles. Before going through the other sections further, here is my small disclaimer.

Disclaimer : I currently, work as an Engineering Leader at Amazon and I am actively guiding my team to “ hire and develop the best ”, along with helping Amazon strive “ to be the Earth’s best employer ”. Do reach out for referrals to get a chance to be part of my team by sending me a dm .

Expectations — What are the expectations in the interview?

Based on your role, you will be expected to show those expectations required through the interview. The sections would be different across the interviews across different roles (for example, high level system design will not be relevant for junior SDEs), but the horizontals remain the same set of our core organizational culture and principles.

Let’s dive down into the expectations of the verticals of the technical engineering interviews.

1. Coding

The coding round focuses on time-bound problem solving and clean modular optimal code. The interviewer will ask a clear 1–2 problems in the 45 min interview along with asking on prior experiences to gauge your problem-solving approach and you will be expected to provide a clean optimal working code for the solution in your preferred language of choice and also, walk the interviewer through the solution and its space and time complexity analysis. It is important for you to cover all the edge cases, write test cases and even, evaluate any more optimal approaches.

The focus of this round is to test your problem-solving skills, which can also be learnt with practice and dedication, which is covered in the next section. Your dedication to learn the art of problem solving through efficient data structures and algorithms and then, using it to solve real world problems shows your perseverance and grit to learn and your curiosity to understand and solve hard technical problems.

2. Low level Design

The low-level design round focuses on checking your depth on how the code would be designed to solve a real-world design problem and your ability based on your coding experience to simplify and model a given real world problem. The interviewer will ask one or two partially ambiguous problem in the interview along with asking on prior experiences to gauge how you approach the problem using good design principles like — KISS, DRY, SOLID, OOPS design patterns (pre-made software blue prints like factory, adaptor, proxy etc) and you will be expected to provide a clean class structure, entities, their API interfaces and their encapsulated data and method and its coupling and interaction with other class entities or API interfaces to simulate the system and then, walk the interviewer through the solution.

The focus of this round is to test your understanding of how long-term maintainable code are written, which is mostly learned through good coding practices and experience.

3. High level System Design

The high-level system design round focuses on your ability to think at scale on how given an ambiguous problem statement, you will go ahead by gathering requirements — functional as well as non-functional and propose a system, which will scale big to solve that problem. The interviewer will ask one or two problems in the interview along with asking on prior experiences to gauge how you approach the problem using different tools and services around storage, network and compute while evaluating the system and resource constraints and trade-offs to design a large-scale system and then, walk the interviewer through the solution and even, be ready to show strength and commitment to justify and defend your design but also, the willingness and courage to incorporate any diverse idea or any other design the interviewer suggests.

The focus of this round is to test how you think at scale and your wisdom of how big systems are designed, built and scaled, which is mostly learned through experience.

Also, read my article on System Manifesto — the Wisdom for System Design, Philosophy of System Implementation and Principles for System Implementation based on my leanings and experiences of building large scale systems.

4. Behavioral

The Behavioral round focuses on your cultural fitment with the team and the organization based on your past experiences and projects working in different teams. The interviewer will ask multiple instances in the interview to gauge how you have behaved in different situations, what tasks you performed, what actions you took and what was the result, and they will be evaluated on whether they align with the right ethics and code of conduct aligning with the organization’s principles.

The focus of this round is to earn the trust of your interviewer and build their confidence that you will be able to fit in the culture and deliver the results.

Preparation — How to prepare for the interview?

The right preparation and a positive approach towards the interview will help you navigate the process and be part of the engineering organization, you are interviewing for.

Let’s dive down into the preparation of the verticals of the technical engineering interviews.

1. Coding

The coding round should be prepared by dedication to learn and be curious about the art of problem solving through data-structures and algorithms.

Here is a sample problem for this round:

Given a set S, write a program in your preferred language of choice to generate all subsets of it, i.e., find the power set of set S. A power set of any set S is the set of all subsets of S, including the empty set and S itselfFor example, if S is the set {x, y}, then the subsets of S are: {}, {x}, {y}, {x,y}Hence, the power set of S is {{}, {x}, {y}, {x, y}}, which should be the output of the program. Provide and cover all the test cases including null set and empty set...

These are the data-structures and algorithmic concepts, which are mostly covered and you should also learn them to apply in your daily tasks:

Space Time Complexity Arrays Maths Strings Binary Search Bit Manipulation Two Pointers Stacks and Queues Linked Lists Hashing Backtracking Heaps, Sets and Maps Trees Greedy Algorithm Dynamic Programming Graphs

These are the resources to learn from in their preparation:

Leetcode Geeksforgeeks Educative: Grokking the Coding Interview Designgurus: Grokking the Coding Interview Introduction to Algorithms book

These are the small curated resources, you should focus, if you are frugal on time:

Striver’s Sheet Grokking the Coding Interview Patterns Leetcode Patterns 2. Low level Design

The low-level design round should be prepared by learning deeply about different design patterns and utilizing them to design entities and classes to solve the problem.

Here is a sample problem for this round:

Design a shopping cart checkout system.Build a checkout system for a shop, which sells say, 2 products – Apples and Mangoes with the unit cost of an Apple as 1.5$, and a Mango as 1$.Design the cart checkout system, which can have multiple of these products and provides their order total. For example :2 Apple, 1 Mango = 4$Define all the relevant class entities for the inventory as well as cart and their methods and how they will be coupled and invoked. Also, provide mechanisms to add new products (say, banana) into the inventory and also, modify prices of the products.

These are the design patterns and principles, which are mostly covered and you should also learn them to apply in your daily tasks:

SOLID DRY & KISS Composition over Inheritance Code Smells, technical debts and refactoring Software Design Patterns Creational Patterns ( Factory , Singleton , Builder  etc.) Structural Patterns ( Decorator , Façade , Proxy , Adaptor  etc.) Behavioral Patterns ( Chain of Responsibility , Command , Observer , Strategy  etc.)

These are the resources to learn in low level design preparation:

Refactoring Guru Educative: Grokking the Object Oriented Design Interview Gang of Four Design Patterns book 3. High level System Design

The high level design round should be prepared by thinking at scale about how different large scale systems like pastebin, twitter, Facebook feed, search engines etc. are designed and learning from them to design such large scale system.

Here is a sample problem for this round:

Design a URL shortener service.Design a service, like bit.ly or tinyurl.com, that creates a short URL against the original long URL. When the user hits the short URL, they are redirected to the long URL against the shortened one.

These are the high-level system design concepts, which are mostly covered and you should also learn them to apply in your daily tasks:

Performance vs scalability Latency vs throughput Availability vs consistency CAP theorem CP — consistency and partition tolerance AP — availability and partition tolerance Consistency patterns   — Weak consistency vs Eventual consistency vs Strong consistency Availability patterns   — Fail-over and Replication Content delivery network  —  Push CDNs vs Pull CDNs Load balancer   — Active-passive vs Active-active , Layer 4 load balancing vs Layer 7 load balancing Scaling  —  Horizontal scaling vs Vertical Scaling Load balancer vs Reverse proxy (web server) Application layer   — Microservices Service discovery Database Relational database management system (RDBMS) Master-slave replication vs Master-master replication Federation , Sharding , Denormalization and SQL tuning NoSQL  —  Key-value store , Document store , Wide column store and Graph Database SQL vs NoSQL Cache   — Client caching , CDN caching , Web server caching , Database caching , Application caching Caching at the database query level vs Caching at the object level Updating the cache   — Cache-aside vs Write-through vs Write-behind (write-back) vs Refresh-ahead Asynchronism   — Message queues and Task queues Communication  —  Transmission control protocol (TCP) vs User datagram protocol (UDP) , Remote procedure call (RPC) vs Representational state transfer (REST) Security

These are the resources to dive deep into their preparation:

System Design Primer Educative : Grokking the System Design Interview Educative : Grokking the Advanced System Design Interview Designing Data Intensive Applications books System Design Interview books Volume I and II 4. Behavioral

The behavioral round should be prepared by going through the culture and principles of your prospective employer and building your narrative of your past experiences and projects working in different teams based on those principles and culture.

Here is a sample problem for this round:

Tell us about an instance when you had to work with incomplete data or information. How did you make your decisions then?

Here are Amazon leadership principles , which you should definitely go through, if you are applying to Amazon . Send me a dm for referrals to Amazon ;)

These are the resources to prepare for behavioral or hiring manager round:

STAR method interviews Educative : Grokking the Behavorial Interview Approach — How to approach the interview?

A positive approach towards the interview will keep you calm and focused during the interview and help you make it. As we are also trying to hire the next team-mate and based on your resume, you have been selected to be interviewed.

Simply, prepare well and be optimistic and positive during the interview.

Let’s dive down into the approach for the verticals of the technical engineering interviews.

1. CodingListen and try to understand the problem clearly.Ask relevant questions on the input and output to understand the program deliverable.Come up with other sample inputs outputs and verify with your interviewer to reinforce your understanding.Clearly communicate and work with your interviewer about your approach and thought process.Start with a solution — even, if brute force or sub-optimal and try to come up to an optimal approach by identifying sub-optimal bottlenecks.Once you and your interviewer agree on the approach, go ahead and provide a clean working implementation in the agreed programming language of choice.Cover the corner edge cases and also, come up with test cases and ensure all test cases pass either on through dry run or on the provided editor sandbox.Finally, provide the space and time complexity and justify it.In the end, don’t forget to ask inquisitive questions about the prospective organization, job role, the tasks or even, about the interviewer, if some time remains.2. Low level DesignListen and try to understand the problem clearly.Ask relevant questions to understand the use-cases, constraints and assumptions so as to resolve any ambiguity.Come up with the different entities, their entity class diagram, associations and their coupling and discuss it with the interviewer.Start with a solution — even, if not so clean and try to clean it up for maintainability and extensibility.Try to provide a UML diagram also —  Data Flow Diagram , Sequence Diagram , Class Diagram etc based on the problem statement and the requirements.Once you and your interviewer align on the design, go ahead and provide a clean working implementation in your object-oriented language of choice.Finally, justify your design using the standard design patterns and concepts like SOLID , Composition over Inheritance , Software Design Patterns  etc.In the end, don’t forget to ask inquisitive questions about the prospective organization, job role, the tasks or even, about the interviewer, if some time remains.3. High level DesignListen and try to understand the problem clearly.Ask relevant questions to resolve the ambiguity and gather the requirements.Outline the functional and non-functional requirements — features and system attributes of the problem statement.Start with traffic estimates in terms of throughput (Read/Write requests per second or Transactions per second ) for infrastructure capacity planning.Come up with the API contract and the logic behind the services.Use the interviewer provided design drawing tool and start with a rough high-level diagram for the system you are proposing (say, like this for URL shortener).Design core-components of the system and the conceptual schema in terms of database and API schema.Now, go ahead and scale the previous design by scaling the storage — databases, caches etc and scaling the compute by using load balancers or auto-scaling etc (say, like this for the URL shortener).Identify the possible bottlenecks, call them out and provide approaches to resolve them to optimize the system.Finally, justify your design choices and discuss the trade-offs with alternate designs, which the interviewer might suggest.In the end, don’t forget to ask inquisitive questions about the prospective organization, job role, the tasks or even, about the interviewer, if some time remains.4. BehavioralListen and understand the problem clearly before answering, preferably taking pauses to collect your thoughts coherently.Start by describing the situation using STAR methodology that you were in for the asked instance and the goal you had to achieve.Next, describe the tasks you did for that situation to achieve a specific goal.Then, describe the actions you took to address the situation with an appropriate amount of detail, focusing on YOU and YOUR contributions.Finally, take credit of the results based on the outcome of YOUR actions.Remember to be polite, honest, specific and most importantly, positive.In the end, don’t forget to ask inquisitive questions about the prospective organization, job role, the tasks or even, about the interviewer and their stories, if some time remains.Epilogue

Hope, you enjoyed going through the Technical Engineering Interview Guide.

Do reach out for referrals to get a chance to be part of my team at Amazon by sending me a dm . Feel free to go through our Amazon hiring FAQs and reach out to me or the recruiter for any further questions.

Looking forward to you giving your best on the day of the interview.

Good Luck!

[image error]

The Technical Engineering Interview Guide was originally published in Technopreneurial Treatises on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Right Approach to Software Engineering

So what really makes an engineer a Great Engineer?Prologue

Software Engineers sometimes, struggle with the understanding the strong integrity and the high standards of our trade and face multiple questions over the course of their engineering career.

Without right answers to those common questions and proper career mentorship, they feel dejected and eventually, give up on this noble trade to pursue business or other arts.

This article is a humble attempt to collate all the common problems and provide answers, guided by strong sense of integrity and high standards of this noble profession to guide the upcoming generation of software engineers.

Note that this will be a running document, which will be updated regularly based on new popping problems faced by the next upcoming generation of engineers, so that they can provide their best service to their organization, community and to themselves.

To give real service you must add something which cannot be bought or measured with money, and that is sincerity and integrity. Douglas Adams

ProblemsHow to learn to code and ship features as a recent college graduate?

Learning to code is like riding a bike.

You get on the bike, but you’re scared to put feet on the pedals because you might end up falling. You push the pedals forward, but then you fall over because you weren’t pedalling fast enough. To ride the bike, you need a leap of faith — you need to believe you can do it so you can start pedalling in earnest.

When you get a coding task, you don’t know how to solve it. But you need to believe you can solve it, so you don’t give up and say “this is beyond my abilities.” You need that leap of faith to stay in your seat and work towards a solution.

This faith isn’t something you’re born with. It’s something you earn. You earn trust in yourself by solving more and more problems, of larger and larger scope. And as you start trusting yourself, others learn to trust you.

What are the advice and approaches for me as a new software developer in the team?

It’s better to succeed together than to fail alone.

Example 1:

Ted was a junior engineer new to the team. Whenever Ted was stuck on something, he asked a senior engineer. Thanks to their help, Ted completed his projects well ahead of schedule. He also learned a lot from his peers, so he started asking for help less often, and became an expert in his domain.

Ned was also new. He was afraid to bother people, and wanted to look smart. So he saved all his questions for his weekly 1:1, if he asked them at all. He spent weeks being stuck on minor things, and shipped his first project much later than expected.

Who got the promo, Ted or Ned?

Example 2:

Jan was given a project. His manager said it was hard, and asked if he needed help with it. Jan said it was easy, that he could do it himself in 3 months.

Three months later, he hadn’t shipped anything. Despite being a solid coder, he had trouble getting his code reviewed, since no one else was working on the project with him. He also made a few design mistakes, since he was fairly junior, and no one helped with the design.

Next half, the project was given to Nan. Nan had ten years of experience and immediately asked for a team of three people. The team shipped in three months, with much glory and fanfare.

Guess who became the team’s tech lead?

The more you help people, the stronger you get.

Example 3:

Sam was gunning for a promo, and was laser-focused on shipping his projects. If someone asked him for help, he wouldn’t respond very quickly, since he was busy with his own stuff.

Sam shipped his projects with adequate speed, but spent a lot of time debugging. People didn’t really help him debug, and a lot of bugs came from code he didn’t know very well, since it wasn’t directly related to his project.

Pam had projects, but wanted to help other people ship their projects. She frequently helped other people find bugs in their work, and was the first to jump on issues that impacted production.

Every time she helped someone fix a bug, she learned about the system they were working on. She helped a lot of people, so she had knowledge of almost everything. Her projects didn’t take as long, because her knowledge helped her find bugs faster. She also had a lot of friends, which helped her ship code faster.

I’m not going to say “don’t be Sam.” Sam’s a fine engineer, every team needs a few Sams. But it’s better to be Pam.

What are the traits or skills required as a Good Software Engineer?

Be the computer.

Computers context-switch.

It runs Spotify in the background while waiting for you to move the mouse.

Great programmers write code while waiting for other code to be reviewed. If they are blocked on their first project, they ask for a second project.

Computers have a cache.

The most recent work it was doing goes into a special part of their memory, so that it can access it quickly next time it needs it.

Great programmers keep multiple projects in their mind at a time, so if they suddenly need to work on Project #3, they can start right away instead of trying to remember what they were doing.

Computers schedule tasks.

Many humans use the Last-In-First-Out method of scheduling — the task they do first is the task that was most recently given to them. The most efficient humans sort the tasks by priority and/or urgency, and work on the highest-priority tasks first.

Computers network.

It provides you the solution or what you are looking from other computer servers through the internet.

Many new programmers are afraid to ask questions or figure out the solution for their problems and just sit on the tasks. The right approach should be to seek out solutions locally within the team across peers/organization or even, globally in the developer community, say StackOverflow or Google and thus, build your own network.

Computers self-update.

Computers can update themselves with patches over the network.

The best programmers always keep learning, keep them up-to-date with the latest developments in technology, understand its merits and demerits and hence, know what tools to pick for what.

Computers have a nice user interface.

Programmers with good social skills are easier to interact with.

Evolve into supercomputers with more nodes and cores.

The programmers who are 10x are the ones, who have a large impact and they create those impacts by rallying other developers to initiatives, delegating them tasks, guiding and mentoring them, and providing them purpose. At this point, you are not just good but a 10x Great Software Engineer.

I want to become a 10x engineer, what should I do?

You become a 10x engineer by making ten engineers twice as productive. You unblock other engineers and help them fix their most difficult issues.

Examples

● The whole system is broken and no one can do any work. Every hour the system is broken is 10 wasted hours of engineering time. You fix the system in 1 hour. You are a 10x engineer.

● Your friend writes a diff with a bug in it. You review the code and find the bug before he puts it in production. If it had made it to production, it would have cost 5 hours of time to fix, but you found it in 15 minutes. You are a 20x engineer.

● Your friend would have spent three days fixing a bug. Instead, he asks you for help, and you proactively, solve it in 1 hour. Your 1 hour saved the other guy 24 business hours. You are a 24x engineer.

● Your team’s code has no unit tests. You add a bunch of unit tests to the code. Other people copy the style of your code, so soon there are hundreds of unit tests. Now bugs that took days to catch are being found immediately. You are a 50x engineer.

● Your friend is doing a project. You learn that someone else on another team is doing exactly the same thing. You take them both out for ice cream, and they find a way to work together. They save 3 months of development time. You are a 100x engineer.

● Your friend is unhappy and thinking about leaving the company. You coach him and talk him through his problems. He becomes happier and decides to stay. Replacing him and ramping up a new team member would have taken 6 months. You are a 500x engineer.

In tech, everyone is a software engineer but with a different x.

Team Leads/Architects/Engineering Managers also have different and higher levels of X impact and responsibility.

I want to mentor other engineers as a senior engineer, what should I do?

1. Giving the mentees tasks that are very well-documented. It should be clear which part of the code they should change, and how they should test their changes. Ideally, you can link to an example diff where you’ve documented how you tested your change.

2. Introducing them to other people on the team or organization and telling them what each person is working on. Usually, new hires are self-conscious about bugging one person too much, so if they have three or four “friends” they will load balance their questions. It also helps them feel welcome on the team.

3. Important, Never directly solving problems for them. When a mentee brings you an issue, the expert’s natural reaction is to fix the bug for them. But it’s much more educational if you tell them how you would fix the bug so that they know how to do it themselves in the future.

Situation 1:

Mentee: “I don’t think I have access to this service.”

Bad mentor: “Sorry to hear that, let me send an email to IT and get that sorted out for you.”

Good mentor: “IT is in charge of this, can you send an email to […] asking for permissions?Thanks!”

Situation 2:

Mentee: “I’m lost, can you help me debug my code?”

Bad mentor: “Sure thing, can you send me your code? (2 hours later) Okay I found your issue, you were doing X but you should do Y instead.”

Good mentor: “What have you tried so far? Have you tried running the code locally and going through it with a debugger? OMG you’re gonna love this, debuggers are the bees’ knees. Here’s the wiki about how to set up the debugger and run our service locally — let me know what you find!”

There is a very thin line between hand-holding and spoon-feeding. Spoon feed an infant, but hand hold an adult.

I have been asked to own/fix bad code or migrate bad systems of others, what should I do?

As soon as Jane joined my team, she was assigned the messiest part of our codebase. It wasn’t actively maintained, no one on our team understood it, and there was almost no documentation. Jane didn’t complain about this. She fixed things.

She cleaned up unused code paths. She added unit tests. She removed old experiment code that hadn’t been touched in years. She documented the whole system and became the local expert on that code. Now the code is better because she made it better.

Do you want to be Jane, or do you want to sit around complaining about bad documentation? I know which person I would rather have as my teammate.

Always follow the boy scout rule:

Always leave the campground cleaner than you found it.

If you find a mess on the ground, you clean it up regardless of who might have made it. You intentionally improve the environment for the next group of campers.

I am constantly questioned a lot on my decisions as a lead or senior, what should I do?

Just yesterday, I proposed an idea, and Very Talented Victor weighed in on it.

Victor: “Is this the right approach? Do you think we should adjust X instead?”

Me: “That’s a good thought. Let me run another analysis, and check if it’s X or Y that makes the difference.”

After running the queries, I saw something super interesting in the plots. With the new plots, my idea became a lot more compelling!

When I presented the idea at the team meeting, people were way more interested than they were before — all because I learned from Victor’s feedback.

Always encourage questions. Even stupid ones.

You may learn that you’re going about your project in the wrong way, and now you have the chance to correct it.You learn what’s important to other people. That teaches you how to explain and motivate your projects, and what are the most important parts to prioritize.You get to learn about all the potential issues in advance, so your ideas are airtight when you go to implement them. If you can’t explain to Victor why your decision is correct, are you really confident enough to invest time implementing that decision?You learn how to correctly answer the question when someone else asks you that question in the future. If you crunch the data when Victor asks the question, you’ll have it ready when your skip manager asks you the same question later, and then he’ll be impressed by how well-prepared you are.I just want to do individual contributions in remote, do I even need other people to be productive?

Here’s a secret:

You can’t be productive without other people.

As an engineer, you are judged by your code. But what code you can write depends on who is supporting you.At most companies, you can’t write any code unless someone reviews your code and signs off on it.And you will write code much faster if you have people to help you and explain things to you.As you grow, you will tackle larger and larger projects, ones that require collaboration between multiple people. Those projects get done a lot faster if people enjoy working on them.

It’s hard to be a great engineer if you don’t gel well in the team.

So what really matters as a Great Engineer?

The Attitude.

Consider three engineers: Jim, John, and Jane.

Jim comes to work at 11:30 and leaves at 4:30. He doesn’t care much about his job, so he writes just enough code to avoid getting fired. The code he does write is sloppily hacked together and poorly tested. He never writes documentation, because that would be too much effort. When he goes on-call, he ignores most alerts, because they’re probably not important anyway.

John is very ambitious, and really wants to do a good job, so he can get promoted. In fact, he refuses to work on any project that won’t get him promoted, and tells his manager to give those projects to other teammates. When John gets assigned a task that won’t get him promoted, he usually ignores it, or gives it to someone else.

John is fairly senior, so junior engineers often seek out his expertise. When someone asks John for help, he first evaluates how important the person is. If the person isn’t going to write him peer feedback, John is too busy to reply to their messages.

Jane just graduated college, and hasn’t built a lot of software in the past. But she cares deeply about the quality of her work. Her code is impeccably tested, and flush with comments. She didn’t know what a move constructor was, or how to declare a variable “const”, but she quickly picked that up in her first few code reviews.

Jane is happy to work on any project her manager assigns her. She figures if the manager gives her a project, that must be what’s best for the team. Sometimes Jane is given tasks that belong to other teams and takes those tasks as seriously as her own engineering work (because other teams are doing important things too).

When other engineers ask Jane questions, she sits with them for twenty or thirty minutes and helps them debug their issue, even if she doesn’t know the answer off the top of her head.

Be Jane. Don’t be John or Jim.

Being a great engineer is all about having the right attitude.

Epilogue

So, to succeed as a software engineer, all it takes is the right attitude of sincerity and integrity towards the service, not a moonshot. After all, software engineers are indeed, artists but with more responsibility towards their organization, community and to themselves with this gift.

Remember, Software Engineering is a disciplined art, so let’s create some large scale masterpieces.

Reference

This article is a curation and rewrite of Stanford University co-alum Jessica Su’s Quora answers and discussions, later drafted after her due permission by Jayanth Kumar.

[image error]

The Right Approach to Software Engineering was originally published in Technopreneurial Treatises on Medium, where people are continuing the conversation by highlighting and responding to this story.