Finding your first job as a software engineer

After I finished up my teaching fellowship at Fullstack Academy in July, I spent about a month (which felt like a lot longer at the time) interviewing for my first full-time software engineer position. Eventually, I accepted a job that I am super excited about in mid-August (conveniently, I chose not to start until next month). My goal in writing this is to share some of my thoughts on the interview process– things that I wish I had known and/or things that helped me in my own search and interviewing. —

1. Be persistent

The job search can be exhausting, frustrating, and deflating at times. Most people will receive many more rejections than offers, and a lot of these rejections will be things out of your control (for me, this was most commonly “We are looking for more experienced candidates”) and before you even get a chance to prove your qualifications through an interview.

If you are truly interested in a company that turns you down for not having enough experience or something similar, and believe they would be a good fit for what you are looking for, you should email them and let them know why they should consider your despite your lack of experience. Mention specific things that distinguish you and make you right for the job. Even if it doesn’t work, you have very little to lose, and the company might even remember you to consider you for future openings.

If you do interview with a company and they don’t offer you a position, I strongly suggest asking for feedback. There were 2 reasons I am glad I asked for feedback. One, it helped me improve as a candidate and two, a lot of the people I spoke with were nice and not only gave me constructive criticism but also pointed out things they did like about my interviews. This is a nice confidence boost in what can be a tough time.

2. Do your Research

This might seem obvious, but read about the company and ask the people interviewing questions. Glassdoor is a great way to learn about the experiences of employees at companies you are interviewing at and their Interviews section can give you some insight as to what to expect.

Make sure you have questions to ask your interviewers. There are some questions I asked almost every interviewer/company I spoke with (for example, “What is one interesting and challenging problem you have worked on at this company”) but it is good to have more specific questions also. You also might be interviewing with multiple people- some may be engineers, some may be product managers, some may do other things. Have a good variety of things to ask and make sure they aren’t questions you could easily find out from the company’s website. You should be interested in the company and the work they do, and the questions you ask can demonstrate this to your interviewers.

3. Practice- but don’t memorize things

There was a time when I did a large number of problems from Cracking the Coding Interview because I thought I needed to know a bunch of fancy algorithms to get a job. I still think this book is a good resource, but don’t get too caught up with memorizing the solutions in it. Why not?

• Every interview is different. Some will ask you to do coding exercises (most of mine were on a whiteboard or piece of paper, with a few in a shared code editor where they could see what I was typing [this was always during a phone screen]) while others will ask you most knowledge based questions (these types of questions were also far more frequently asked in phone screens). Again, this is part of doing your research and knowing what to expect from the interview (you can also ask about interview format when you set the interview up).
• Good interviewers will come up with unique problems. It’s easy to ask commonly known questions, like those listed on Glassdoor or in the CTCI book. However, since well prepared candidates will have seen these when they were preparing for the interview, they don’t tell the company much about you. Memorizing solutions won’t help you if get asked a question you have never seen before.
• On that note, if you see a question you have seen before, be honest. Even if you think you are being a great actor and acting confused and then miraculously coming up with an answer after being deep in thought, you are not doing yourself any favors. A huge part of interviewing is showing the interviewer how you think, how you approach tough problems. If you have seen the solution, even if you try to pretend you haven’t, this process is going to be different and will not truly show how you approach a problem. Note: In my interviews, there were I think 4 or 5 interview questions I got asked that I had seen before. All but 1 of the interviewers made me do the question anyway, even after I told them I had seen the problem. So don’t lie about it as a way to get out of a question you are confused by.
• There are some basic ways of thinking about problems and analyzing your solutions that you should know. This is definitely not a complete list but some of these include: using the greedy approach, knowing when to use Dynamic programming, recursion, Big O Notation, data structures (I didn’t get asked about these in most interviews, but I did in some so it pays off to know the basics).

4. Use the interview process to decide whether you really want to work at the company

You can tell a lot about a company through their interview process. Are they apathetic, or do they actually seem to care about you and want you to work there? Do they ask you thoughtful questions or did they just find some random problem from HackerRank that they clearly had not looked at in detail? (this actually happened to me; when I asked my interviewer questions about the problem, he could not answer them…) Do the employees at the company seem excited about what they do?

A lot of people think of the interview process in terms of how to best impress the employer. I like to think of it more about finding the perfect match, a place to work that is the right fit for both you and the employer. It should be a place that you actually want to work, and a place that is excited to have you join their team. Use the interview process to learn about the company and to help you determine these things. Figure out what you value most, and if the position has what you are looking for. If possible, talk to employees who work there about their experiences and see if they can answer any questions you still have.

Job searching can be tough, but when you find the right job, it will be worth it. Everyone’s process is different, but I think one way to divide your time is to divide it between these things:

1. practicing/studying/coding (see the resources I mentioned below for some ideas on where to do this)
2. contacting people you know who work in the industry (or friends of friends who are at companies you are interested in– use LinkedIn to help you figure this out!)
3. applying to places where you do not have referrals (AngelList and StackOverflow careers are two sites a lot of people I know have used; I personally did not use either very much so I cannot say much about them)
4. interviewing- make sure you have enough time to devote proper time and energy to your interviews. I tried to schedule no more than 1 in-person interview and 1 phone screen a day; there were times this did not work out, but that was how I liked to balance my time
5. Do something completely unrelated to finding a job. I do think it is very important to rest, relax, and do other things as well.

Best of luck to anyone reading this position who might be in the hunt for their first job as a software developer!

Lastly, here are some of the resources I used to practice my skills while I interviewed (along with those I already mentioned like the CTCI book):

• Codewars
• Exercisms
• Epic List of Interview Questions from kate{mats}
• Project Euler
• Frontend Developer Questions . Note: I didn’t use this resource much because I was not too interested in pure frontend positions but if you are interviewing for a position involving a particular language or framework, make sure you Google interview questions about that language or framework and are prepared to answer them
• this set of Javascript problems that I put together https://github.com/seemaullal/preacto-workshop. Each has corresponding tests you can run to check your solution and explanations.
• some of the Cracking the Coding Interview problems in JavaScript that I’ve solved This is something that I have since taken a long hiatus from (so that I can learn Ruby) but there are a few solutions there from when I was contributing to the project.

Originally published at www.seemaullal.com on September 13, 2015.