Interviewing for Front End Jobs

Instructor: [0:00] Hey, everybody. Today I'm going to be talking about the front-end interview process and give some tips or preparation advice that has helped me through the interview process. Let's try to stay away from some of the more black act tactics to win in the interview.

[0:20] We're going to really dive into the whole process and start from even before you apply for that job to then all the way into the interviews itself and give you some of the things that you should be ready for along the way. The first thing I do when starting out is really know the market.

[0:42] What I mean by knowing the market is, there's a lot of trends and we know in the front-end market, it changes fast. If you've been doing this for any time at all, you'll know that there is some new framework, some new technologies popping up all the time.

[0:56] It's particularly useful to go and look into what is happening on the market. I love looking at the 2020 state of JS to see what people were using recently. You can see there's a lot of interest here popping up in Vue and Svelte.

[1:14] Now, that might at a glance say, "I need to learn Svelte. I need to learn Vue." That is not all that helpful because there's another thing that comes to mind, it's what is actually being used? Here you can see Svelte is pushed further down the list.

[1:33] Vue is up a little bit and React is up at the top. Again, this is just a global survey. This doesn't really give us the little details that we'll need to know if we're applying locally.

[1:48] What I advise is staying away from all the trends and things you see on Twitter or on the Stack Overflow surveys or even DE surveys and go and do a search yourself. Look for the local results.

[2:02] I'm based in Dublin so I went and did a little look to see what were the top jobs in my area so that I could really be educated and know what I should be learning and focusing on if I want to best my chances at landing a job, or at the very least, landing interviews.

[2:22] As you can see, when I search for React JS in Dublin, I got 621 results. That is going to be a lot easier to get interviews for hopefully, if I know my React JS rather than spending my time studying some Vue and WordPress.

[2:40] Now, that's not to say if you don't like that technology, you shouldn't go and find a job with it. I'm just talking about ways to give you an edge or to at least play the odds here. I definitely always focus on what's selling in your market.

[2:56] The next thing you're going to do after you found the jobs that you can apply for is write your resume. Writing your resume can be tough. This is one of the parts of the process that can make this easy or hard for you, because if you don't have a good resume, it's very hard to get an interview to begin with.

[3:23] I recommend for most people, keeping it to a couple pages and giving a lot of bullet points to show off at a glance the tips, and technologies, and things that you're responsible for on a day-to-day job.

[3:38] In this CV example I have here, I start with my name. I'm not John Ferguson, but this is a mock CV for this. We'll put on our GitHub. If we have some content on our GitHub, be careful. If you have an empty GitHub, it's probably not worthwhile putting your GitHub up there.

[3:57] Have your personal website, email, and phone number so people can contact you. Give the title of the job that you're applying for. Always be direct. Don't just have one resume that you send out to everywhere. Take the time to tailor for the job that you're applying for. At least, it looks like you read the job spec.

[4:18] For this one, I'm applying for a JavaScript job. I'd say JavaScript developer, and then I'd have a little bit blurb of myself. I tend to steer away from saying, "I'm ambitious. I'm a goal getter," because that is very standard and seeing too much. It can often have the opposite effect. People think it can make you sound a little bit more junior than you need to be.

[4:44] Keep it professional, a short snippet about yourself. If you have some experience, like here, it will be a senior engineer with over six years of commercial experience in software development and experience in leading teams, mentoring engineers, and software architecture.

[4:59] If you cannot write a small professional blurb like that, I would just totally disregard it. Having bullet points of your technical skill set is often useful because when somebody looks at this, they can have a quick glance and know without much effort what your skills are. This will grab people's attention so that they know they should keep reading or toss it in the bin.

[5:24] Now, hopefully, they've kept reading. That's when you go on to your professional experience. The professional experience should be appropriate for what you're applying for. I know this is more difficult if you're early on in your career.

[5:40] But even if it's a job that wasn't software related, hopefully, you'll be able to give bullet points of responsibilities you had and to show that you're a professional and that you get work done.

[5:53] I'm going to focus on somebody here that has a couple of software jobs under their belt. When they have the company's title or the company name, we go into how or what responsibilities you had as a developer in that business.

[6:14] We'll then, underneath the responsibilities or a little outline of what you did, go into bullet points again. You want to make this very passable by anyone that's reading it. It's often good to think about, "Am I bored reading this? If I am, I'm probably going to bore somebody else." Make it as easy and digestible as possible.

[6:37] On the next page, you're going to look at your education and training and you can even put in some of your technical courses here. Maybe you can put in some of the Egghead courses you've completed recently and the technical courses you've completed.

[6:53] You can move into and always have your degrees, if you have one, at the top of it because that's the most important. I like to put in some other sections like hobbies and things because sometimes it can kick off conversation.

[7:09] In the other, I usually mention that I'm a Star Wars collector. Believe or not, that has helped ease some of the stress in interviews when I meet somebody else that likes Star Wars and we end up having a 10, 15 minute tangent about different things in the Star Wars realm.

[7:27] Adding a few little personal notes or some oddities in there is often useful for when you get talking because it can be a nice ice breaker. If you can have references on this page straight away, do it because it is so helpful to have the references to speed up the process.

[7:44] For me, whenever I've been applying for things, I've usually had a job at the same time so I've wanted to wait and get the references after I at least think I have the job. What if you don't have experience? This is the hardest job probably for you to ever get.

[8:03] The first one is difficult and there's no point in dancing around that fact. It is going to be a tough battle uphill to get it. It's a competitive space out there. There's lots of people trying to land jobs in it.

[8:15] But people are also doing it every day so keep on fighting. What tips would I have for that? Network. Now really network. Getting involved with people and knowing people will help you push forward.

[8:30] If you can get a reference internally from somebody in the business, it will probably catapult you forward in the process. People just like to hire people they know. Having a good network is definitely important. It's one of the easiest ways to get a job I think.

[8:48] You obviously have to still know some of the stuff you're doing here because you are going to be referred by people who trust you. Build up your experience behind the scenes, or you're building behind the scenes and build stuff.

[9:02] That kind of leads into the next point which is make experience and show it off. It's not just good enough to be copying and pasting from tutorials and watching videos and thinking that will land you your job. You're going to have to go and build a couple of things.

[9:21] Reach out to people you know. Maybe they're family or not. Go and try build something. Maybe build a couple of websites for people and put it down as some experience on your CV.

[9:37] Once you have built a real website and it's deployed and it's on the Web, you can safely say, "Yeah, I've built something and I've gone through the whole process of putting it online and everything else." Doesn't matter if you weren't paid for it. Absolutely not.

[9:51] It's still experience because you built it by yourself. That's going to really push you up and above anyone else who hasn't done that in the process. Again, you're going to need to show it off. Have your own personal Web page that you can link to all these things. It will really help you out when you're going to point at stuff.

[10:13] LinkedIn is where recruiters are searching for people. LinkedIn is something you should definitely set up and have all the ties and useful bits and pieces in there that say you are a JavaScript developer or you're really good at CSS.

[10:30] When people are looking and searching on LinkedIn for people for jobs, they might find your profile and reach out to you directly, which will also be great because you didn't have to look for a job.

[10:43] The last tip I have on this is joining developer and business communities. The obvious one everyone always jumps to is joining meetups and local Web development groups, because other Web developers can give you a push in the right direction.

[11:01] One of the most owner-utilized networks is joining business meetups directly. You could be talking to the bosses of companies straight away if you go to the right meetups. You can cut out the Web developer referring you and talk directly to business owners or people that are hiring by going to these business meetups as well.

[11:28] If you have had no look in the Web development meetups, you could try going into some of the more of the local business communities and seeing if you could help anyone in there.

[11:39] This also could get you some freelance experience beforehand, which could then boost your experience, which will in turn help all of this. Definitely something to try if you're struggling at the moment.

[11:55] What's next? If you've gotten this far and you have sent out your resume to a lot of businesses, you're going to hopefully get some calls back. That's what we're all looking for. The first call is usually with somebody from HR from a business. They will check a few things.

[12:17] What you should have ready is you should be ready to tell them what you're doing currently, why you want to work for that company. The next one is something I always see people forgetting. Have your availability for your next interview.

[12:30] If you've set up a call with this person, make sure you know when you're going to be available for the next interview because it will just streamline the process. There's no back and forth. You can just tell them, "Yeah, I'm available four o'clock tomorrow if that helps."

[12:43] They're also going to want to know what kind of projects you've worked on recently. Again, if it's somebody in HR, they're probably not that technical. This is just stuff that you're going to relay to the team that is going to interview you.

[12:56] You might want to ask some questions as well. That will not only just show some interest but prepare you so you can succeed in the interview process. I always ask, "What are the steps in the interview process?" if they have any tips or advice to help you through it.

[13:15] Believe it or not, most of the time, they do want you to succeed. They will give you some help here if you ask. It's all just about asking. You might want to know what size the team that is working there. Some people like to work in small teams. Some people like to work in big teams. It's good to know beforehand as well.

[13:32] It's also useful to know which team you're going to be interviewing for so you can do some research about it after this call. It's also, in my opinion, most important to know what exactly I would be working on so that I know it's something that I would be interested in doing day-to-day.

[13:51] Then hopefully you'll get into this technical prescreen. This is a very standard [inaudible] . You might end up having a phone call with somebody in the team if you don't get straight into the interview process or an in-person interview.

[14:07] You might reach somebody who will want to just check that you do know some stuff about JavaScript, or CSS, or whatever it is, depending on what you're applying for. I am going to get there. I'll put some of the tips I have if you're applying for JavaScript jobs because it's a little bit more complicated. There's a lot more variety of questions out there. It takes a little bit more research.

[14:33] These are some of the common things I see asked all the time, event loops, closures, prototype inheritance, the DOM data structure and how it works, whether it's functional program versus object-oriented programming, some basic structural questions, event delegation, and sometimes -- I don't know why it's such a common one now -- const let versus var.

[14:58] These are some of the things I would go on research so that you're ready to nail this interview process. Now depending on the level, you will know how much you have to know. Again, it's no [inaudible] to learn these things anyway. They're stuff that will help you out in your career and interviews all the time once you know them.

[15:18] The least loved part of the process, usually because it takes a lot of time, is the home code test. It's frustrating for a lot of people because it can take hours to do. I am a big fan of this when I get them because it gives me a chance to show them what I can do and give them a taste of my ability.

[15:47] When you're doing this, remember code is for people. We compile for machines. We [inaudible] our code afterwards, so don't try to be too smart. Write it in such a way the person who is looking after it will understand what you're doing and saying so that they can read through it as if it was close to English or, at least, legible JavaScript or CSS.

[16:12] Comment your code as well. You might want to be more liberal with your commenting than you ever would normally. That is because we are in test mode. We want to be more verbose. We want no ambiguity. We just want to know why you're doing things. Just give people a better insight into ways you are doing things, the way you're thinking or how you came up with solution.

[16:40] I would always keep your architecture simple. Don't over-engineer. It's very rare that people want to see an over-engineered solution straight out of the gate for this. Take your time. Plan a simple approach so that it keeps things easy for the people that are reading this.

[16:58] Don't import too many libraries. This can also leave you dead in the water. If you're just leveraging libraries to solve all the problems, the person who is correcting this will not know if you could actually solve the problem because you've just leveraged older tools to build it. How would they know what you can do?

[17:21] If you have the chance, test your code. Maybe time won't allow it, but even setting up some stuff to show that you were thinking about testing will often help you through this.

[17:33] Do your best here to get even a test up and running. It will show that your attention to detail is really good here. The last thing I always do at nearly every step of the process is ask questions. Don't make assumptions. Do a back and forth to make sure you understand what you're trying to achieve here.

[17:58] There's nothing more frustrating than going through the hours of working on this and then you end up giving a solution that was not what they expected. Even though you might have put your best into it, it's useless unless you're going in the right direction.

[18:13] Next section is in my opinion probably the toughest. I don't know why this part always puts me on edge but it's something that you can prepare for as well and that's the phone coding test.

[18:27] Do yourself a favor and ask for the development environment ahead of time so that you know that your browser works with it and that you can get set up on it beforehand. It would really stop the stress when you're just jumping into this on the day. You can also ask ahead of time what style of question it's going to be.

[18:47] Is it going to be a practical test like are you going to build a small UI or is it going to be an algorithm test because lots of businesses just like to mimic Facebook and other companies and give algorithm questions just to test to see if you've studied.

[19:01] Practice without a computer because it will really help you think logically about the steps involved in solving a problem. It just makes you better at knowing what you need to do.

[19:15] I find even writing pseudo-code on paper when I'm sitting in the sitting room or sitting on my couch, kind of help me just be better at reasoning about problems and less stress when it comes to solving a random task on the day.

[19:32] You can also search for sample problems. I often do this on Glassdoor and things like that. You might have people who will tell you the kinds of questions that are being asked. Again, ask questions because assumptions are bad.

[19:45] We don't want to start building something in a way that isn't going to get you top marks. You might want to ask, "Hey, do you want to see me do this in a functional way or do you want me to do this in a brute force way? What is the best way to solve this?"

[20:03] Depending on who is testing you, they'll really appreciate that and they might even be able to give you a push in the right direction. Even if you are struggling a little, just ask questions.

[20:14] You can talk about what you think you need to do but you can't get a certain step and usually people will help push you. Because again, companies usually want to hire people so they might give you a little push to unblock you even when you're struggling. Give it a shot, ask questions, and make sure you solve out loud.

[20:31] This is the other thing that people are looking for here. They want to see what you're thinking. Because you can't add comments here really or take the time to leave notes on things, just solve out loud so people can help you through it as well in case you're going, again, in a direction that isn't right for what you should be doing.

[20:51] Preparing for these things takes time. The things I used to prepare are all here. I have used Topcoder, Frontend Mentor, Exercism, LeetCode, Coderbyte, Codewars. I have used so many different resources to try and just sharpen my problem-solving ability before these interviews.

[21:14] Before you're doing any coding tests or anything like that, I would definitely go into something like Codewars and practice that problem-solving ability. It will really help you refresh your mind and be ready for the odd things that are decoding tests because they're never as practical as they should be.

[21:38] The last stage is the onsite interview. Again, before you get to the onsite, you're going to be invited, so ask questions. Ask again if it's going to be algorithm or practical because that will definitely drive what you should be focusing on when you're studying. You should ask somebody if they can pre-test you so that you're prepared to solve on whiteboards.

[22:03] Whiteboards is like writing on paper. If you've done some of that preparation area by writing on paper, this might help you in the whiteboard stage as well. It is also very useful to just get somebody you know to help you with this in a pre-test. That goes back into this at least perfectly. This preparing without a computer will help you here. Take the time to sketch out things on paper.

[22:32] As always, in the order process as well, we are going to solve out loud so people understand your thought process because that's what people wanted to meet you in-person for, is they want to see how you work and how you prepare for these things.

[22:48] Now, if it's a more practical test and you're going to be doing some more coding, know your useful array and string methods because they will help you through these things, so your filter, reduce, map, split, join. These methods in combination can solve most problems that are asked, so learn them off before you get in there. Then last of all, ask lots of questions. This is a conversation.

[23:19] People are going to see if they like you here as well, so take the time to ask questions and build some rapport with the people that you're talking to.

[23:28] These are potentially your future colleagues so by talking to them it's going to do no harm other than maybe see whether you like them and they like you and vice versa, and help you make a better decision if it's somewhere you want to be as well as help them make a decision if it's a place that will suit you.

[23:49] Next up on the list is getting the actual result. Hopefully you get the result you want but if not, just remember it's a learning experience and there is a lot of luck involved in this interview process.

[24:04] Well, people will say it takes skills and everything else but depending on where you're interviewing, the time you're interviewing with, what's going on in other people's heads, it's very hard to know how you're going to do.

[24:16] Just treat it as a learning experience. Take something and improve on it. Every failure is one step closer to success. I met somebody very recently who taught themselves how to build a nuclear reactor in their spare time which was bizarre to me.

[24:39] I asked him how does he go about teaching something that difficult to himself. He had a philosophy that he was going to fail anyway so he just wanted to see how close to not failing he could get. I really liked that attitude.

[24:55] Just see if you can get it a little closer every time to not failing and eventually, you will get there. For my very first role, I failed over 40 interviews and it was heartbreaking. But every single one of them pushed me a little closer to where I am now.

[25:15] I am glad I failed as many as I did because where I ended up in my first role really shaped the career I had up to this point. Although it was unintentional and I did want several jobs before I got where I was, it was definitely one of the best experiences I ever had. I feel grateful for all the failures along the way.

[25:44] I hope some of this is useful and thanks a million for watching.