Interviewing as a Junior Web Developer

I recently finished a full stack web development bootcamp at General Assembly and have been looking for work.

I spent a fair amount of time updating my CV and creating a portfolio site. I was quite pleased with the portfolio site and as soon as I was done I started applying for jobs.

I found it quite straight forward to get to the first stage of the interview process with a fair few companies. I wrote thoughtful cover letters that weren’t too long, and which usually consisted of listing a few tools and languages I am familiar with that were relevant to the tech stack of the company I was applying to, and then a more personal paragraph where I was connecting with the company and highlighting the reason I liked them.

The next part of the process has been much less smooth, and I’m going to break things down into how I approached each part of the interview process and the mistakes I made along the way!

Phone Calls

These were initial phone calls which would last around half an hour, and usually they would start with the person from the company outlining who they are and giving a brief overview of what the company does. If the companies were practiced at this it usually went quite well. There would be questions about my experience, and in most cases I would have written down a list of the languages and tools I’d been using and examples of projects I’d done, that I could then refer to.

Writing it down on paper was really helpful for me and helped me stay focussed and to the point.

I had one phone call that was particularly technical and I was asked very specific questions such as “what is recursion in JavaScript”. I found the questions asked mostly caught me completely off guard and I made some serious mistakes with this one! Here is a list of all the tips I would have given myself if I could go back and do it again.

  1. Have a list of your projects and familiar technology and keep it in front of you (I had forgotten for this one!). Make sure you’ve gone over the notes before the conversation begins. 
    This always helps and I feel this is super important.
  2. When asked a question make sure you come up with an answer, including an example, and commit to it. Include all the details you have. This is important even if it feels like it’s a long answer, and even if you feel like it’s not what the person listening wants from you. 
    I often find myself starting to talk about a concept and/or an example, then I lose confidence part way through, or outright know that I’m giving a less than appropriate answer and trying to change it mid way through. Sticking to an initial response and following it in whatever direction it takes you means you will have a better conversation, even if the answer isn’t quite what was expected. This is particularly important on the phone, when you can’t read any body language to figure out how the interviewer is responding, and you can’t work out whether you need to cut your response short. It’s rare that you will have to cut something completely short in my view.
  3. Remember that the call needs to feel like a conversation as much as possible. 
    I have this tendency to either be very practical or very chatty. In a technical phone interview it’s important to keep things conversational where appropriate. In my phone call, I answered a lot of questions with technical answers and forgot to add any key details; such as why I enjoy coding, and that I’m someone who can learn. So, for example, after most of the technical questions had been asked, I was asked if I have any questions about the company. I was already in a panic by then as I knew the conversation was going badly, and I asked if the company practice Test Driven Development and follow Agile methodology. I mumbled something about liking their ethos, but I was not offering any details about myself that could have helped them connect to who I am as a person, as well as my coding experience. I could have said “I’ve been enjoying practicing Test Driven Development, especially on my last project where I used Mocha to test the authentication process. What practices do you follow at your company?”. I felt I rushed the conversation and cut my answers back, feeling I was being “tested” for my knowledge. It’s so important to remember that the conversation is a two way street, and it’s important for you to get along with a company as much as it is for them to assess your skills and get along with you.

As a junior developer, my knowledge is sometimes still a little fuzzy when it comes to using the right terminology and expressing myself clearly, so I feel it makes a big difference when I take the opportunity to actually add some details about myself and my personal experience.

On that note, here are a few related tips:

  1. Don’t try and please the interviewer, remember to give answers that feel right to you. 
    Which, to me, means that it’s important not to keep second guessing what the interviewer wants, and to stick to an answer that feels right. If it ends up being somewhat off the mark, or not what was expected, that should be okay! What matters is that you give a clear and thoughtful answer.
  2. Ask for the question to be repeated if you need to, but then go for what you think you understood, and follow through!

Face to Face Technical Interview

I have only had one of these so far, and I will highlight the things I learned from this interview.

  1. Take your time to answer the questions. 
    This might sound obvious, but I found it is too easy to give a reactive answer and not think it through enough, at least for me. I always feel that it’s important to share my thought process, so the interviewer can gauge my problem solving abilities. However, I found there is a thin line between sharing useful thoughts, and offering useless fluffy words while I stumble through something I’m really not understanding or thinking through.
  2. Keep the role and specification in mind at all times. 
    I was interviewing for a front end role at a company, and simply hadn’t thought through or focussed on the context of the role. I was asked a question about how I would handle dynamic data. I went completely blank and I was frantically going through all the ways I have handled data, both back end and front end. If I had taken my time to absorb the question and put it in a front end context (which the role was!) I may have reached an answer. However, as it stood, I spent ten minutes completely blank and confused and trying to process what was being asked of me. I got there in the end (with some prompting!), but the question was really about request methods, and how to make them. The answer should have been; “For handling dynamic data I’d make an HTTP request. If I were updating the data, I would use a put request”. I could also have added that with React I’d been using Axios, which is an HTTP client.

Code Challenges

I think my first hurdle with this one is referring to them as “challenges” and not tests, which apparently is what most companies call them.

My very first challenge was creating a website from a design brief, and my experience with that deserves it’s own section on “tips that I have to offer”, aka, don’t make the mistakes I did!

  1. If the brief includes a mobile design, definitely build it as a mobile first website!
  2. Code what you can in the time provided. 
    You will not finish a whole website in four hours! This was my biggest and most embarrassing mistake so far. I had the brief, I started coding away and I rushed everything, thinking I should try and produce as much code as possible. I’ll expand on this below to include a few more tips as to how to approach something like this.
  3. Remember to focus on yourself as well as the brief. Check in now and again. Ask yourself; am I proud of this code? Do I feel this is what should be expected of me on the job? 
    I was so focussed on what I felt was expected of the task, and the notion it was a test, that I forgot to check in with my internal radar and reflect on whether I was actually producing something of high standard (or even acceptable standard!). The outcome was terrible. I sent the company an absolute mess of code, with no comments, no structure, and, on top of that, I had panicked about the time limit and used a framework. Which leads me to my next tips.
  4. Comment everything you can (within reason). In the CSS file add those comments that show which parts of the site the code refers to. 
    I am mostly in the habit of doing that for myself, and I simply allowed the time constraint to take over any thoughtfulness I could have applied to the task. This is not a moment to be sloppy and leave out comments and structure. I truly pity the developer who had to scrape through my messy, unhelpful code!
  5. Always use plain CSS/ vanilla JavaScript /insert language you’re using here. Don’t use frameworks or libraries unless you absolutely have to, and do that right at the end only if you come across some code that warrants it!
    Most companies are wanting to see your coding skills, and your ability to use a framework or library is usually much less relevant or valuable to them.

I’ve had some great advice from sources such as the careers panels at codebar and General Assembly as well as all the advice I’ve been given along the way. If you can get involved in meet ups and take advantage of the awesome support like they offer at Codebar, I can highly recommend them! 
Sometimes though, it’s just about making those first mistakes and then learning from them. I may have some more tips and thoughts as I continue my journey, in which case I may write another post. I’m sure I still have a lot to learn!