From Amazon Internship to Full-time : Learnings and suggestions

·

6 min read

Cross-posted to sbvkrishna.tech/from-internship-to-full-tim..

Having went through the path of transitioning from a Software Engineering Intern to Full-time Software Engineer at Amazon, below are some of the learnings that I can share from my experience. Note that these are based on what I've experienced in my journey and might have things specific to Amazon or my team, but the core learnings/suggestions should be applicable for any Software Engineering internship.

  • Document everything you do. This will help you track the progress in your projects and in gathering the data points required to support your full-time conversion. (At Amazon, Interns have to write a ~5 pager doc at the end of the Internship, detailing the work, the challenges faced and the learnings using STAR format. This doc will reflect your performance and the ability to work as full-time engineer, which will be reviewed by your manager and a Bar Raiser to decide on giving the return offer).
  • Follow the company core principles and their culture. For instance, Amazon has Leadership Principles which define their culture and employees' long term success.
  • Follow Industry/company standard coding practices/guidelines and best practices. Ask your team for any team guidelines they adhere to when doing Code Reviews (template format, Testing required), Design Docs, etc.
  • When in doubt, reach out to your team for help but do your own research first. You don’t want to come off as someone who always relies on others for every small thing. When asking for help, try to follow something like "Hey teammate, I am trying to accomplish task A, but facing issue B. I tried finding the possible solution from the internet (or some internal portal) and tried fix C (or workaround D), but they didn't resolve the issue. Could you please help me resolve this?"

  • Be honest about things you know and don’t know. If you bluff, you’ll get caught and it will leave a bad impression. Remember, Trust is a fragile thing -- hard to earn, easy to lose.

  • Come up with your approach/design solutions first: Before you approach your mentor or any other teammate regarding a problem you’re trying to solve, come up with a couple of your own solutions and discuss them. Don’t just go and ask, “How do I do this?”. Of course, if it is related to an internal tool or some setup, you can directly ask for help.
  • Get the code reviewed regularly -by your mentor and/or other teammates. You might see ton of comments on your code during code reviews early on. As long as you don't repeat the same mistakes again and are learning over time, you don't need to question your capabilities. Use code reviews as an opportunity to learn new things and feel free to share/put forward your opinions.

Butterfly_man_meme_about_feeling_attacked_by_code_reviewers-300x300.jpg

  • Try to improve from feedback- be it in code reviews or in person. When you get feedback (negative or positive whatever), always take it positively. You could consult your mentor or manager on how your performance will be evaluated. They will surely help you understand your responsibilities and deliverables. They are here to support you and help you grow.

  • Talk to your mentor frequently. Don’t bother him with every little detail but provide substantial updates about your progress. Learn about the team, the projects everyone is involved in and participate in team building activities. This is even more important for remote internships.

  • Talk to your manager every other week: Ask if you’re doing well. Ask what their expectations are. Ask if they would like you to take additional responsibilities. Don’t be quiet and wait for the final review. And as I mentioned earlier, always take feedback positively.
  • Participate in daily stand-ups and sprint plannings: This may be tricky since you’re new and have no clue about what everyone is talking. But, don’t ever say, “No updates”. Point out even little things you did; for example, “Had a discussion with my manager about the progress of our project and 'fill in the outcome here'.” If you find something interesting that someone said but didn’t understand, grab them for a coffee or during side-bars to learn more about it.
  • Address code reviews carefully: Your code can be reviewed by a couple of people in or outside of your team. Make sure you’re addressing each of the reviewer’s comment and/or replying to the comments stating why you didn’t address it. There may be conflicting reviews from different people; don’t ignore them but maturely ask your mentor how to handle such cases.

r_1205476_UFofK.jpg

  • Try to ship as much code possible and let your work speak for you. All the tasks/projects I was assigned to was in production before the end of my internship. Take the ownership of your deliverables. you won’t have any difficulty in supporting your conversion to full-time at the end of the internship.

Useful tools/technologies to learn

These are few things that can help you deliver and start making contributions faster in the internship. Particularly helpful for short duration internships where you are expected to deliver a complete project in a very short period of time.

  • Learn Git

  • Become familiar with your terminal/shell

  • Learn Cloud computing (depending on the role and domain you would be working on)

    • What is cloud computing, the types of cloud computing (IaaS, PaaS, SaaS)
    • For AWS for instance, have an idea on what each of the core services do and when/where to use them - SQS, SNS, DynamoDB, RDS, Cloudwatch, S3, Kinesis, VPC, EC2, Load balancing & Autoscaling -- few popular AWS services to name.
  • Don't write code which looks like shit. 0_Ak-hWgbRp2RSD8iM.png

    • Learn SOLID principles and OOPS concepts (must!).
    • Write extensible and modular code with separation of concerns.
    • Learn coding best practices and common Design patterns.

    • Look into Refactoring code.
  • Learn Language specific nuances: Become comfortable with built-in libraries, Exception Handling, Multithreading and concurrency.

    • Java: Lombok, JUnit & Mockito for tests, Guice/Spring for DI, Log4J for logging, Maven/Gradle for building.

Further reading


Other references or credits


Questions?

  • Feel free to reach out to me on LinkedIn - sbvkrishna or at email saladibalavijayakrishna[at]gmail[dot]com

Disclaimer: Views expressed are my own and do not reflect the views of my employer (so please don’t come after me with a flamethrower if these conflict your views).