I've been doing regular mentorship sessions on ADPList for a bit now and a lot of common topics and questions have been coming up, that I kept record of.
Also, being in an educator role for a while, very similar conversations come up on a daily basis.
The purpose of this repo is simple - to help me remember and organize these conversations and provide some insights to a larger audience.
With time I will continue to expand and refine this advice, with the goal of making it more accurate and practical.
Topics are going to be pretty general and varied: learning effectively, mindset, job search, interview process, staying relevant, and many more.
While some of this advice is, hopefully, universally applicable, I mostly share my experience as a Full-Stack JS Developer, so a lot of advice is provided through that lens.
- If you're just starting your developer journey or want suggestions for guided learning paths, here are some of the programs that will provide you with more structure:
- These are in no particular order and the reason they made the list is trivial in a best way - they all came up in a positive way in several conversations.
- For a great overview of very detailed breakdown of all concepts needed for Front-End Development (with a ton of helpful deep dive links), highly recommend the Front-End Handbook from Frontend Masters.
-
When learning to program, you are not just learning a particular programming language or syntax. You are learning how to think programmatically - the ability to break bigger problem down into small problems and work out the solution for it step by step.
- This makes it extra tough at first because you are learning two complex skills at the same time.
- But this also makes you be able to learn other programming languages down the road more approachable, as they'd be using a lot of very similar concepts.
- Be patient with yourself. Don't get too wrapped up in expectations of how long it "should" take you to learn something. Take your time, it takes time to internalize these complex concepts.
- Excellent article on how to learn stuff quickly.
-
It can be helpful to figure out learning method that works best for you, but don't be afraid to switch it up based on the context or complexity. You might want to start with a video for crash course but get into text content or interactive tutorial for deeper understanding.
-
Reading documentation can be overwhelming at first, but it's often the best resource to understand a language, library or framework. What you are looking for in terms of being effective at it, is being able to skim through the content to find the parts relevant to you, rather than having to read the whole page. At first it can be very hard, but with practice you will get better at it.
-
Googling for help can be intimidating and frustrating. How do you know what to search for? The answer is that at first you don’t know what to search for, so you take an initial naive "seed" query and continuously refine it as you discover repeated terms.
-
Watching someone else code is terrible for retaining information. Whenever you go through lectures, tutorials, getting started docs or demos, always take notes or better yet write out the code yourself. Don't wait to apply concepts, always practice everything you learn immediately.
-
If you've just completed a bootcamp, a guided course or any other type of organized content, it will always pay off to review existing content, examples and demo code and get deeper understanding of it.
-
Learn satellite technologies instead of net new. Don't spread yourself too thin trying to learn everything under the sun at first, especially if it's not immediately usable; it will soon be forgotten.
- For example if you are a React developer you could look into TypeScript, NextJS, React Query, GraphQL, tRPC; things you can use to expand and improve your existing projects.
-
Learning fundamentals deeper will always be a better bet than learning yet another technology on a surface level.
-
Best way to learn is to build things, not watch other people build things, aka Tutorial Hell.
-
Everyone gets stuck in "tutorial hell" once in a while. While you gotta learn from somewhere, make sure you do more of writing code yourself than watching other people code. You can make every tutorial project your own by changing it up, having your own data-set or entities or adding your own features.
-
Using AI tools (ie: ChatGPT, GitHub Copilot) can be a double edged sword.
- While AI can generate code for you easily (ie: boilerplate, new feature, a chunk of functionality) it is not the expert, you are. It is important that you apply your own critical judgement to the quality of that code and tweak it to your needs.
- Crucial to the previous point, understanding fundamentals, the why and how of the code isn't something AI will replace. It is especially important for new developers to build solid fundamentals, learn to think critically and understand how to hand craft their code before using tools that help with that.
- Thinking of AI as just another tool is a good way to approach it. You need to apply judgement on when it's beneficial to you and when you are using it to your own detriment. Often doing things harder more manual way pays off in knowledge dividends.
- There are many great use cases for it of course!
- Using it as a tutor (ie: "explain this concept to me")
- Using it as a debugger for broken code (ie: "what's wrong with this code"). Important note - make sure you understand what was broken about that code once fixed, and make a mental note for the future.
- Asking it to refactor your own code. Same note - evaluate the changes, assess why might they be better, why you wrote your code differently, is there a more readable version somewhere in the middle.
- Long term thinking living in the post-AI world requires us to be smart about skills we acquire.
- Generative AI is truly a jack of all trades: good knowledge on everything, but the best on nothing.
- Knowing that these tools are here to stay, you will benefit from becoming a domain expert - having deep knowldge in your area of interest but striving to be a generalizing specialist
-
Don't be afraid to "break stuff". That's where a lot of learning happens. Don't be precious about your code, learn from error messages, re-write your stuff when it starts to get messy; no one writes perfect code on the first try.
-
Building projects can be approached in two ways:
- creating a product and picking technology that will serve the requirements well
- or starting with technology that you want to learn and coming up with simple example that you can continue expanding on as you are learning the new concept.
- At the end of the day a lot of us are developers first and foremost. We are not expected to come up with amazing product ideas; we are expected to solve problems with technology.
- There are also platforms like Frontend Mentor that can help you with the project ideas, that you can also get feedback on as well as practice code reivews yourself.
-
It's a good idea to "build in public", especially if you love writing and if not, that's a good opportunity to improve your communication skills. What "build in public" means is keeping progress of your learning and project work, be it through a blog, twitter, videos or other medium. There are couple of benefits:
- Explaining your thought process and breaking down technical aspects are a very important skill set to build.
- Keeping a record of challenges you face and your solutions allows you to easily go back and find it in the future if you ever run into a similar issue. And we all usually do.
- It's another way to build your personal brand, show your passion for the field and be noticed by a potential employer or simply to network and grow.
-
Familiarity with cloud (cloud functions, edge, AWS services ie: S3, deployment (CD, CI)) would be a good thing to add to your resume and generally understand on a very high level, but it also isn't an expectation for junior developers to be DevOps engineers.
-
Start familiarizing yourself with higher level of software development cycle.
- Most likely a lot of this stuff won't make sense at first, that is OK. You can always come back to it regularly to gain a better understanding.
- Best way to learn about clean and efficient code isn't to hear someone else tell you what it looks like but rather for you to understand where you could improve it by realizing how certain things you wrote might not be ideal.
- This is where coming back to these books or resources will pay off; with time you will recognize the things these resources talk about based on the experience you've had yourself.
-
Embrace the concept of T-shaped learning.
- Also known as specialized generalist.
- Pretty simple idea in essence: become an expert in your field of interest, the T vertical (eg: Front-End) but also know enough about other aspects of development to be able to hold the conversation or understand what other devs are talking about very high level, the T horizontal (eg: DBs, DevOps, Cloud).
-
Understanding how to write code that will scale is important, so a couple of larger continuous projects are a good to have rather than only lots of proof-of-concept projects. One of the biggest challenges faced by new developers is working with large codebases; do anything you can to mimic working on a "real project".
-
Couple of other ways to make your projects closer to real work environment:
- Build projects collaboratively with other developers or UX designers.
- Great platforms to help you find collaborators are Co.Lab and Collab Lab
- Build projects using agile methodology with GitHub projects or Trello.
- Recreate dribbble sites or any popular applications.
- Ask your immediate network for any work they might need help with; this will count for "real projects", as you are doing freelancing. Even if they don't need a "real" site, that can spark inspiration for a project that will be solving a real need.
- Build projects collaboratively with other developers or UX designers.
-
Practice regularly and efficiently.
- Learning new things or working on projects every day for a small amount of time is better than once a week for a larger chunk of time. Time adds up, but the regular practice compounds.
- Doing things you are comfortable with repeatedly isn't gonna bring much learning (though refreshing and solidifying concepts once in a while is good for muscle memory). Growth mindset might be a controversial topic, but learning on the edge of your comfort zone is a powerful tool. If you feel like you barely understand something you are trying to grasp, that's a good place to be, push through that.
-
Participate in Hackathons: you meet new people and network, you practice learning and applying something new quickly, and you might even win some prizes or clout.
- Hackathons are also something that's really great to bring up during the interviews. They are fun to talk about from a technical/learnings perspective and a lot of people wish they had time for hackathons so they get to live vicariously through you. Positive emotions during interview never hurt.
- Ensure your GitHub profile and repository pages are well organized and documented. Show off your best projects using Pinned Repositories functionality. Quality always trumps quantity. You have a very limited amount of time to leave an impression on a potential recruiter, so do your best job to have your profile and projects speak for themselves.
-
Leverage LinkedIn and platforms like ADPList to connect with people. Attend local meetups and join tech groups.
- You never know who you will connect with to help you find the job.
- Don't even ask about jobs or if they are hiring, show interest in what they or their company do, what advice they have for looking for jobs or what they look for when they are hiring.
- As a nice side effect, connecting with people can always lead to them thinking of you when their company is hiring.
-
Additional to obvious job platforms like LinkedIn (which might, at times, have 100+ applicants for one role), consider looking for VC firms websites and look at their own job boards for earlier stage startups.
-
Glassdoor Community can be a great way to get some insights on the industry, as well as ask for specific help with resume / job search / etc.
-
For your resume and LinkedIn, where possible, include action verbs and quantify your responsibilities.
- Stick to a single page resume, simply styled.
- Proof read your resume several times for grammar, spelling, wording and correct technology names.
- Do not get tempted to list every possible skill you might have touched without being able to provide proof to your experience and expertise.
- When describing your experience, avoid wordiness or fluff words, be concise. Stick to one line bullets below each job title.
- Have several people look over your resume to provide some feedback or catch mistakes.
- Optimize your resume for 10-30 second viewership.
- Test your resume for Applicant Tracking Software performance.
-
After you've applied to a position, consider following up with LinkedIn message or email to company hiring manager or CEO.
- Things you can touch on in the message: re-iterate that you've applied for the role, why you think you could be a good fit for the role and explain why you're interested in the company.
- Isn't it too much or too desperate?
- Majority of applicants are less likely to do this, so this makes you stand out for going the extra step to follow up on why you are the person they should hire.
- This shows you've done your research, and are committed to go the extra step to help the recruiting manager find the right person for the job.
-
You should practice whiteboarding questions and technical questions, but that should be a smaller ratio compared to building things.
- LeetCode easy questions are often more than enough for a good chunk of jobs.
- If you need to get more in-depth with Data Structures and Algorithms, you'll know. There are specific companies that look for that. Tip here is to ask or research ahead of time what kind of technical interview process a particular company uses.
- Remember that technical interviews are all about communication, not just solving the challenge. Interviewers are looking into how you think and communicate about your problem solving, not necessarily getting the perfect answer.
- Be comfortable talking about technical concept questions:
-
Soft skills (clear communication skills, presentation skills, team work, patience and compassion, professionalism, simply being a person people want to work with) is just as important if not more so than technical skills.
-
We don't always get the choice on where and what we work on but think about the things you like and enjoy, the passion shows when you work on things you truly love. It doesn't even have to be technical, you never know what you can connect over and that can be a deciding decision for hiring team or for you choosing the company to work for.
-
You are going to get a lot of job application rejections and even more silence. Don't just mass apply but also don't hesitate to apply for positions that ask for a laundry list of technologies, if you feel like you know majority of it. It's a known inside joke in the industry that all junior positions require 3-5 years of experience. Apply anyway. Try to not take things personally and get discouraged.
- Consistency is important, make sure to create a daily structure for yourself to apply to X number of positions, search for new roles, reach out to people, etc. Don't be hard on yourself if you don't hit your goals, and celebrate the wins when you complete some of the set out tasks
- Not all positions are created equally, so try to customize your application package as well, ie: resume, experience, cover letter, tech skills. Also while "Easy Apply" on LinkedIn can be tempting, don't hesitate to check out careers page on company website directly as that can help you apply with more personalized approach.
- You might want to consider having a "low effort" and "high effort" split in your applications. Jobs you are most interested in, dedicate plenty of time to apply with utmost care. Positions that are "nice enough", but you still might wanna apply, you might want to do the quickest version of the application.
- Consider creating a job search spreadsheet (feel free to Google for template that fits your needs) to keep track of the process. Organization is key!
-
Consider applying for positions in tech companies that are not necessarily dev positions, but can get your foot in the door and you can then pivot later. Some examples are QA Testing, Technical Support, Data Engineering or Analytics, Technical Writing, CMS Authoring, Email Development.
-
Someone else's dream job is not guaranteed to be your dream job. We all find meaning in different things, at different parts of our life. Find what it is that fulfills you and gives you meaning at this point of your career and seek that out. Also, remember, that it is still just a job, it's OK to love it, it's OK to love things outside of your job that your job affords you.
-
Prepare yourself for the interview as much as you can.
- Be prepared for common interview questions; think of the examples from your career ahead of time, so you're not caught off guard in the interview.
- Do some research on the company you are applying to. What is their mission? What are their values? What does their product do or what are their services?
- What does their interview process look like? Google or Glassdoor can help with that, but don't hesitate to ask your recruiter for details on how you can prepare the best. That's only gonna work in your favour.
- Come prepared with some questions to ask back. "Do you have any questions for us?" is not an optional interview question; show your interest, preparation and forethought.
-
Recruiting is expensive. It's in recruiters' interest to hire someone as soon as possible.
- They are on your team, not working against you. Leverage that. Help them help you by asking the questions and being curious and open about the process.
- If you are getting weird vibes about the interview process you are likely dodging a bullet anyway.
-
Employers look for coachability, personality and drive not just technical skills, especially for junior roles.
- From interviewers perspective, it's not realistic to expect new developers to be experts in a lot of things. To be able to perfectly use the right terminology. To have in-depth knowledge of architecture and scale.
- What they want to see is your willingness to learn, curiosity and passion about the field, ability to admit when you don't know something, following up on those things you don't know answers to.
- Treat interviews as a two-way conversation, be curious, have follow up questions, don't be afraid to show off your personality. Simply enjoying the process of the interview and showing that you are happy to be there and engage fully is a huge green flag for the interviewer.
-
Practice talking about the projects you've done effectively.
- One of the biggest interview challenges for junior devs is to put the work you've done into context. Take the time to reflect on your school or self-guided work and distill some learnings and takeaways from that work.
- Practice talking about your work in technical terms.
- Practice breaking the project down and explaining it in non-technical terms.
- Practice talking about challenges and learnings of the projects.
-
Behavioural interviews are not just to confirm that you're not a crazy person.
- Companies look for insight your communication skills and you being able to talk about your work experiences and distilling the outcomes from them
- A good reference point is Amazon's Leadership Principles; prepare 1 or 2 stories for each of these principles to talk about. If you are missing any, that's an excellent growth and learning opportunity, work on it.
-
Take time regularly to reflect on what you've accomplished so far instead of being overwhelmed with all the things you still need to learn.
- No one knows or will know everything, try to find your focus.
- We get de-sensitized and used to all the positive things, they stop feeling special and comforting. It needs to be a conscious effort to remind ourselves of things we are grateful for which includes all the knowledge and experience we acquired. Negative stuff is natural to us, but it doesn't mean it's always right.
-
It's important to keep in mind the bigger picture of the code. A good way to progress in your career is to understand other parts of the business, what other departments do, how engineering department fits into it all, being able to communicate technical decisions with non technical people. How can you help the company grow with your skills? Who are your customers?
-
Eat well, sleep well, stay hydrated, avoid caffeine late in the day, go for walks. Your brain is your main tool, take care of yourself first and foremost. There is no shortcut to productivity but feeling rested and content sets the theme for the day.
-
Make time for hobbies. The ones that grow you as a human, the ones that make you happy, the ones that you are embarassed to admit but that make you get out of the bed early on the weekend. And everything in between. Growing as a person will make you a better developer too. How cool is that. And being slightly happier because of that is not a bad side effect.
-
It's ok to code a lot and it's ok not to.
- When you are first starting out you should definitely try to be in the former camp.
- However, that is not the expectation for the rest of your career that you have to live and breathe code to be a "real developer".
- Continuous learning is paramount, but just because you might not feel like coding after full time work or you're not as "passionate" as people who love coding 24/7 does not make any less of a developer. Don't let any external definition of "real developer" make you question yourself and your goals.
-
Don't compare yourself to others.
- Comparison is a thief of joy as they say. It's irrelevant and unproductive, you are probably just concentrating on the highlight of one person's current snapshot of where they are without seeing their whole journey.
- It's your personal journey, with your own timeline and challenges. Besides, there is no finish line, but just continuous learning.
- Enjoy the process of bettering yourself and a healthy version of comparison is to compare your today self with the yesterday self.
- It's hard to stop yourself from feeling overwhelmed, jealous, incompetent, etc. But you can practice chanelling these feelings into something more productive: inspiration, curiosity, enjoying the process of learning new things, finding focus, contributing to other people's growth and success, etc.
-
Don't think of your career as a straight line. Instead, use The Tarzan Method.
- It's good to think about your ultimate destination (short or long term), but the path to get there won't be immediately clear and that is OK. Consider what career move is right for you at any given time and swing to it. The cool thing is that it'll ensure you'll be on the path that is unique to you. You will find out what really matters to you.
- To quote the article, "You may find that you love a particular type of work, or a particular type of company, or a particular technology. You may find yourself trying a role that you hadn't originally considered... You may find that you love smaller start-ups rather than big enterprises, or perhaps the other way around."