The Ultimate Guide

Sign up here to be emailed when new content is released!

Getting Started

The Application Process

Preparing For Interviews

  • What To Expect When You’re Interviewing
  • Preparing For Algorithmic Interviews
  • Preparing For Technical Interviews
  • Preparing For Behavioral Interviews
  • Tips For Algorithmic Interviews
  • So You’ve Flunked Your Interview

Succeeding At Your Internship


  • Getting in Touch With the Larger Online Tech Community

Preparing Your Tech Application

Before applying for an internship, it’s important to have an application that will make a hiring manager take note of it. Below are some guidelines for things that you should take care of to maximize the chance of recruiters being interested in you.


It continually astonishes me how little time students spend crafting and revising their resumes. Your resume is what represents you to a recruiter and 100% controls how you’ll be perceived. A recruiter or hiring manager will take a five-to-ten-second glance at your resume and make a snap decision whether to put your resume in the garbage or the “first round of interviews” pile.

If you’re in college, career services can help you put together an effective resume, especially if you don’t have much experience to write about. However, often career services aren’t used to how things work in the tech industry, which is why it’s always a good idea to ask someone in the tech industry to look over your resume to make sure it portrays you in a good light, doesn’t contain any accidental red flags, and includs everything that it should.

Before submitting your resume to positions, pretend you’re a recruiter and take a look at your resume. Think: If I was a manager looking to hire someone, would I want to hire this person? What would convince me that this person was worth hiring?

Side Projects

  • Side projects should be prominently featured on your resume, and are especially crucial if you don’t have experience. They are a great way to convince employers that you can write code and use tools and frameworks. Your side projects should be hosted on GitHub, and your GitHub profile should be on your resume.
  • A great way to start is to repurpose projects you’ve done for school; just be sure that it’s not obvious that the project was a school project. If you don’t have school projects or want to work on other projects, the world is your oyster! Create a website, game, browser extension, or whatever else your heart desires. Besides for resume value, hacking is a great way to learn about the great tech ecosystem and how to use tools and languages in a practical way.

Online Presence

If your resume passes muster, chances are a recruiter or hiring manager will Google you. It’s important make sure they’ll be impressed with what they find.

First, a challenge: Google your name. Do it right now. If there are many people with your name, try your name + location or your name + university. What did you find?

  • Social Media
    Is your Facebook or Twitter on the first page of Google? Does it contain overtly political or religious messaging, or pictures of you drinking or smoking marijuana or acting generally unprofessional? If so, you don’t want hiring managers to see it. You have many different options to make sure recruiters don’t see it. For example, you can:
    • Clean up the offending posts, Tweets, and messages
    • Rename your profile so that’s it’s not easily found from Googling your name (for example, Tom Jenkins’s profile name can become T. Jenkins)
    • Set your privacy settings to private, so that only people who are connected to you can see what you post
  • LinkedIn Profile
    On the other hand, something that you do want to show up is your LinkedIn profile. You should have one. One plus of connecting to everyone you know on LinkedIn is that allows you to see who you know that work at companies you’d like to apply to. There are many other benefits, including the many jobs that are posted to LinkedIn’s job board that LinkedIn will recommend you.
  • Website
    If you’re technologically saavy enough to have a website, it’s a great way to be able to showcase your skills or just represent your online presence. You can even create a simple website with your contact information on it, and there are free templates online for small portfolio sites. Websites are great because they double as a way to show a future employer that you know how to use technology well enough to make one.
    A great tip to know is that Heroku has a free hosting plan, so you can host your site on it for free from just a GitHub repo.
  • Blog
    It’s not for everyone, but a blog looks extremely impressive. They aren’t crucial, but are fantastic if you have one. The drawback is that you need to have something to actually write.


  • Relevant geographic area. Do some thinking into which regions you’re willing to work in, and whether you’re willing to leave the area you operate in. Do you only want to work in your college town? Do you have dual citizenship or visas in any other countries? Will you constrain your internship search to specific areas?

If you can check all these boxes, you’re ready to start sending out your application!

Back to: The Ultimate Guide To Getting A Tech Internship


Freshman and Sophomore Internships

One great way to get into the FAANG companies is via freshman and sophomore internships. Top tech companies offer these internships only for first- and second-year students, and they are a great backdoor in. Some of these programs are directed at underrepresented minorities, while others are open to anyone.

Because students haven’t been through the full computer science curriculum yet and are just beginning their studies, the interviews are significantly easier. However, applicants do still need to have a very solid understanding of data structures and algorithms. Another thing to be aware of is that these applications close early – sometimes as early as October and November.

Some examples: 


Preparing For Algorithmic Interviews

Given an array of integers, return indices of two numbers such that they add up to a specific target.

For example: Given [ 1, 2, 3, 4, 5, 6 ] and a target 9, return [ 2, 5 ]

Can you solve this question without help? Known as the 2sum problem, it’s considered an easy problem that an interviewee should be able write a solution to without much difficulty. (Stumped? The solution is explained here.)

Most large tech companies will give applicants at least one high-pressure technical interview where you’re expected to solve difficult algorithm or data structure problems under time pressure. The algorithmic interview is the hardest kind of interview you’ll face. There are two ways algorithmic interviews are given:

Coding challenges involve solving problems under time pressure. Applicants are given a customized link to a code editor with one or a few problems, which closes after a set amount of time – generally between 30 minutes and two hours. The company sees the final code that was submitted, as well as how many of the test cases passed. Code challenges are generally a screening step; applicants with promising resumes are given the coding challenge, and those who score highly advance to the next stage in the interviewing process.

Live interviews up the pressure by having applicants solve the problem in front of an interviewer. They can take place in person (also called “whiteboarding”), over the phone, or over video chat. Applicants write code in a shared code editor and explain what they’re doing to the interviewer, who takes notes and occasionally gives hints if they’re in a good mood. The applicant’s code is evaluated, but the interviewer also pays attention to his explanations of what he’s doing and how he approaches the problem.


Before you work on the type of challenging problems that you might see an interview, it’s important to make sure that you have a good grasp of the material itself.

Ideally, you took a data structures and algorithms courses in college. If you didn’t, or it wasn’t a good course, or you’ve forgotten the material, there are a variety of books, websites, and online courses that will teach you. The following are two options, but you can find literally millions of others by asking around and using Google.

Data structures you must know:

Algorithms you must know:

You also must must know Big-O Notation so that you can evaluate the complexity of your algorithms. You will always be expected to compare the complexities of different solutions to a problem in an interview.

Unless you’re applying for a specialized position (graphics programming, for example) you generally won’t be asked advanced data structures like splay trees or A* search.

Once you have the material straight, the next step is to get used to solving interview-style problems. Some people find it easier to work with a book and others find it easier to solve problems online. Neither is a better technique than the other – it depends most on how you learn. The most important thing is to be consistent: whatever you use, go through it completely. Nothing is less productive than constantly getting into new books or websites and then dropping them days or weeks later.


There are two main books that people use to study for algorithm interviews.

  • Cracking The Coding Interview by Gayle Laakmann McDowell is a great guide to the interview process. McDowell worked at Google, Microsoft, and Apple, and explains what interviewers want to see in an extremely clear fashion. (You might see this book referred to as “CTCI” around the internet.) The book goes topic by topic and explains each topic and how to approach it, and provides interview questions on each topic whose solutions are in the back. I highly, highly recommend Cracking The Coding Interview. Besides for covering most of what you’ll need for interviews, it’s written in a concise, clear, and friendly tone.
  • The Algorithm Design Manual by Professor Steven Skiena of Stony Brook University is the other recommended book to learn how to understand algorithms. It’s a good way to understand how to approach problems, and how to recognize which algorithms can be use to solve a given problem. If you aim to learn how to think algorithmically and understand algorithms on a deeper level, The Algorithm Design Manual is the book for you.

Online Practice

One of the biggest benefits of using websites is that you can see how others solve the problems, and read discussions about the advantages and disadvantages of different solutions. You can also try out your own solutions to problems and see if they work against test cases.

There are many sites out there, but I’m covering LeetCode at length because that’s what I used and was successful with.

  • LeetCode is the main site, so much so that the process of studying for tech interviews is sometimes referred to as “grinding LeetCode.” There is a great guide to using LeetCode here. Some other useful components of LeetCode:
    • LeetCode Premium is one of the interviewing secrets of the tech world. You can see what companies ask which questions, with very high accuracy in my experience. It’s expensive though, at $39/month at the time of this writing.
    • LeetCode Discuss is where people talk about their experiences interviewing at different companies. It can be very helpful to see what process and types of questions to expect at a specific company.

Other sites that provide practice problems, review, and communities include InterviewCake, CodeWars, HackerRank, CareerCup, and HackerEarth. I’ve never used these, but feel free to discuss them in the comments if you have.

Solving Problems Under Pressure

When I got good at problem solving, I still kept failing interviews. My issue was that I would freeze if I didn’t know how to solve a problem off the bat. If the problem I was presented with wasn’t a question I recognized, my brain would shut down and I couldn’t strategize and figure out the solution.

What cleared that issue up for me was Pramp. Pramp is a wonderful free service that pairs you up for an hour with someone else who is practicing interviewing. The other person interviews you for half an hour, and then you interview them for the other half an hour.

Pramp very realistically replicates the interviewing environment, and after about ten or so Pramp interviews I found that I was able to stay very calm and think straight during interviews.

Another benefit of Pramp is that you see what it’s like to sit in the interviewer’s chair. Once you understand that, you’ll begin to understand how to really optimize your explanations of what you’re doing in an interview.


  • Choose one programming language that will be your interviewing language. Know it inside and out; know its quirks and edge cases and what it does when you multiply a char by a decimal. Always use that language for both practice problems and real interviews. It’s best to choose a language that you can always interview in, such as C++, Java, or Python.
  • Always evaluate the Big-O complexity of your solutions. An interviewer will always expect you to do this, and will ask you for it if you don’t.
  • You can do it. Some people start trying to solve LeetCode problems, realize they have no idea where to start, and give up, rationalizing that they “aren’t good at algorithms.” Anyone can succeed at these interviews – it just takes a lot of study and practice. Granted, some people probably have an easier time than others, but once you study and learn to recognize the common problems given you’ll be surprised at how much easier the questions have gotten.

Practicing for algorithmic interviews is hard, and can take a lot of blood, sweat, and tears. However, the returns are worth it. Besides for getting good at interviews, having a good grasp on data structures and algorithms can help you immeasurably in your career, both when using them and when understanding larger, more advanced ideas in tech.


Types of Software Development Companies

The application, interview, and internship experience is very different based on what kind of company it is, and what you’ll experience is heavily dependent on what the industry standards are.

The following categories summarize a few different kinds of companies, and ranks them in terms of pay, work-life balance, job stability, corporate-ness, and the interview process.

These categories are not mutually exclusive; a company can fall into multiple categories. These are also obviously not all-exclusive. Your company may be different. These are general trends within the tech industry, but don’t make conclusions about a specific company without investigating them first.

Tech-For-Tech Companies

Tech For Tech companies are companies whose main product is software. Some examples would be Google, Facebook, Airbnb, Spotify, or Tumblr. They tend to be the kind of companies that people talk about when they talk about “Silicon Valley” and “tech startups.” Tech For Tech companies are stereotypically “cool”, young, hip, progressive, and diverse. They’re the companies known for their free food, doctors on staff, and special shuttle busses for employees.

How can you tell if a company is tech-for-tech? Some signs are job titles like “Software Engineer” or “Software Developer.”

  • Pay: High. Generally, Tech For Tech companies pay extremely well.
  • Work-Life Balance: Depends – it can be very high or very low. As an intern you likely won’t have to be on-call, but as an employee you likely will. Some companies feel fewer compunctions about overworking employees than others; for example, one of the FAANG companies is well-known for demanding overtime, whereas others are much more flexible – but you still may have to work overtime simply to keep up.
  • Stability: Low. Tech For Tech companies will fire you if you are underperforming, or if there are layoffs, or for any unrelated reason; a common attitude among Tech For Tech executives is “hire fast, fire fast.” You’ll also need to keep up with the changing software development world with its quick-changing technologies.
  • Corporate: Low. You can wear what you want, drink alcohol at work events, and in general get away with things you wouldn’t get away with at most companies.
  • Types of Interviews: Mostly heavy algorithmic. These are hardest, most intense algorithmic interviews, and while sometimes there is a behavioral interview or two it’s not the focus of the interview process.

Tech-For-Non-Tech Companies

These companies make a product that is not software. Some examples would be Goldman Sachs (finance), Guardian Life (insurance), or WPP Group (advertising).

Signs of a Tech For Non-Tech company include job titles that have the words “Technology”, “Information Technology”, “Programming”, or “Coding” in them.

  • Pay: Industry standard to low.
  • Work-Life Balance: Generally a standard of 40 hours per week.
  • Stability: Medium. You’ll likely work in less shiny technologies, like Java or .NET. If you need to learn something new, the company will often take responsibility for training you in it. Often such companies invest in people staying long-term, and people might spend thirty years working for the same company.
  • Corporate: High. You might wear a suit or formal wear to work. There are strong managerial hierarchies, and you’ll talk about your boss’s boss’s boss’s boss.
  • Types of Interviews: Technology + Behavioral. Non Tech For Tech companies generally have “technical” interviews (as opposed to “algorithmic” interviews), where applicants are asked questions that show their understanding of technology and programming (for example, “Tell me some new features of Java 8” or “Describe how the singleton design pattern works”). There’s also a greater emphasis on your attitude, your abilities, and how you work in a team.

Small Businesses

Also known as family businesses, these include your neighbor who’s happy to give you a job in his business making websites or your local paint store that hires you to maintain their website.

  • Pay: Low, unless you’re freelancing or a contractor.
  • Work-Life Balance: Generally high. This is the tradeoff of the low pay: if you need to drop your son off at playgroup or stay home with him when he’s sick, it’ll likely be fine. You can often have flexible hours and work 7-11 AM and 4-8 PM.
  • Stability: High. Small businesses don’t want the headache of hiring and finding new people, and if you’re doing a good job, they’ll want to keep you. On the other hand, if you’re not doing a good job, they’ll want to replace you quickly – they don’t have the money to keep a low performer on.
  • Corporate: Low.
  • Types of Interviews: Behavioral. Small businesses want to know you have some knowledge and can learn, and can do what they need, but they care a lot about whether you’re friendly, work well in a team, and have a good attitude.


Government jobs are a whole different beast.

  • Pay: Low. The government is notorious for its extremely low-paying jobs – although the benefits are great, and you may also get a pension.
  • Work-Life Balance: Very high. The government has to pay you for overtime and generally doesn’t want to. You’ll work a standard 40 hours per week.
  • Stability: Extremely high. It’s extremely hard to get fired from a government job.
  • Corporate: High. You’ll likely wear formal wear to work, speak in corporatese, and obey a long list of rules about what you can and cannot do at work.
  • Types of Interviews: Easier algorithmic or technical + behavioral interviews.


Startups are heavily glamorized in popular culture, and can appeal to applicants’ ideology, sense of risk, or desire for adventure. However, there can be significant drawbacks to working at one as well.

  • Pay: This depends on the startup and how it’s funded. If the startup is a “unicorn,” like Airbnb, Stripe, or Uber, the pay will likely be extremely high, higher than even FAANG companies. On the other hand, a fledgling startup without lots of funding may not be able to pay much.
    Startups may try to pay you in promises. Something important to remember with startups is that the startup’s success is not your success; unless you own a significant amount of stock in the company, if the startup becomes a unicorn worth three billion dollars, nothing will change for you and you’ll still get your regular salary.
    Startups may also try to pay you in dreams, and always remember that dreams don’t pay the bills.
  • Work-Life Balance: Low. Because startups try to conserve runway and their spending, there’s often not as many people as are actually needed to build software, and when something goes wrong at three in the morning it’s you who will have to fix it. If a customer needs a feature by tomorrow morning, the startup may not have the leverage to refuse, and you’ll be up all night coding it.
  • Stability: Low. You don’t know if the company will exist next week, and you can be laid off any time the company doesn’t have enough money to pay you.
  • Corporate: Low. You can program in a hoodie while drinking beer.
  • Types of Interviews: Algorithmic + Behavioral.

Other Factors To Take Into Account

  • Size. The smaller the company, the more room there is for your own personal and technical growth. One Google engineer I spoke to complained that she had spent the last six months on a single part of a single page of an app. Large companies have less room for innovation; at a smaller company or startup you’ll be able to get your hands dirty and learn about how to do everything. The flip side is that at a big tech company you’ll specialize; you might become extremely knowledgable about one specific thing, like cloud storage or databases or load balancing.
  • Tech Culture. Does the company have a tech blog? Have they updated their technology since 1988 when it was first built? Will you be dealing with legacy code? What is the company’s attitude towards new tech?
  • Mentorship. Will you have someone dedicated to mentoring you? Will you get comprehensive code reviews? Good mentorship is crucial, and is often the difference between a good internship experience and a bad one.
  • Experiences. If you’re considering an internship, you’ll want to look at Glassdoor at what employees have to say about the company or reach out to previous interns on LinkedIn. While no one’s experience is definitive, it’s a good idea to know what others’ experiences are to have a frame of reference of what to expect.

Ultimately, choosing a company is about you and how you work best. There are different strokes for different folks; some people enjoy a corporate environment and some enjoy a more flexible, open environment. Some people enjoy throwing themselves into their work and working sixty-hour weeks, while some want to work forty hours and not think about work the rest of the time. The benefit of internships is that you can try out different environments and see how you work best without any commitment to continue working at the company.

internships Uncategorized

Where To Find Internships

The process of getting an internship starts with the process of finding internships to apply to. Many students apply for three or four positions, don’t get a response, and give up. A student that forms a strategy for his or her search and casts a wide net of applications and opportunities has a much better chance of successfully scoring a great internship.

Where can you look to find an internship?

  • Your own research

The most powerful skill you can develop is the ability to do your own exploration and find available positions. You can Google “<type> internship <time period> <year> <place>” (for example, “software engineering internship summer 2021 los angeles”). Google will lead you to results like LinkedIn Jobs and other resources that can help you find positions.

There are many websites that can help you find positions. For example, Built In NYC has great internship in the greater New York City area, and keeps track of open internships at top tech companies.

You can also simply think of a place you’d love to be part of and see if they have internships. You can work for the CIA, McDonald’s, or Toyota!

The challenge of this method is that companies recruit least from their online application portals. This means that you’re significantly less likely to receive a response, and you’ll need to send out many resumes without ever hearing back. My rule of thumb is that for every twenty resumes you apply via an online portal, you’ll receive one reply. This obviously varies with the quality of your resume, but this means that if you apply to forty companies, you’ll get around two responses.

While that sounds discouraging, remember that all you need is one response to get an internship! I know a student who applied to every place she could think of and got one response – which turned into an internship and then a job, and she still works for them now, over five years later.

If you’d really like a position but don’t know anyone at the company, you can try emailing their recruiters personally.

  • Referrals

You know your uncle who you’ve spoken maybe three sentences to in your life, and you’re not sure what exactly he does, but you think it involves computers? Ask him for a referral for an internship at his company. Referrals often guarantee you an interview. Ask for referrals from family and friends, your professors, speakers at tech events, and literally anyone you know who know in tech.

One way you can see whom you know at a company is by using LinkedIn to see your connections that work there.

  • Career Fairs

Many universities run career fairs at lease twice a year where employers recruit directly from within the college. Many times they are open to alumni as well. If your university has a career fair, research ahead of time which companies will be there and what you should look, speak, and sound like.

There are also professional career fairs that non-students can attend. However, you generally need to pay to attend, so it is up to you to decide if it is worth it.

  • Career services

If you’re in college, career services can be a big help. They can help you get your resume up to snuff, and they often know of jobs that come through the university. Exercise caution, however: career guidance is very different for the technology industry than it is for other fields, and you may get advice that is not appropriate for the industry. For example, most companies will not make you write a cover letter, and side projects are important to prominently feature on your resume.

  • Government Internships

Unless you’re living on an uninhabited island somewhere, chances are you’re living under a government, and that government has employees. Governments are a great place to get internships, especially if you don’t have industry experience – they are willing to hire based on aptitude instead of achievement and will train you on the things you need to know.

  • Hackathons

Many hackathons are sponsored by companies who are explicitly looking for interns or software developers. Chat up the representatives when your’e there! If you win a prize, they’ll be even more interested in considering you for open positions.

  • Diversity-based opportunities

If you’re an underrepresented group in technology – if you’re female, African-American, Hispanic or Latino, disabled, or another minority – there are many scholarships and diversity-based opportunities you can get involved with. Many tech companies have specific diversity-based internships. Some of these organizations also have newletters or job boards specific to people that are part of the organization.

Caution: Unpaid Internships

There will always be many opportunities for you to do unpaid internships. It’s not hard to get a position working for free.

There is one rule when it comes to unpaid internships: Don’t do them.

Why not?

  • You’ll get taken advantage of. If your time doesn’t cost anything, you can be given work that doesn’t need to be done but is just busywork. A manager doesn’t mind giving you ten hours of work if it doesn’t cost them anything.
  • You’re appreciated more when you’re paid. It’s an interesting psychological phenomenon that when your employer knows that they are paying hard-earned money for your services you become more valuable to them. If you’re not being paid, they mentally don’t think you’re as important to the company.
  • If you do unpaid internships, it becomes a standard for everyone. If companies know they can get quality unpaid interns, they don’t see a reason to pay for those same interns, and other companies realize they don’t need to pay theirs. Doing an unpaid internship means that unpaid internships will become more common.

Granted, in some fields unpaid internships are required – but in tech, where the standard is to be paid and paid well, there is absolutely no reason to work unpaid.


Why Get An Internship?

One of the biggest obstacles standing between most computer science students and an internship is that students don’t realize how important they are.

Internships are the most important way you can develop your career in software development while in college.


  1. An internship makes you more valuable to employers. 

    Employers want to minimize the amount of training new hires will need. An employer wants to hire someone who can hit the ground running, especially in technology and software development, where there’s a lot to learn and it can be some time before a new hire is productive.

    Because of that, employers will always prioritize job applicants with previous experience over applicants who show promise, but haven’t actualized it yet.

    Getting an internship means that you’ll have an enormous advantage over other applicants when you apply for jobs after college.

  2. An internship allows you to skip parts of the job-climbing ladder. 

    It’s very hard to get a job at a well-paying or prestigious company straight out of college without any experience.

    Generally, the way life works is that people slowly climb a career ladder. A college graduate will take the best position she is offered when she applies for jobs after college. After a few years there, she is skilled enough to get a better-paying position somewhere else. After a few years she might job-hop again to a better position, and eventually she might get a position at one of the coveted FAANG or fancy unicorn companies if she works hard enough.

    With internships, every internships is worth one rung on that ladder, so a student who gets as many internships as they can – and leverages them into better internships – can get a FAANG position (if they so desire) right out of college.

  3. An internship can lead to a full-time offer. 

    Companies have internships for the specific purpose of hiring software engineers out of the intern class. It’s a low-cost, low-commitment way for them to see who they like: who learns quickly, has a good attitude.

    At the same time, you get to vet a potential employer and see if you enjoy working for them. If a company likes your work, there’s a good possibility you’ll get a job offer – sparing you from having to do any job interviews at all, and allowing you to be confident that you’ll be working at a job that is a good fit for you.

  4. An internship makes programming less of an abstract concept.

    Before my first internship I had a very narrow understanding of technology. I understood what I learned in school – I could write a while-loop or balance a binary tree or write a read–eval–print loop – but I didn’t understand how that turned into Google or Twitter or Facebook.

    Once I had experience at a variety of tech companies, I saw how everything I was learning comes together to create something useful, which enhanced my ability to make sense of larger concepts within computer science. I understand how I could build large, complex systems.
At one internship I learned about satellite imagery, and how it’s used by private industry, academia, and governments to make decisions.
  1. An internship can expose you to interesting subfields of computer science. 

    Let’s say you’ve always wanted to get a job in Natural Language Processing (NLP) – the subset of machine learning that deals with processing language. Chances are, no company will consider you for a job without an advanced degree in machine learning or previous NLP experience. But it’s not as hard to get an NLP internship; most companies will hire you without much previous experience.

    For example, at one of my internships, I learned a lot about satellite imagery and the field of Geographic Information Systems, or GIS. It was a fascinating experience, and I was so interested that I later did government-sponsored research in it and took a few graduate classes on the topic.

    If you want to be in interesting places, working with interesting technologies, and be in places you might not be able to get to otherwise, get an internship!

The best possible way for a student to get a good job, get an opportunity to do interesting things, and really understand technology is to get one or multiple internships in the field.

How can you do that? Stay tuned for the next article: How To Get A Tech Interview.

Enjoyed this article? Sign up here to be emailed about new content!


How to Succeed at a Tech Internship

At my first internship, I was really clueless about what I was doing.  I was only a year into college, and interns often don’t know much, but my lack of knowledge took the cake. Once, I couldn’t figure out why my calls to my backend weren’t working, and finally a senior developer sat down to help and ended up having to explain to me that… the server needed to be running. 

By now, though, I’m a veteran junior developer. I’ve done six different internships over the course of my undergraduate years, which means I’ve onboarded to a new codebase six different times, used six different tech and DevOps stacks, went through six different types of documentation, and interfaced with six different company cultures. Each time I took note of what techniques helped me onboard and get things done the fastest. Over the course of these internships, I went from completely clueless to what I like to think is vaguely competent. 

The good news is that you aren’t going to need all that junior developer experience, because you can learn the main lessons from me instead. Here are the important things I learned from my junior developer experiences.

Don’t go straight to Stack Overflow. 

This is something that senior programmers know and junior programmers don’t. When I first started programming and had a problem, or was trying to add an existing feature to a codebase, I would google what I need to do or an error message and go straight to the first Stack Overflow link, which more often than not solved my problems. 

After a while, though, I started to realize that doing that made my understanding of what I was doing nonexistent. And if I wanted to slightly modify the code I copied and pasted from Stack Overflow, I couldn’t – I would have to try and see if someone had asked that marginally different use case somewhere else on Stack Overflow.  

Now, I always do a five-minute reading of the documentation. That’s not a metaphorical five minutes: I actually look at the time on my computer, read the documentation for whatever I’m using, and keep reading until my five minutes are up. After that I’ll allow myself to check Stack Overflow, but more often than not I’ve developed a deeper interest in the background, approach, and philosophy of the service or language. Often I don’t even need to look at Stack Overflow anymore, and if I do, I understand the solution much more easily. 

Learn to read Wikipedia, and if that doesn’t work, read Simple Wikipedia, and if that doesn’t work, google “Tutorial of <topic/language>” or “Introduction to <topic>”. 

Learn the standard libraries. 

You probably studied for interviews by forgetting that the standard libraries exist and implementing data structures yourself. But once you’re actually programming, it’s crucial to have a sense of what a language provides for you. This is especially relevant if you’re using an IDE that comes with code completion, like Visual Studio, IntelliJ, or Eclipse – they make it possible to develop for a long time and still be unfamiliar with the standard libraries. Read through language references like the Java API specificationPython Language Reference, or Ruby Documentation. Know the data structures your language gives you: what methods are available for an array, a dictionary, a stack, a queue. Read through the calls you can make for an API and the parameters you can pass to a function.    

Try to commit these things to memory if you can. If you have to remove an element from a list, try to guess whether you should use poll(), queue(), removeLast(), or pop() before using code complete to figure it out. Once you have an internal sense of what structures do what, you’ll be able to code ten times as fast, because you know what you do and what you can’t and you won’t need your IDE to tell you what’s possible. Your code will also be much more powerful, because you’ll be able to harness the full capabilities of your language and libraries. 

Put away your phone. 

I used to see the plethora of anti-cellphone and anti-social media articles on sites like Medium and the New York Times and scoff at the Luddite authors and their primitive understanding of technology. My phone was on silent and it didn’t disturb me in the least while I was working. 

Then one day I bought a phone with a terrible battery (in my defense, it was $40) and began to turn it onto airplane mode during work hours to conserve battery. Wow – what a difference! All of the sudden, my focus was qualitatively better; I was writing better code faster and getting much more done in a day than I had ever been able to before. This is important advice: stay off of your phone, reddit, Facebook, and anything else you spend time on. There are many site-blocking browser extensions that you can install to help you remember. 

Figure out how to unblock yourself. 

You are going to spend a lot of time blocked: being stuck, not knowing where to turn, and not wanting to bother the senior people on the team. Most companies don’t have the kind of extensive documentation that would be needed to fully understand how their internal codebases work. Here’s a tip: your fellow full-time developers don’t really want to be bothered to help you until you’ve tried all other possibilities. So here’s a list of resources you can check to find solutions to problems.   

  • Internal documentation. This includes internally-maintained wikis like Confluence, READMEs, and Q&A sites. 
  • External documentation. This includes publicly-facing library documentation, tutorials, and RFCs.
  • Codebases, both internal and external. This includes GitHub as well as your company’s codebase. 
  • Chat logs. Your team probably uses a chat app like IRC, Slack, or Microsoft Teams and it almost certainly supports search. You also may be able to search your company’s email archives. 
  • Issue managers like JIRA or Asana often have tickets or comments on tickets that deal with problems you might face. Seeing who assigns or is assigned to tickets can also be helpful in figuring out who you can ask for help. 

You also may want to quickly confirm with someone more senior that you’re trying to solve the right problem, and that you’re trying the right things – you wouldn’t want to spend a day trying to unblock yourself only to find out that you had gone down an irrelevant rabbit hole.  

Figure out when to ask for help. 

This is the counterpart to the previous point. As mentioned before, you will spend a lot of time blocked. Unfortunately, that’s part of the process of becoming good at what you do – figuring things out for yourself and working independently is what enables you to understand the systems and logic of what you’re working on. At some point, though, you will need to ask for help, and even though they’re intimidating, senior team members are generally happy to help and teach you new things. Here are some tips for optimizing the “asking for help” process. 

  • Decide what your threshold is for asking for help. It could be 45 minutes, three hours, or a day – it depends on you, your skill level, your deadline, the company culture, how willing to help the people around you are, and your level of desperation. But once you hit that threshold, you need to stop trying, swallow your pride, and ask someone for help.  
  • Document what you’ve tried already and why it didn’t work, so that the person who you ask for help can see that you’ve tried to solve the problem first, and so that they won’t try those to use those the same approaches when trying to fix the problem. 
  • If you have a lot of questions and they’re not absolute blockers, save them for later and then ask them all at once. This way, you won’t be constantly interrupting people’s work – you can ask them if they can sit down with you for an hour, and then ask them all of your questions at once. Something that helps with this is working on more than one task at a time; this way, if you’re stuck on one or have a blocking question you can work on the other while you think about it.

And of course, once you’ve solved a hairy problem, document the solution – for yourself, your team, or publicly – so that other people won’t be stuck the same way you were. 

Keep track of what’s going on in the industry. 

There are a couple of reasons why this is important. 

  • It will lead you to articles and opinions of other engineers as well as industry leaders. Reading is a superpower because it lets you see through others’ eyes, and reading what people in the industry have spent thirty years discovering will prevent you from spending thirty years discovering the same thing. It also gives you perspective on what people in different roles on a team and in a company want from you, the challenges that they face in achieving what they want to achieve, and what you can do to make their lives easier. 
  • You’ll become knowledgable about new libraries, technologies, and services. This is a great way to discover new tools you can use to approach a new functionality or project. You’ll also find out about new versions and capabilities of the tools you already use. 
  • Hate writing unit tests? Surprise – so does everyone else! You’ll find it’s fun and relieving to share your likes, dislikes, satisfactions, and frustrations with others in the fraternity of software developers.  
  • It will introduce you new ideas. The work of tech visionaries like Joel Spolsky and Rands in Repose are often bandied around and quoted, and it’s interesting and valuable to go through what they’ve written. 

A great way to engage with the tech community is via email newsletters or podcasts. Try to maintain a stream of news about your specific technologies (“React”), line of work (“front end development“), and computer science as a whole. Some great generalized tech sites to follow are Hacker News and

Stop being insecure. 

If there’s one thing I consistently see with interns and junior developers, it’s an intense, all-encompassing insecurity about their lack of knowledge and low output. My advice is to calm down. Everyone around you had to go through the process you’re going through at some point, and just like them, you’ll be really good one day. This is what makes computer science such a humble and helpful field – the only way to get good is to program, experiment, and make mistakes, and there are no shortcuts around the learning process. 

This is not to say you’re doing a great job. Most of the full-timers on the team are likely better than you, but even the greatest programmers had to start somewhere. Keep learning, reading, looking at code, and getting code reviews, and one day you’ll look back and notice you’re a lot better than you used to be.

In the words of the inimitable Dr. Seuss: 

And will you succeed?
Yes! You will, indeed!

(98 and 3/4 percent guaranteed.)


Be your name Buxbaum or Bixby or Bray
Or Mordecai Ali Van Allen O’Shea,
You’re off to Great Places!
Today is your day!
Your mountain is waiting.
So…get on your way!

Reprinted with permission.