Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
- Hi, welcome everyone. Before I get started today, I just want to say, who is a Ruby expert that's in this interview? That's in this session? Okay, great. So this is about Ruby technical interviews. My name's Chris Mar, and I'm a software engineer at CustomInk.
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 boot camp or an 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 it's 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 on 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 Devise. Every company you interview with is going to be using Devise. After you've been, you 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've taken 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 the Gathering 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, like go see it, see my source code on GitHub.
And we'll be able to go over to GitHub and we will take a look and see what you've done. Now when you invite someone to your house, you usually will 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's 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 Duck 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, a 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 built to the duck. Then, find some nontechnical people in your life, and describe your project to them. Maybe even 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 meet up 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.
Okay, so all the learning you've done, the code school, the boot camps, and your passion project, that's going to fill up 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.
Now 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 in 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, 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 he called the most pedantic pull request of all time.
He went around to a lot of big projects on GitHub and explained to them that they were using the em-dash for their range of years in their license instead of the grammatically correct en-dash. Super pedantic, 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 a secret: most developers are lazy, and when you come in, we're just going to read straight down your resume, ask any questions. So you have the opportunity to construct the conversation before you go in.
[ ... ]
Nota: se han omitido las otras 2.815 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.