 everyone. Before I get started today, I just want to say who is a Ruby expert? It's in this interview. It's in this session. Okay, great. So this is about Ruby Technical Interviews. My name is Chris Marr and I'm a software engineer at Custom Inc. But I've been doing technical interviews for over 15 years. I started with C++ interviews and then I used to do Java interviews and now I do Ruby interviews. But through all that time, early career developers are always plagued by the same problems during interviews. So you've been learning Ruby. There's a lot of great resources out there. Maybe you're doing a bootcamp or online code school or reading books, but you've been learning the Ruby and now you're ready to start interviewing for your first job. The first thing that's going to happen when you start looking at job descriptions is going to say one to two years of experience, maybe of scripting language experience. And if you don't have any experience when you go into these interviews, you don't have anything interesting to talk about. So how do you get this experience? Well, you build something. This is the number one recommendation. Build something. And don't just build anything. Find something in your life that you're passionate about and build something for that. So let's say you collect Magic the Gathering cards. Build a website and manage your Magic the Gathering collection. And don't just build the obvious thing that's a website showing your Magic the Gathering cards. Do something interesting. Maybe you want to calculate the future value of your card next year. Write an algorithm that's interesting. And when you start doing this, reach out into the community and use some gems. So reach out to the Ruby community and find gems that help you solve your problems. If you only have time to pull in one gem, always pull in device. Every company you interview with is going to be using device. After you've created this project on your laptop, you've been typing away, push it up to GitHub. If you haven't done this before, this is the cathartic moment where you're taking something you've created and you've pushed it out there for the world to look at. After you've pushed it up to GitHub, deploy it to something like Heroku. The reason you do this is to show that you can create something on your laptop and productionalize it and put it out there for everyone to use. Then you send this link along with your resume. And before we interview you, we're going to go look at that link and say, hey, this is great. I really like the way they put together this magic they gather in website. Then we'll say, oh, I wonder how they're calculating these future values. That seems like an interesting algorithm. So put one of these banners at the top and go see my source code on GitHub. And we'll be able to go over to GitHub and we'll take a look and see what you've done. Now, when you invite someone to your house, you usually straighten up a little bit before they come over. Same thing with your source code. Clean up the code. Remove any commented out code. Make sure your indentation is nice and pretty before you invite people to come over to look at it. Now, one of the important skills of a developer is to be able to describe what they've built. There's a technique called rubber duct debugging. And this is where you keep a rubber duck on your desk. And if you get stuck on a problem, you take the duck and you describe the problem to the duck. And a lot of times the solution will reveal itself during that process. Same thing here. Find a duck and describe what you've built to the duck. Practice describing what you've built to the duck. Then find some non-technical people in your life and describe your project to them. Maybe you can call your parents up. Hey, mom and dad, I built this great website. Remember all those magic, the gathering cards you bought me? I've determined they're going to be worth thousands of dollars next year. Let me tell you how I did it. Then go to a local meetup group and find some technical people and say, hey, do you mind if I tell you about my project I built? See what questions they ask you. So all the learning you've done, the code school, the boot camps, and your passion project, that's going to fill about half a resume. The next thing you need to do to fill out the second half, the best way to do that is to contribute and to contribute to open source. Here's the secret. Even if you don't feel like you know enough Ruby to contribute to some of these projects, every project needs documentation. And you say, well, that's not Ruby. How can that show what I can do with Ruby? Well, actually, if you were able to look at someone else's source code, understand it and then document it, that's more difficult. And if you can create a pull request and work with the engage with the project team to get the pull request pulled in, that's a great demonstration of your abilities. A friend of mine, Kevin, he created what we called the most pendantic pull request of all time. He went around to a lot of big projects on GitHub and explained to them that they're using the EM dash for the range of years in their license instead of the grammatically correct EM dash. Super pendantic, but he got engaged with a lot of project teams. And now he's actually one of the top 10 contributors on Bootstrap. Now you can put together your resume. You have a lot of experience that you can put on it. Here's the secret. Most developers are lazy. And when you come in, we're just going to read straight down your resume asking you questions. So you have the opportunity to construct the conversation before you go in. So put it in, I built this project. I read this book. I did this class. Here's the projects I contributed to. And then you can practice that conversation before you even come into the interview. Speaking of practice, a technical interview is a lot different than writing a movie on your laptop. When you're learning, you're sitting at your laptop focused on the screen typing. Soon as you come into an interview, the first thing we're going to do is we're going to say, here's a whiteboard marker. Please stand up on this whiteboard over here and solve this problem. And if you've never done that, that context switch can be disorienting. So find a whiteboard somewhere and practice solving problems on the whiteboard. While you're practicing, practice solving the problem but also speaking while you're writing. So say I'm going to create this array. Now I'm going to iterate through the array. Remember, the whiteboard doesn't compile. So you don't have to write perfect source code. But don't sit there quietly. If there's nothing more awkward than we're staring at your back while you're quietly noodling a problem. After you practice solving some problems, some writing code on the whiteboard, practice your domain modeling. This is your box and line drawings. This is things like maybe active record models or Ruby classes and how they relate to each other, even SQL tables and how they relate to each other. This is how you, given a problem domain, how would you construct, how would you diagram the concepts? So for example, if I were to ask you, how would you model RubyConf? Oh, well I would say there's a conference. The conference has many sessions. Each session has one speaker. Each session has many attendees. When you start writing on the whiteboard, most people tend to start in the upper left corner. And that puts you in a corner. You don't have any space if you have to make annotations or insert codes. So always start in the dead center. That way you have space all around if you have to make insert annotations on your code. Now before you go in, you have to remember that Ruby is a community. So you need to understand what the community is doing and where the direction is going. You're already here at RubyConf and that's a great start. And while you're here, make sure you figure out who the thought leaders are and go to their talks. Tenderlove just gave a great talk, Matus talking on Wednesday, or I'm sorry, Tuesday. But listen to these people and if you don't have time to see them here, they get conference. They've been talking all year at different conferences and they're talking about the direction the community is moving. Another great resource to learn about the community are podcasts. There's many of them out there. I'm a host on Ruby 5. Every Tuesday and Friday we give you five minutes of news of what's happening in the Ruby community. But if you only have one to listen to, I recommend the Ruby rogues. They've interviewed a lot of thought leaders and a lot of project leaders and they have an amazing back catalog that's approachable to all levels. Know what's happening. Ruby 2.3, they just went into preview and they're going to be talking about it at this conference. Nobody's really using this yet, but if you were to go into interview, if you know what's happening and maybe you could ask a nice question like, oh what about the new navigation operator that's coming to Ruby 2.3? Are you guys thinking about using it? What do you think about that law of demeanor? How does that work? Maybe Rails 5. Maybe you're looking at, maybe you're thinking about Action Cable, the new WebSocket framework. No one's using that yet, but you could ask them, hey, are you looking at using that? Now at some point during the interview, they're going to ask you an innocuous question like, hey, what code editor do you use? Never ever say, I'll use whatever you want me to use. Always have an answer. You're talking to developers who spend all day long working in their editors, fine tuning them. They really care about the craft and the tools they use for the craft. I can start awards from them by saying, all these vim users over here, tell us why you do it faster than everybody else. So when they ask you what editor do you use, whatever you're using, if you've been using Adam, say I use Adam. I use RSpec. I use Cucumber. Whatever it is you're using, that's the tool as you've chosen to use. I'm open to using new tools, but right now I'm using Adam. Now most of you didn't raise your hand when I asked who's the Ruby experts and that's good. A lot of people put Ruby expert on their resume. I'll tell you what happens. These resumes gets handed out to the developers in the morning before you come in for an interview and they all stand around and go, oh, this candidate's an expert. Let's see how much of an expert they really are. It sets the bar so high that you're going to fail before we even get to the interview. Now you're ready to come in and talk to us. So what are we looking for? I did a survey of some senior developer and said, what are you looking for for early career candidates? And these are what they said. They said, we're looking for curious minds. People with curious minds. We're looking for people who are coachable. Are they willing to enter into an agreement with a coach and learn and listen from a coach? Are they passionate? Are they passionate about Ruby, passionate about solving problems? And are they enthusiastic? What's the one thing they didn't say? Ruby experts. They're not looking for Ruby experts. So you're going to come in and you're going to talk to us. So who's going to conduct the interview? Well, the technical portion is typically handled by engineers. And what are we doing? Well, we're sitting at our desk. We're on our computer, headphones on, we're jacked into the matrix. We're typing. We're doing what we love. We're solving problems. Manager is going to come over to us, tap us on the shoulder and say, hey, we have a candidate. Can you stop what you're doing, what you love to do, and go talk to this candidate over here? And of course we do it. That's part of our job. But we're going to get up and we're going to start walking over towards the room. And we think, what do we like to do? We like to solve problems. That's what we do all day long is we solve problems. Manager comes to us, website slow. If you have a problem, yeah, I'll solve it. That's what we do. And we build things. We love to build things. We like to sit at our computer building things. And we love Ruby. A lot of the senior engineers that you're going to meet with came from other languages, maybe Java.net. And they came to Ruby because they love the community and they love the language. And here's a tip. We want to hire you. Hiring is difficult. It's hard to find people. It's hard to get them into the interview. And it's stopping us from doing what we love. So if we can say, we can talk to you and then go to our manager and say hire this person, then we're done doing the interview portion. We get back to what we like to do. So we want to hire you. Now, when we get in there, I have one hour to decide. Will you help me solve problems? Will you and me be able to sit on a white board and solve problems together? Will you and I be able to go back, sit at our desk and build the solutions that we've designed? Will it be fun building those? You don't have to know Ruby. I can teach you the Ruby. I had a lot of great mentors in my career that taught me things. And Atlantis always pays his debts. But I have to be thinking it's going to be you and me for five years sitting together solving problems and building things. I'm going to see you more than I see my spouse. And I have one hour to make this decision. So those are what I'm thinking about. But when we come out, my manager is going to come to me and say, how much Ruby does this candidate know? So we're going to have to do some Ruby questions. Every Ruby interview is going to revolve around enumerable. Almost all questions end up being around enumerable. So if you're new to Ruby, make sure you know enumerable. And if you only have time to learn a few things, make sure you know each map and inject. All questions probably will start within each map or inject. But if you have time, because it's so important, pull up IRB, pull up the API doc and just write a little example for each one of the enumerable methods. Because you may find yourself in an interview with someone who's trying to trick you with an obscure enumerable question and you'll be ready for that. If you're in for a Rails job, make sure you know your active record associations. And the three big ones are the has many, the belongs to, and the has many through. Guarantee most questions somehow end up being the has many through or the classic hasn't belongs to many. Now then there'll be a series of questions. These are the algorithm questions. This will be a question like, give an array of integers determine if two of the integers add up to 500. And if you don't have a computer science background, these can seem daunting. They don't have to be. Because there's actually not a correct answer. We don't have anything else to judge you on, so we ask you these questions. And all you have to do is answer them better than the pool of candidates we're interviewing. And there's a good technique to answer any of these algorithm questions when they're asked of you. First thing you do is ask a lot of questions. Make sure you understand exactly what the algorithm question is. Then solve a brute force. Get the answer on the board. Don't worry about any corner cases, just say, this should solve the problem. Then apply the bud technique. Go through your algorithm that you written on the board and look for any bottlenecks. If there's one line of code that's the slowest, that's going to be the speed of your algorithms to try to improve on that. Look for any unnecessary work you might be doing. Maybe each time through the loop you're doing a line of code that could be done once before the loop. Then look for any duplicated work. A lot of times when you're searching through an array, you can remove elements from the array each time to reduce the amount of the times the next loop has to iterate. Know how the web works. A lot of people ask, how's the web work? What happens when you type a URL in a browser? Now be able to explain what happens when you type the URL in the browser, the request response cycle, what happens on the server, the process, is everything involved. And then we come to the hard questions. These are the notorious interview questions that you've always heard about, like how many ping pong balls fit on a bus? Nobody cares how many ping pong balls fit on the bus. The point of the question is to ask you something in a problem domain that you're not used to and how you approach the problem. And there's a simple way to answer all these questions. You say, I have never thought about this. I've never thought about how many ping pong balls fit on the bus. But I would start with the smallest thing I do know. And what's that? Maybe the size of a ping pong ball. I can determine that a ping pong ball is maybe one inch by one inch. From there, you can build out and say, oh, OK, maybe I can figure out how much a cubic foot of ping pong balls is. Then you can kind of start estimating how many fit on the bus. Then ask questions about the problem. How big is the bus? How many seats are on the bus? Are there people on the bus? Is the bus moving? That's engineering. If any of these questions, the Ruby questions, the algorithm questions, these hard questions come up and you get stuck, it's fine to say, I'm having trouble getting started on this problem. Turn to the interview and say, could we pair on this solution? Could you start on the whiteboard helping me head in the right direction and I'll pick it up from there? Every developer loves to pair with people. Now, if these algorithm questions, you're still concerned and want to be prepared, there's an easy 700-page book you can read before you go into the interview. This is actually a very good book and she covers things like the bud technique. Now, at no point when you ask a question during the interview, say, oh, I could just Google that. Of course you could Google that. I Google all day long. Most of my job is finding things on Stack Overflow and copying and pasting them over. But that's not the point of the interview. You're the end of the interview when the wrapping things out. Usually they'll turn you and say, do you have a question for us? Always ask a question. Have a question that's prepared. Say something like, oh, earlier in the interview, you asked me if I had experience with Redis. Do you use Redis? What do you use Redis for? Or before I came to the interview, I was looking at your website and I saw this cool JavaScript widget you're using. Why did you choose that? Now, a lot of the comments in this talk are about company and culture fit. And not every company is going to be a good fit for you. But there will be a place for you. And remember, we want to hire you. So thank you. We have plenty of time to answer some questions. Do you have any questions about interviewing, finding a job, resumes? Ruby? Yeah, well, that's a good, typical one. Let me turn to you. Have you ever been asked one of these hard questions? Oh, OK. Well, you can Google for a lot of these. I don't Google for that. But you can find a lot of examples. But that's one of them. I mean, there's a lot of legendary ones like how many wire manual covers round. Typically, there are logic questions like, you're giving a series of light switches, how much you solve a problem. Maybe best if you kind of search around for those. But the point is that they're looking at how you approach the problem, not necessarily how to solve that problem. There's always the one that how many windows are in the buildings in Seattle or that's another one. Right. So she's asking, is there another resource besides the 700 page book on cracking the code interview? And that's the best resource I found for at least the questions. And then you just have to kind of search around and try to solve some of those problems. There's 189 algorithms in that book. So it's kind of hard to know every one of them. But if you just kind of know the series of them and how you would approach each one of those. I mean, a lot of times the questions are about like if you get into nested loops, how do you break out of the nested loops or how to do things ahead of time? And a lot of that comes with experience. But like I said, they're not actually looking for the correct answer. It's how you approach the problem. And that's the secret is just get the problem on the board and then start trying to optimize the algorithm. And it becomes actually repetitive patterns as you do if you've done a lot of them, you'll kind of start to see that it's the kind of the same techniques over and over again. That's a very good question. He's saying in 15 years of interviews, what has been your best source of candidates? There's not one that really stands out. We've definitely hired people coming straight out of college, people with experience. I've hired great people that didn't have any schooling and I've hired people who've had boot camp experience. So there's not one that sticks out. It's really about the person and being able to work with the person and if they're open and willing to learn. I'd much rather have somebody who's coming in enthusiastically teach me everything you can and willing to listen versus somebody who comes in and goes, I already know everything. I've done this before. So the question is, do I have any do's and don'ts for blogging? I would say do blog. It's a great resource. It gives you time to format some of your thoughts and if you put that on your resume, we can go look at your blog and see things you're writing about. It's a great resource and something that we can get to know you even before you come in. And a lot of times if you have a website or a resource like a blog, we'll make a look at things and ask you questions about it. So you ask how many people come in cold? A cold call? Yeah, if we get a cold resume, you have to remember we get hundreds of resumes maybe a day, like we get a lot of resumes. The ones that stand out are the ones who've kind of researched our company and maybe they write a nice cover letter to attach to the resume and to explain why they want to work specifically with us. It really sticks out if you use a cover letter that we can tell that you're just sending into all the companies. But if you have something that's kind of personalized for what we're doing, another secret is to go to local meetup groups. Like every developer and I that work with us, they actually go to a lot of the local meetup groups and you can easily find someone and just make a connection and you can see them in the email when you apply. Yes, that's a great thing. So she's saying if in the cover letter maybe she saw something that she'd like to change or she can improve. And I think that's great. That's you're looking at well, you're solving the problem and us solve the problems that we're trying to solve. And that's a great introduction into the company. I mean, open source is great, especially in the Ruby community. I think it's a big part of our community is giving back. And even if it's just you're publishing your own gems or scripts onto your own GitHub, I think it's important. I feel they most people, especially if it's a senior engineer, we go through all their GitHub projects and like the comb through GitHub. That's actually more important than the resume. So get some stuff up there. Just some examples. It's like your portfolio. Yeah, so the question is about giving homework to candidates before they come in. It's actually interesting because we've just iterated on what we used to do. So we used to come in and give you a cold problem and have you sit down and try to solve it on spend one hour coding. And we found we're getting better results though by sending that out early and say it worked on the problem. And then when you come in with what you've solved, then we can ask you to iterate on we'll ask you questions about something, maybe add an additional feature or something. But we found that we're actually getting better results by sending the homework out. So what are some of the best questions that we've been asked in the interview and how maybe how we can determine that they're going to be the best asset for our team. I really like and that's personal because you're trying to make a connection with the person interviewing you. I love it when someone's asking me what I do, maybe why, how long have I been there and why have I been there so long, what's great about the company, how I work, and kind of so it's just a lot of interest in what we're doing. The question, the worst question to ask are what can you do for me or what are you going to teach me? If they're me centered questions, those are turned off. But if you ask them if you're asking what we're doing and how the team works together, I think those are fine. Those are the best questions. Just a personal question about what I'm doing, what am I trying to solve? And so she's asking about the length of time of the homework. And we have had debates about that because you don't want to force someone into like eight, nine hours of their own time just to apply for a job. So we're still iterating on that as well. I think the project we give, you can do an hour or two of sitting down and just kind of putting something together. And we don't expect a full blown out solution. We kind of expect based on your skill level the approach that you've taken. But that's definitely something you can ask. If you're given an assignment from any company, especially the HR person, just say, hey, how much time do you expect is reasonable to expect that you put into this? And if a company is expecting you to put in 20, 30 hours, right? That's a lot of commitment. So I wouldn't expect that. So the question is, how do you help if you're the interviewer and your candidate freezes? How do you kind of make them more comfortable? One of the great ways to do that is to kind of just switch. If they're frozen, kind of talking about Ruby, switch. Maybe like, what do they do in the personal time? What are their hobbies? And kind of see how they approach those. A lot of times people have these hobbies that they're real passionate about that they'll geek out on. And then that's actually just as good. You can kind of hear about how like if they homebrew beer, how do you do the beer? Like, tell me all about the process and what's involved. And that's a lot of like engineering and problem solving, too. And then that makes them more comfortable with you. Then you kind of get back to the Ruby and the technical pieces. How do you come up with them? Yeah, that's a hard problem. And I think through my research I feel like nobody, because I've worked with some big companies, too, and it doesn't seem like they, I've never been given like, these are the questions we ask. It's almost like every engineer it's left up to them to come up with the questions that they're going to use. And a lot of people are lazy and they're just going to sort of say, oh, these sound like three questions I can use. And honestly, it's the approach. How the person approaches the problem. So the question is not, being correct with the question is not actually what I'm looking for. I'm looking for how they approach the problem. But I do usually have a backlog. Sometimes I'll interview candidates and they'll say, oh, I've been asked this one before or I can answer it if you want. Or you can come up with another one. So I usually try to have two or three that I ask. But I think for when you're interviewing, the important thing is you ask the same question to multiple people and you'll see the different approaches. And sometimes when I ask, I have a couple of algorithm questions asking, if someone pulls out something that I've never heard before, it really like, it's like, I'm like, this is great. I just had never thought of that approach before. I'll be around the conference. There's a few other anchors here and we can kind of talk to you and we'd love to talk to you about interviewing and maybe give some tips and resumes and things or you can hit me up on Twitter at CMR. Thank you.