Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Selling Yourself12:20 with Pasan Premaratne
Applying for a job in technology means proving your technical proficiency. There are many ways you can be asked to do this and in this video we'll go over some of the common methods depending on the role.
Applying for a job in technology means proving your technical proficiency. 0:00 There are many ways you can be asked to do this, 0:03 and we'll go over some of the common methods, depending on the role. 0:06 First, let's go over how you can be interviewed for a designer role. 0:09 A design job has very visual outcomes, 0:13 so expect the questions and tests to be weighted similarly. 0:17 If you are applying for a design job, you will have to showcase your work. 0:20 The most common way you will be asked to do this is by presenting your portfolio. 0:24 Things that employers could be looking for are visual weight, 0:29 does it look good; information hierarchy, are the most important things 0:32 on the page immediately visible; information organization, 0:37 are related ideas near one another; 0:40 intuitiveness, is it clear what you're supposed to do next; 0:43 and clarity of copy. 0:48 Once you show your portfolio, you can be asked to explain your design process. 0:50 If you don't know what this means, pick your three best pieces of work 0:54 and ask these questions about them. 0:59 What problems were you given? 1:01 How did you approach solving each problem? 1:03 How did you iterate from idea to final product? 1:06 How many concepts did you work on, and how did you decide on a final concept? 1:09 The goal here is to show that you have a rational, thoughtful process 1:14 that balances the requirements of the client with the end goals of the user. 1:18 Aside from presenting visual examples of your work, 1:22 you can be asked a variety of questions about your approach to being a designer. 1:25 You will be asked questions that show your initiative to learn. 1:29 Design, like everything in the tech industry, is constantly changing. 1:32 And you will have to keep with the trends, best practices, and new technologies. 1:36 Are you willing to learn this? 1:40 And how proactive are you at identifying these trends and changes? 1:42 Testing these initiatives can come in the form of questions like 1:46 What do you read? What is an example of good user experience and why? 1:50 How do you stay up to date on trends in the industry? 1:54 Finally, you could be asked to run through a quick project at the interview. 1:57 You could possibly be given a UI component to redesign 2:02 or a description of a problem and be asked to walk through a solution. 2:05 Carry these exercises out at home, so that you are best prepared. 2:09 Developer interviews are a bit hard to generalize, because jobs can vary by 2:15 language and other areas of expertise. 2:19 Let's go over different types of interview structures you can expect to run into, 2:22 and then we'll talk about different questions. 2:26 In addition to the general interview questions, you will run into situations 2:28 where you have to demonstrate your ability to code. 2:32 There are a couple different ways you can be asked to do this. 2:35 Whiteboard tests are a practice that many people have heard of 2:38 but not a lot of people, at least developers I know, have been through. 2:43 There is a general antagonistic trend towards whiteboard testing. 2:46 A lot of people see it as highly unrealistic and an ineffective way to test a candidate. 2:51 Nevertheless, it does happen, so you should be prepared. 2:56 With whiteboard tests, employers are testing a few different things. 2:59 A whiteboard is a finite space, so writing out some code 3:04 quickly and then backtracking to add another variable or loop will get messy. 3:08 They're testing your ability to think through a problem and how to solve it 3:12 given the finite space that you have. 3:16 Secondly, they're checking that you know your language without having an IDE 3:18 all to complete your stuff for you. 3:23 If you forget a colon, comma, or semicolon, it's not the end of the world. 3:25 But they're looking to see if you can remember language-specific stuff. 3:29 Finally, they want to see how you work. 3:32 Do you ask questions and clarify any assumptions? 3:35 Do you read over your code and check things? 3:39 Is coding a collaborative process to you? 3:41 Do you ask questions and explain your reasoning to the employer? 3:44 Or do you like to be left alone? 3:47 If you Google whiteboard coding, you will see a lot of people arguing against it. 3:49 Regardless of where you stand on the issue, 3:54 if there's a chance you might have to do a whiteboard test, 3:57 it is best to practice beforehand. 4:00 The second type of interview you can run into is a pair programming interview, 4:03 where you code with someone from the company. 4:08 Like whiteboard tests, pair programming has its own set of criteria 4:10 to test in an interview. 4:14 It is good at exposing an interviewee's programming style. 4:17 Coding with someone allows you to see if they're open to criticism 4:20 or are thoughtful and have the ability to express their ideas clearly. 4:23 It can also show you if they're aggressive or competitive and hard to work with. 4:27 Second, you get a very early glimpse of their creative skills. 4:32 A key part of a developer's job is to read an insufficient set of requirements 4:36 and come up with creative solutions to fulfill needs. 4:40 Finally, you see through their thought process as they work through complex problems 4:43 and get an idea of how they complement your team. 4:49 Pair programming doesn't test at all job levels, so it's not ubiquitous. 4:52 But for mid to higher level positions, you can expect to run into this kind of test. 4:57 Then there's also written tests on paper. 5:01 You could be handed code samples to review and identify errors. 5:04 This kind of test is looking to evaluate the same set of criteria 5:08 as a whiteboard test. 5:12 As to the type of questions you could be asked, there's lots of different topics. 5:14 You could be asked simple factual questions about a specific programming language 5:18 or questions regarding data structures or algorithms. 5:23 It just all depends on the positions you are applying for. 5:26 A great way to figure out questions you might be asked at a specific interview 5:29 is to check out websites like glassdoor.com or LinkedIn. 5:34 Glassdoor is a great website to get all sorts of information about a job, 5:38 from reviews, salary information, and most importantly interview questions 5:42 that people have been asked when they interviewed with that certain company. 5:47 I've included a document in the downloads with a list of potential interview questions 5:50 by topic, ranging from easy to hard. 5:55 The list probably only covers a tiny part of all the different questions 5:58 out there, but, hopefully, it's enough to give you an idea of what to prepare for. 6:01 Now that's all I have to add to the topic. 6:06 But to round it off, let's look at what some of our teachers 6:08 have to say about being interviewed for jobs they've done in the past. 6:11 >>So it's interesting. There's such demand for mobile development right now. 6:14 The moment I updated my online profiles to say I was doing mobile development, 6:18 I started to get requests and job offers. 6:23 I wasn't even looking for a new job, and people started to contact me, 6:26 through LinkedIn and other ways, to say, hey, I see you've got these skills. 6:30 Let me tell you about my company. 6:33 And I went on a couple interviews just to see what things were like. 6:36 And it's kind of an intense process. 6:40 It's one of those things where, in my experience and I think this is relatively general, 6:44 people want to know what you can do. 6:50 They don't care as much about your degree or— >>Right. 6:52 >>or what certifications you have. They want to see your code. 6:56 And they want to see you code. 6:59 So we mentioned having things available online for people to look at. 7:01 But one of the experiences I had was, with some small companies, 7:07 they wanted to—one company gave me an assignment to do. 7:11 And I had to write some code, send it back to them so that they could review it, 7:14 and do it within a certain period of time, 7:18 so they knew I could turn things around and meet a deadline. 7:20 And then another—a friend of mine had an experience where 7:23 he went, interviewed for the company. They really liked him. 7:26 They invited him back to do some pair programming, 7:29 because they wanted to pick apart his brain, give him something to solve, 7:32 and watch how he worked through it, and they ended up— 7:36 there was an iPhone application they were working on, 7:39 and they found some weird bug, and he was working through stack overflow 7:41 and navigating the documentation, and he really just impressed them 7:44 with how he could solve the problem and how he wrote the code. 7:47 >>So pair programming is essentially you're there, and there's someone else watching you code. 7:51 >>Yeah, he was working with a developer at the company for a couple of hours, 7:56 on a small project, just to see how he worked with a team 7:58 and how he thought about the problem. >>That could sometimes be nerve-wracking, too. 8:04 >>Oh, sure. >>Someone watching over your shoulder and watching you code. 8:08 >>Yeah, I didn't have that experience, but I imagine it was very nerve-wracking. 8:11 It was nerve-wracking enough just to put together the code and send it 8:16 away from somebody to evaluate, but it was also a good experience 8:18 in that I could make it pretty much how I wanted it. 8:23 I was putting my best out there, and it was up to them. 8:27 As opposed to a more traditional interview, where you feel like 8:32 you've got to answer the questions the right way, and you can leave the wrong impression. 8:36 When you're just sending a product for them, like this is what I can do— 8:40 it was a better experience for me. 8:44 >>Yeah, I think, more and more, when it comes to actually coding in dev positions, 8:47 the employers are asking you to send over code, 8:51 or they ask you to solve a little puzzle, or they ask you to build a little feature 8:54 that they could use in their app. 8:59 So that they can review your code, they can see that you deliver on time, 9:01 and they can see the depth of your knowledge, too. 9:05 I mean, having the breadth is good, but a lot of employers do look for depth, 9:08 especially when it comes to mobile dev. 9:13 Do you know the language, do you know the ins and outs of the language? 9:15 I think one of the craziest questions I got, which was totally unrelated 9:18 to the development aspect, but it was more—can you think on your feet kind of thing— 9:23 was, given two phones with both the airplane mode on, 9:28 there's text on one phone, how would you transfer that text to the other phone? 9:33 So it was just like it stumped me completely. 9:37 I was like, well, there's no airplane mode, there's no Bluetooth, 9:40 you can't have an accessory attached to the phone, like— 9:43 how would you do it? 9:46 I couldn't answer it, of course. (laughter) 9:48 >>You know, we're given these detailed answers, and that's— 9:51 this is for a more advanced senior-level developer position. 9:54 I think a lot of companies, because it's a—there's a lot of demand, 9:58 a lot of companies do realize that people are coming in as entry-level, 10:01 needing to learn the technology, so that's a different experience, too, 10:05 where I think, in that case, you just need to show that you have 10:08 an appetite and an ability to learn. 10:12 And that the culture and the fit with the team is important, too. 10:14 They want to just make sure—whether you're working remotely or on site, 10:19 just that you can communicate clearly 10:22 and that you'll have the same, a similar work ethic 10:25 as the rest of the people you're working with. 10:28 >>Being interviewed for a development position varies from company to company. 10:33 Sometimes there's maybe small entrance exams, sort of thing, so 10:38 the most technically capable person in that company, 10:49 which may be very technical or may be not that at all, 10:53 may ask you how to start something in JSS 10:56 or may ask you generic computer sciencey type things. 11:01 And depending on your performance, I've often found 11:07 even with a semi-okay performance, don't be too hard on yourself 11:14 because you're often more technically competent than the other entrants. 11:20 So always go in there with a positive attitude, and 11:24 brush up on the particular skills that you know that they'll be looking for. 11:30 >>It's been a very different interview process for every single job that I've had. 11:34 For example, my professor hired me in college during my sophomore year, 11:40 so that was the longest eleven-week interview I've ever had. 11:45 So there was that one, but I've also interviewed for a more traditional 11:48 advertising agency, where I had to come in with my computer 11:52 and show them my favorite pieces and explain what problems I solved 11:56 and really thoroughly go into them. 12:00 And then another interview I had was just literally through Twitter. 12:02 It was very casual. He mentioned that there was a job opening. 12:07 I tweeted that at him, and he called me and set up a more official interview. 12:11 But they've all kind of been very different experiences for me. 12:16
You need to sign up for Treehouse in order to download course files.Sign up