Good at Leetcode, and I now want to get good at software engineering!!

Hey! Thanks for your questions!

I'm glad the Leetcode hustle has been positive for you and congrats on passing through those interviews. As you observed, leetcode =/= software engineering. It's one of the ways for interviewers to evaluate your problem solving skills (I personally think the system is broken, but not hating the players)

Here's what I would recommend someone just starting out:

1. Be solid on your fundamentals of your programming language. Know your syntax, loops, if-statements, most-used library functions, good naming conventions, etc.
2. Brush up on data structures and common algorithm patterns. You probably got this covered but having good intuition of these is very helpful when writing code.
3. Write good tests. Learn to test your code in a holistic manner. Cover happy path. Do isolated tests. Look up test-driven development.
4. Organize your code well. There are many ways to organize your code. Pick a file structure and code structure. I like to organize my files by relevancy rather than file type.
5. Practice problem solving. Console log debugging. Rubber duck debugging. Test your assumptions. Use StackOverflow, Google, ChatGPT, etc. Tailor and refine your questions. Process of elimination to get to root cause asap (this really comes with experience).

As for 'understanding complex systems', it depends on your learning style. What is most effective to help you learn? For me, it has to be interactive or project-based. Maybe the Feynman Technique would be helpful for you.

Those are some specifics that helped me when I was just starting out. It's an iterative process rather than a linear one like what you're asking for but I hope it helps.

We can dive deeper into each of these and come up with a solid plan together.

Good luck!

"Any concrete suggested steps will be great instead of just some general bullet points." I will try my best to give detailed and actionable bullet points 😅.

1. Do a lot of reps – take your assigned tickets, open PRs, get PRs reviewed, address PR feedback, and merge them. If you find yourself finishing more assigned tickets for the sprint, ask your manager/lead for more tickets. Go beyond of what is "expected".
2. Get PR feedback from high quality PR reviewers – Not all reviewers are the same – some people are excellent reviewers and if they see that you are open to learn and iterate quickly based on feedback, then it increases the likelihood that they would want to continue reviewing your work.
3. Creep/study other people's PRs – ask your manager, other members on your team, who writes high quality code and in what areas – look at their PRs, study them, ask questions, understand their decision making.

Outside Of The Job

Even if you're interviewing, try finding time to build side projects. Here's some good resources to help with that:

• [Masterclass] How To Come Up With 100k+ Users App Ideas You Can Build For Free
• [Masterclass] How To Build And Grow Tech Products To 500k+ Users For Free
• "How to Learn/Practice Clean Code, particularly by oneself?"

If You Have A Job

Ask lots of great questions, be a feedback sponge, and embrace discomfort facing situations you're unfamiliar with (this is where learning is maximized). Here's some good resources for this:

• [Masterclass] How To Learn Quickly In Tech
• [Masterclass] How To Succeed At A New Team Or Company As A Software Engineer
• "What are software engineering fundamentals?"

This is a great question and what Taro helps with! (If you don't feel more confident after reading through Taro discussions, attending the live events, and chatting with us directly, ping me for a refund!)

• Study the code review process at your company. Learn from high quality PRs, and incorporate feedback from poor PRs into your own code. 
• Build real programs. That means you should actually run the app or service, and print statements, and understand the code flow. This will feel different from solving programming puzzles, and that's ok. 
• Talk to people on your team and adjacent teams. Take advantage of being the new person and schedule 1:1s with everyone on the team and learn what they work on (and what challenges they face).
• Figure out what your team and company care about. You could spend the next 6 months increasing test coverage from 60% to 90%, but does anyone actually care? This is not strictly about software engineering fundamentals, but if you work on things that people care about, you'll get more feedback which will help you get fundamentally better.

Since you're a junior engineer, I recommend these resources as well:

• [Masterclass] How To Write Better Code Faster As A Software Engineer
• "What are some tips for quick growth when you're just starting out?"
• "What does it mean to not require handholding anymore?"

You're well set up to learn well at a prestigious Big Tech company like Amazon. As long as you're communicating well and thoughtful with everything you do (especially code quality), you'll be well on your way to SDE 2!

Here's a good discussion around mid-level engineer expectations as well: "What does a competent mid-level software engineer look like?"