Two things: First, stop saying you're not good enough. Second, start practicing, and the ace developer within you will flow out. In this post I share my rollercoaster of experiences with interviewing, why I haven't given up on landing a developer job, and what I've learned along the way.
Photo by José Alejandro Cuffia on Unsplash
You might be like me. You spend your days daydreaming about writing great code and showing off your amazing work. Often, the last thing you want to do is have to fight through the interview process. You make yourself vulnerable by putting your skills out there for criticism. You open yourself up to rejection.
Don't get discouraged now. The truth is that interviewing is an essential part of every developer's skillset. Not only does it expose your skills: It gives you the opportunity to share your unique approach to technical problems, it lends you the chance to speak with other developers and pick their brains in kind, and most importantly, interviewing makes you a better coder.
Why? You show off your strengths and weaknesses. You introspect. If you do well, you get a job! If you don't, you learn what you need to work on. The truth is that interviewing is always a win-win for you.
What sucks is that unless you get the job, it almost never feels like one.
Before starting my foray into programming, I was a Mechanical Engineering student in university. I dreaded job interviews, networking, any of that, yet still I went to job fairs, handing my resume over and getting business cards back. I knew it was a necessary evil. Sometimes I'd get a call, and every time, about two minutes after giving my practiced elevator pitch to the nice person on the phone, I'd freeze.
As a mechanical engineer, I was not particularly passionate about what I was doing, and it showed whenever I'd speak with a recruiter. I spoke well enough to get calls, but after that, maybe due to inertia from not enjoying my field, I would not do anything else to prepare. Nothing came out of any of those calls except for building anxiety about the next one.
You merely adopted the rejection letter.
About a year and a half ago, I decided to take take the plunge into web development. I deemed myself good enough to start looking for internships in July of 2017. I chose web development out of my love for it, and I was more than driven to land a job in this industry... yet for a while, the same results followed as before.
I'd study relentlessly. I'd read the Django docs cover to cover. My GitHub contribution map was greener than Richard Hendricks trying to sell Pied Piper as a music player. Something had to change, and that something was my mindset.
As I said above, interviews are always a win-win for you, even though it might not seem that way at first. The very first step to conquering the fear of interviewing is to change how you think about interviewing. The most important thing to keep in mind is that you have nothing to lose, and you have everything to gain!
There is no magic method to getting good at interviews, or to getting rid of the anxiety that comes with them. Interviews land jobs, and a job is what you want--it's very easy to tunnel-vision on the end result. Here's my greatest advice: Don't.
Instead, focus on yourself. Why do you want to be a developer? If you've already got a job, why do you want to make a change? What are you good at? What do you want to achieve? How are you going to do that? Answer these questions for yourself, no one else... and be honest. Consider writing it down and keeping a log of this internal monologue.
I keep a running log of what my goals are and what I learn from every interview.
Revealing the answers to these questions will give you confidence in what you want to pursue, clarity in your strengths, and a path forward on how to improve. In setting your goals clearly and for yourself alone, you gain insights on your strengths and awareness of the gaps in your knowledge. The more aware you are of your own self, the better you can communicate your goals to others. That means interviewers, but it also helps you connect with fellow developers who might be going down the same road as you!
Interviewing is not about getting a job. Interviewing is about sharing your skills. Interviewing is about improving your skills. Let that sink in. It's not about getting the job. It's about improving.
Think about your other hobbies. For me, it's Olympic weightlifting. In weightlifting, there are two lifts: The snatch, and the clean and jerk. I am not particularly good at the snatch, but I know others are, so I often ask my fellow athletes about their technique.
We could end up talking for hours, sending videos back and forth and discussing the mechanics of the lift. "How do you keep a solid position when the bar leaves the floor?". "What do you think about when you're about to catch it?".
My goal with these questions is obviously to better my technique so that I can lift more weight. To do that, of course I want to ask honest questions and receive honest answers in kind. More often than not, I leave the conversation with knowledge that I didn't have before, and I apply it to my training.
I'm sure you see where this analogy is going. My goal in these conversations is to exchange knowledge, and often both parties in the conversation end up better off. This obviously applies to the development world as well, as when you interview, you're exchanging knowledge about the company for knowledge about yourself, and everybody ends up smarter and with a better idea of how to improve. Whether or not you get the job is just a side effect!
Hopefully this takes some of the pressure off. Above all, isn't becoming a better developer your main goal, as opposed to landing a sweet gig at Facebook?
Here it is: The hard part. I hope none of you are standing up, because I'm a terrible motivational speaker and you're going to want to be sitting down for this mediocre speech about *~THE GRIND~*.
Find a friend or peer, hop on a Skype call, and start a pair programming session! Pick some problems you both would like to work on and guide each other along the way. If you're doing this online, I recommend using JSFiddle's "Collaborate" feature (free!) or CodeSandbox's "Live" (not free! 😅), so that you've got eyes on the same code.
In doing this, you'll get used to talking through your thought process and learn how to best communicate a problem solving approach to others in a team. If you or your peer start to struggle, you'll learn how to help each other work through difficult spots. Coding with others absolutely makes you a better, more confident coder, and it'll get you in the groove of sharing your work.
The second step is much like the first, only you're uniting yourself with other like-minded people on a common goal, which is to make this damn website work somehow.
I emphasized in step one that pair programming is great for helping you building confidence and expertise in talking through your steps. Building a project with others, however, is a new ball game: You'll learn to make decisions about your code. You'll figure out your style compared to others and what sets you apart. You'll learn to work through team conflicts. You'll learn how to code in a team.
(As an aside, this is a great opportunity to get into open source software! Contributing to open source exposes you to new technologies and gives you practice in reading, debugging, and improving others' code, as well as everything I've said in this section. At the time of writing, it's Hacktoberfest 2018, which means if you contribute to open source on GitHub you get a sick shirt!)
Aside from open source, I recommend checking out Chingu, a community which matches you up with others to collaborate on a production-scale project!
Face your fear. Become mighty. Conquer the interview.
Plus ultra, baby. Image by steamXO on Flickr
If you have peers that you'd like to start practicing with, that's great! I recommend that you pair up and quiz each other with questions from LeetCode, interview modules from freeCodeCamp, or other resources that you prefer.
If you'd like to collaborate online, I highly, highly recommend Pramp, which is a service that pairs you with strangers, where both of you take turns as the interviewer and the interviewee. You'll receive feedback from your peer and will find out exactly what you need to do to improve!
Practice interviews are the real key to getting through real ones. You need to be quick on your feet, be able to answer questions about yourself, and be able to work under pressure. In a practice session with no real stakes, that's exactly what you will end up focusing on!
It will be uncomfortable at first, but think about it this way: In the previous steps, you just spent a ton of time learning how to communicate and solve technical problems and learned a ton about yourself. Those skills are crucial to succeeding in interviews, and because you've practiced them so much, the only step left for you is to apply those skills to actual interviews.
Practice interviewing again and again, and continue to grow in the process. Now it's time to send out your resume and start taking real interviews. The only difference this time is the stakes, right?
Not at all. You're not risking anything; the worst case scenario in a real interview is not getting the job, which doesn't set you back anything because you're not losing anything in the first place. Instead, think about what you have to gain:
Interviewing is a win-win every time when you put the focus on yourself. Getting the job will follow.
I hope this post helps shed some light on why interviewing is as scary as it is, and I hope to have motivated others on how to push through them. Please remember that interviewing is just as important a skill as actually coding. For developers, knowing how to communicate what you've done is crucial to the work you do every day, whether it be pushing a great new feature to an app or explaining how you solved a problem on Stack Overflow.
Much of the code we write is for other people, not just ourselves. Learn to share your skills, and your success will come in kind!