- 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.
So put 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 Ruby on your laptop.
From when you're learning,
you're sitting at your laptop, focus on the screen, typing.
Soon as you come into an interview,
the first thing we're gonna do
is we're gonna 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.
There's nothing more awkward than we're staring at your back
while you're quietly noodling a problem.
After you've practiced solving some problems,
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 the corner.
You don't have any space if you have to
make annotations or insert code,
so always start in the dead center
and that way, you have space all around
if you have to make annotations on your code.
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.
Matz is talking on Wednesday.
Or sorry, Tuesday.
And listen to these people,
and if you don't have time to see them here,
later confreaks, 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,
a lot of project leaders,
and they have an amazing back catalogue
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 in Ruby 2.3?
"Are you guys thinking about using it?
"What do you think about that Law of Demeter?
"How does that work?"
Maybe real spot, 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 gonna 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 could start a war in this room 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 were 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 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 your 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 gonna fail before you 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 developers 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 jacking in the Matrix, we're typing,
we're doing what we love.
We're solving problems.
Manager's gonna 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 gonna get up and we're gonna 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's slow.
If you have a problem, yo, I'll solve it.
That's what we do. (laughs)
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 gonna meet with
came from other languages,
maybe Java or .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 talk to you and then go to our manager
and say, "Hire this person,"
then we're done doing the interview portion
and 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 whiteboard
and solve problems together?
Then, will you and I be able to go back,
sit at our desks, 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 a Lannister 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's gonna come to me
and say, "How much Ruby does this candidate know?"
So we're gonna 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.
If you only have time to learn a few things,
make sure you know .each, .map, and .inject.
All questions probably will start
with a .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,
'cause 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_t0, and the has_many:through.
I guarantee you most questions
somehow end up being the has_many: through
or the classic has_and_belongs_to_many.
Now then there'll be a series of questions.
These are the algorithm questions.
This'll be a question like,
"given 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 answering 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 it bruce 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've 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 algorithm
so 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 times the next loop
has to iterate.
Know how the web works.
A lot of people ask, "How does the web work?
"What happens when you type a URL in a browser?"
Be able to explain what happens when
you type the URL in the browser,
the request response cycle,
what happens on the server,
the processes, 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, maybe I can figure out how much a cubic foot
"of ping pong balls is."
Then you can kinda 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 interviewer 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're asked 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.
Near the end of the interview,
when they're wrapping things up,
usually they'll turn to you and say,
"Do you have a question for us?"
Always ask a question.
Have the questions 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
"Java script 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.
(audience applauds)
We have plenty of time to answer some questions,
if anyone has any questions about interviewing,
finding a job, resumes,
Ruby.
Yeah, that's a good typical one.
Let me turn to you.
Have you ever been asked one of these hard questions?
(audience member speaks quietly)
Oh okay. (laughs)
Well, you can Google for a lot of these.
Don't Google for that, but you can find a lot of examples.
That's one of them.
I mean, there's a lot of
legendary ones like why are manhole covers round?
Typically they're logic questions,
like you're given a series of light switches.
How might you solve a problem?
Maybe best if you kinda 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,
how many windows are in the buildings in Seattle?
That's another one.
Right, so she's asking is there another resource
besides a 700-page book on cracking the code interview,
and that's the best resource I've found
for at least the questions
and then you just have kinda search around
and try to solve some of those problems.
There's 189 algorithms in that book,
so it's kinda hard to know every one of them
but if you just know the series of 'em
and how you would approach each one of those.
I mean, a lot of times, the question's about
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.
It's just get the problem on the board
and then start trying to optimize the algorithm
and it becomes actually repetitive patterns
if you've done a lot of them.
You'll start to see it's kinda 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,
hired great people that didn't have any schooling,
and I've hired people who've had bootcamp 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
enthusiastic, like "teach me everything you can.
"I'm 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't's for blogging.
I would say do blog.
It's a great resource.
It gives you time to format 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 it's 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 might look at things and ask you questions about it.
So you're asking how many people come in cold?
A cold call?
(audience member speaks quietly)
Okay, yeah, if we get a cold resume,
you have to remember
we get hundreds of resumes maybe a day.
We get a lot of resumes.
The ones that stand out are the ones
who've kinda researched our company
and maybe they write a nice cover letter
to attach to the resume
and 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 to all the companies,
but if you have something that's kinda personalized
for what we're doing.
Another secret is to go to local meet up groups.
Every developer that work with us,
they actually go to a lot of the local meet up groups
and you can usually find someone.
And just make a connection,
and you can CC 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 could improve,
and I think that's great.
You're helping us solve the problems
that we're trying to solve.
That's a great introduction into the company.
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 think most people, especially if it's a senior engineer,
we go through all their GitHub projects
and like to comb through GitHub.
That's more important than the resume.
So get some stuff up there,
just some examples, just like your portfolio.
Yeah, so the question is about
giving homework to candidates before they come in.
It's actually interesting because we 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.
We found we're getting better results, though,
by sending that out early
and saying, "work on the problem."
And then when you come in with what you've solved,
then we can ask you to iterate.
They'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 he's asking what is some of the
best questions that we've been asked in an interview
and maybe how we can determine
that they're going to be the best asset for our team.
I really like, and that's personal,
'cause you're trying to make a connection
with the person interviewing you.
I love it when someone's asking me about what I do,
maybe how long have I been there,
why have I been there so long,
what's great about the company,
how I work?
I kinda told you,
just a lot of interest in what we're doing.
The worst questions to ask are what can you do for me,
or what are you going to teach me?
The me-centered questions,
those are turn off,
but 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 the personal questions about what I'm doing,
what am I trying to solve?
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 in an hour or two
of sitting down and just kinda putting something together.
We don't expect a full, blown-out solution.
We kinda 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 is it reasonable
"to expect that you put into this?"
And if a company's 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 just switch.
If they're frozen talking about Ruby,
switch maybe to what are their hobbies?
And kinda 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 that's actually just as good.
You can kinda hear about how,
like if they home brew beer,
like how do you do the beer?
Tell me all about the process and what's involved.
And that's a lot of engineering and problem solving, too,
and then that makes them more comfortable with you.
Then you get back to the Ruby and the technical pieces.
How do you come up with them?
That's a hard problem.
I think, through my research, I feel like,
'cause I've worked at some big companies, too,
and it doesn't seem like,
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 gonna search
and say, "Oh these sound like 3 questions I can use."
And honestly, it's the approach.
How the person appraoches a problem.
So being correct with the question
is not actually what I'm looking for.
I'm looking for how they approach the problem.
I do usually have a backlog.
Sometimes they'll interview candidates
and they'll say, "Oh I've been asked this one before.
"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 algorithm questions that I ask
and if someone pulls out something
I've never heard before,
it really, 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 Inkers here
and we can kinda talk to a few
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 @cmar.
Thank you.
