DAVID MALAN: All right.
So welcome to CS500's third annual prep and practice for technical interviews.
As you all know, the goal of the session is really to better prepare you
as you go into maybe your first or your second year or third year of interviews
just feeling more comfortable, more confident, and more aware
of what kinds of questions you might get asked and also
to get you some feedback and some thoughts on how best to structure
resumes, things to do, and not to do.
And we're super excited to have two of our friends from Quora here,
Ryan and Tommy.
Tommy, of whom was one of CS50's head TFs just a few years ago.
And if you took CS50 a couple of years ago,
odds are you were using a lot of the software that Tommy himself wrote.
He's been at Quora since doing amazing things in mobile and software
engineering, more generally.
And so we'll now turn it over to them to take us away thanks.
[APPLAUSE]
TOMMY: So as David mentioned, my name is Tommy.
I used to be one of the head TFs CS50.
And since then I've been at Quora.
I've been on a bunch of different teams.
I've worked on mobile.
I worked on performance.
I'm currently leading our platform teams.
So platform you can think of as basically internal engineering
and productivity.
So we work on things like tools for full stack engineers
and distributed systems for machine learning engineers-- basically,
a lot of the foundational stuff that a lot of Quora is built on.
I'll let Ryan introduce himself as well.
RYAN: Yeah, hi, I'm Ryan.
I'm a software engineer here at Quora, so I work on our machine learning team.
So I kind of focus on those e-mails you might get
from us, our digests, our main feed.
So working on the ranking algorithms and the performance assistance that
drive that at Quora.
TOMMY: Awesome.
So as David mentioned, today, we're going
to go through a workshop focusing on all aspects of the technical interview.
Technical interviewing can be really intimidating and scary.
There's not a lot of sort of direction of what's going to happen.
So really, the goal of this workshop is to help
you understand all different parts of the process, what's going to happen,
what you can expect, and then lots of strategies and tips
and tricks along the way to help you prepare
and be successful in those interviews.
So this is what we're going to be covering today--
basically, sort of an end to end process for the interview.
So things to do before the interview, how to prepare for the interview,
during the interview itself, what to do after the interview,
and then we'll have lots of time at the end for Q&A. If you
have questions, anything specific to your situation,
happy to answer those questions.
We'll do a couple of mock interviews as well.
So to start, let's talk about before the interview itself.
So before interviewing, the first decision that you clearly have to make
is choosing companies to interview with.
You probably don't want to interview with every single company out there.
You don't have the time.
You're probably wasting their time as well.
So this is sort of an important first step during the interviewing process.
So I have here five questions that you probably
want to ask yourself as you're choosing companies.
So the first one is, what are you looking for?
Whether it be an internship or a full-time job,
I think everybody is looking for different things.
So some people in their job really want to focus on impact
and want to work at a company where they can
have a really strong impact on the product,
not just work on some small corner of some larger system
but really take a lot of ownership, drive a lot of things themselves.
Other people want to focus on learning.
Maybe it's your first internship, and it might be hard
for you to jump in and have a lot of impact.
And you just really want to focus on learning a bunch about the industry--
sort of soaking up as much around you.
Maybe you want to think about work-life balance.
Maybe you want to go live in a new location for the first time.
Maybe you're like me, you're from Boston.
You've never been on the West Coast before.
You want to try a West Coast internship, want to try a New York City internship.
That's all fine.
That's something that some people want.
I know some people care about money.
This is something that might matter to some people, not to other people.
And none of these is really more important than the other.
So a lot of times, when you're interviewing,
you'll see a lot of sort of peer pressure from your friends of,
oh, you've got to interview at this place, or you can't go work there.
That's so lame.
I wouldn't think about that.
Everyone is really, really different and what
everybody is looking for out of an internship or even
their first job out of college is really different.
And so recognize that and make sure you're asking yourself
what it is that you're individually looking for.
So second question you ask yourself is would you
be excited to get up every day and work on this product
since that is something you are going to be doing
is getting up every day at 9:00 or 10:00 AM
and working on this product for a long time.
So you want to make sure that you're actually
excited to work for this company.
So in many consumer companies, it's really easy to just go use the product.
If you enjoy it, it's something you could
see yourself contributing to and being excited about working on,
that's a great sign.
Other companies, that their product might not
be super available, especially if they're
in the enterprise space or you're working
on something that is a little hard to access,
or you wouldn't use much as a student.
That's totally fine.
Just learning about the company's mission
and what their high-level goals are as a company
and what they're trying to do in the world also sort of paints
a picture of what their day to day work is going
to be like if you were to work there.
So these are always super publicized online in their about page or whatever.
Companies are pretty public about their mission
and explaining what they're trying to do to the world.
So the third is whether or not you'd be excited to get up every day
and work with the people at that company.
So that's another real thing.
You could be working on your favorite product,
your favorite product in the world.
But if the people that you're working with you don't like
or you don't collaborate well with, now that's
not going to be a great experience-- so that's
a really important part of the equation.
And the best way to get signal on this is during the interview process itself.
You're guaranteed to be meeting with several different people
from that company during the interview process
and so think about how those conversations are going.
Every interviewer will say do you have any questions for me about the company
or about my journey here?
Really, really, really take advantage of that.
I've had so many people when I say do you have any questions for me?
They just say like, no, I'm tired--
not a great answer, one, from my perspective but also from theirs
because they're really missing out an opportunity
to understand what it's like to work at Quora
or work with me with anyone else on the interview loop.
So this is also a really important thing.
This is the thing that's a lot harder to get a sense of.
You can't just go to like quora.com/careers and suddenly
understand what it's like to work with the people there.
You only get this by interviewing so make sure you
capitalize on that opportunity.
Also once you have an offer, this is another really, really great
opportunity to talk with a lot of people from the company.
If a company gives you an offer, that means that they want you to join
and they're going to put in a lot of effort to make sure that you join.
You're probably and to have offers from three or four different companies
who are sort of competing for you to join their company.
So that means if you're in that situation, you've got a lot of leverage
and you can just sort of ask like, hey, I am
thinking about these different things.
Do you mind if I talk to some PM or your head of business or someone
on a design team or the head of engineering or something?
If companies gave you an offer, they're going
to be really willing to put in that time for you
to meet other people from the company.
You can ask them questions and learn about their role, how
you'd fit in at the company, what that day to day is going to look like.
Oftentimes, recruiters will ask like hey,
is there anyone you want to talk to you?
Can I set up these conversations?
Some companies call them reverse interviews.
Some companies call them sale chats, which is a little more direct.
If a recruiter doesn't ask, just ask them.
Chances are, they'll be really willing to do that for you.
So fourth, you want to make sure that the things
that you value align with things that the company values.
So you can think of company values as basically
what some company values more than other companies out there.
So for example, probably a lot of companies value like
don't steal stuff--
not all of them but probably most of them.
And that's not really a value because like every company sort of values that.
So when companies talk about their values,
they're talking about what differentiates them
from a lot of other companies out there.
So again, these are really easy to find for basically any company.
You're just looking at their careers page.
They probably shove them in your face during the interview process, which
is good because you know what they are.
Here's an example-- so these are Quora's five values.
So one, everybody at Quora is really mission first.
We really believe in putting the team and the company over yourself,
so the achievement of a team in the company
is much more important than your own individual achievement.
Second, we value drive.
So people who take a lot of initiative, have a lot of autonomy,
don't sort of sit around and wait for someone to tell them to do something.
They go off and do things themselves.
Value agility-- so the ability to quickly pivot and change our approach
or direction to solving some problem.
We value awareness.
So we're a very data-driven company-- so being aware of different data,
being able to make rigorous data-driven decisions.
And finally, pragmatism-- so people here are not perfectionists.
They're OK cutting corners, delivering something that's 80% as good,
so they don't waste the remaining 20% of the time.
So those are Quora's five values.
It sort of paints a picture of the type of people who work at Quora
and what it would be like to work there.
These are not sort of objective truth.
Like this is just this is how Quora works.
Think about how you work, think about how you value,
and see how much that aligns with each company that you're interviewing with.
In some cases, you might see a values mismatch.
You might, for example, really value transparency and understanding
everything going at the company, and some other company might not
value transparency at all because they're really big,
and they know they can't share all that information.
So that's just a values mismatch.
That's totally fine.
It's not a poor reflection on you or the company probably.
So but the more you're asking yourself that question,
you can sort of understand where you're going to fit at different companies.
So finally, really easy question to ask is just how big
is the company because your experience as an intern or a new grad
is going to depend a lot on the size of the company.
So this is a cool table that Dustin Moscovitch, who's the founder of Asana
put together.
So I can't claim to have created this, but it's really good.
And you can basically think of a lot of companies in the tech space
in the Bay Area, in particular as having categorized into one of three buckets.
The first one is a really small company, so this
is your seed series A, series B-ish company probably around 50 people.
The second is the midsized company, so this is sort of series C or D-ish
somewhere in the range of 50 to 500.
It's sort of big here.
It's like 50-300 ballpark.
On the left is just everybody else-- so sort of like the large companies.
This could range from some company like Square,
which is like 2,000 to some companies like Google, which
is like an order of magnitude more than that.
And then here are sort of like the axes of how
things are going to be different.
I'm not going to walk you through this entire chart.
So one good example is autonomy.
So at a really small company--
this could be a company that's like three people--
you basically got to do whatever.
Some companies you have to like go assemble your desk on the first day
or like go be a salesperson one day and then be a PM the next day.
And that's really appealing to some people.
But if you're the type of person who just wants to go and learn,
this isn't necessarily a great way to learn
because you have to figure everything yourself,
and you may or may not get feedback.
At a mid-sized company, the autonomy is less than that but still not too small.
So basically, teams are given some high-level mandate.
So here your team's goals for the quarter.
I'm not going to tell you how to achieve those goals because I
got to go somewhere else, but it's your job
to figure out how you're going to hit this metric or ship this product.
But you know that you have to go hit that metric goal or ship that product.
And then, finally, at a really big company, you have a lot less autonomy.
You're just sort of given a to do list and say go.
You have a very clear list of tasks.
You can evaluate your success very easily.
Did you do the tasks or not?
There's a pretty big range there.
I think another one is the mentorship one,
so this is a lot of what new grads and interns look for.
So a really small company, there's going to be basically none.
You don't have time for that.
When you're really small company trying to ship a product,
you might not exist next week.
You don't have time for a lot of mentorship--
maybe that's OK, maybe it's not.
At a midsized company, there's some structured mentorship.
On day one, you apply get assigned a mentor.
Some companies have sort of a bootcamp process.
You can try a bunch of different teams but ultimately,
focus on delivering some project later.
And then really large companies-- they have these really established programs.
I think, for example, Facebook has a program called
Facebook University that's a very structured learning process.
It's explicitly learning driven, and these really big companies--
they have time for that.
They can make that investment because they have many more resources,
but a company that's at a different end of the spectrum
can invest in various mentorship.
Yeah, take a look at this chart.
There's lots of other ones there, but those, I think,
are two good ones to highlight.
So let's jump into resumes first since this is sort of something
before the interview process is you're going to be submitting your resume.
So resumes are not that important.
A lot of literature out there suggests that resumes are extremely important,
and you've got to spend a ton of time getting the wording exactly right
and make sure you use like a 12-point font size.
It's probably because they're like 13.5--
whatever.
So resume is not that important.
So to start the question, who has a guess for how long
me, as a hiring manager, is going to spend looking at your resume?
Yeah, just shout it out.
AUDIENCE: Five seconds.
TOMMY: Five seconds?
AUDIENCE: 10.
TOMMY: 10.
OK, people are a little aggressive.
I'd say, on average, I spend like 30 seconds.
Five seconds, I can say good font, but I can't actually read any words.
So anyway, we're not that bad.
We spent around 30 seconds on a resume.
I think we'll spend more than that if something looks interesting,
or we want to dive a little deeper.
But we're not going to spend a ton of time on this.
So keep that in mind as you're designing your resume.
If you have a choice between practicing some new interview problem
or like spending two hours on your resume,
definitely don't pick the resume.
So I have here 10 easy rules that if you follow them,
your resume will probably not be bad.
And again, that's your goal.
So here you go.
Rule number one-- one page.
There are absolutely zero exceptions to this rule.
Super senior engineers, people who have been
in industry for 20 years, the inventor of Python, for example--
the resume is one page.
If the inventor of Python can get it on one page, you can too.
Do not break this rule.
I'm not going to read past the first page.
Second, make it really easy to skim.
If I'm looking at your resume and I'm struggling to see where you've worked
or where you've done or what you did, I'm just going to give up.
I'm only spending 30 seconds on it.
You've got to like maximize the efficiency of my 30 seconds reading
your resume so just make it really easy to see where did you
work, what you do, what year are you, ate you looking for an internship
or new grad position, which I can just infer by graduation year.
You don't need to tell me that.
Just make it really easy for me to skim in 30 seconds.
Third, your contact information should be the easiest thing
to find on your resume.
The whole point of giving me your resume is
so that I can contact you later if we want to move forward with the process.
Some people don't have any contact information on their resume.
Some people put it in a really small font at the bottom,
and I have to search for it.
And then I get annoyed, and that's not good for you.
So make it really easy to contact you from your resume
because that's why I have your resume.
So this is sort of the duh ones.
So fourth, make sure you're highlighting specific accomplishments
from past internships.
Some people say, oh, I worked on this team.
OK, great.
I don't really know what you did.
That doesn't really pique my interest.
But if you say I worked on this internal tools team
and shipped a new tool to a team of 50 that increased productivity
by reducing this bottleneck by 30%, that's much better.
So it's more specific.
I can see what you're actually doing, and that's
going to make me more interested.
Obviously, some companies have confidentiality rules,
or you sign an NDA that prevents you from doing this.
So don't break any confidentiality rules here.
But a lot of things like some high-level metric,
you could say you know I 2x'ed the throughput of the system.
If you don't say what it was before and after,
you're not breaking any confidentiality metrics.
So fifth, include interesting personal projects.
So if you're working on some side project,
maybe you're a member of a student group or something
and you develop something on your own or with some friends,
definitely include that on your resume.
Do not include standard final projects.
It's pretty common that we'll be at a career fair,
and it's really clear what the final project for some in show class
is because 50 people built like collaborative pong or something.
That's not a side project, and it sort of
looks lame because it's sort of introduced like what else did you even
do?
Probably nothing-- so I wouldn't advise doing that.
But if you do have interesting personal projects--
maybe the final project is more open ended,
and you could build something that wasn't just sort of the standard
template thing-- include that but don't just include like had you'd like CS50
problem set three, which some people do, so don't.
And I know what problem set three is so definitely don't.
So number six, do not have charts or ratings next to skills.
This is egregiously common.
There is absolutely no value in telling me
that you are like a three out of five team player.
So which again people do, so do not do that.
Again, there's absolutely no exceptions to this rule either.
I don't care what role--
just don't do this.
Seventh, you don't need an objective.
A lot of people at the top of their resume
may say like my objective is to seek a challenging
position in the field of software engineering
where I can apply my skills.
I don't care.
I know.
You're wasting space on resume.
I don't read it.
And if I am reading it, it's probably not because I'm interested in it.
So don't include that.
You're wasting space.
Similarly, a lot of people put in the resume
a somewhere like references available on request.
Again, you're completely wasting space.
I know-- if I want a reference, I'll get one.
You don't need to tell me that they're available upon request.
You're wasting space.
You only got a page.
So number nine, if you don't have a professional looking email address,
just create one.
I get a lot of ridiculous looking email addresses
that people had like in high school very clearly
or something just first initial, last name something.
It's really easy.
You look really silly if you don't do this-- so just do that.
And then finally, if you have relevant links-- so maybe your LinkedIn
that's filled out and looks good.
If a GitHub contains some personal projects, those are great to include,
especially 95% of resumes we're getting digitally, so we can click on links.
If you're printing out a resume, links aren't that great but include them.
It sort of allows me if I'm interested.
Or maybe I'm interviewing you in five minutes,
and I want to sort of get a sense of what you've been working on.
I can click here to your GitHub, say, oh, this thing looks cool,
and we can talk about that for a few minutes
during a technical phone screen.
So if you have them, include them.
OK, so we have two example resumes.
I want you to tell me based on those 10 rules what is good
and what is bad about this resume.
So if you raise your hand, if you have something good or bad.
Yes?
AUDIENCE: It's really clear where you worked before and [INAUDIBLE]..
TOMMY: Yes, it is very easy to skim.
You can see like clear headings.
Here's the experience.
He's the CEO of something.
He's got a hell of a career path.
You can see his education.
It's really, really easy to skim so that's definitely good.
Yeah?
AUDIENCE: Contact information's right there.
TOMMY: Yes, contact information-- very easy to find.
He has these nice icons in case it wasn't clear
that this string of numbers is a phone number, but it's really easy for me
to find.
Yes?
AUDIENCE: One page?
TOMMY: One page-- excellent.
Did not break the one-page rule.
That's the easiest one to not break.
Yeah?
AUDIENCE: Bad because of the skills.
TOMMY: Yes, this is what I mean by skills, reading this is ridiculous.
This person is a three out of five team player.
It's a little blurry, but that is literally what it says.
This is a complete waste of space.
I'm not even sure I want to work with a three out of five team player.
I think my bar is probably like a four.
So this is totally, totally wasted space.
Other stuff-- good or bad.
Yeah?
AUDIENCE: [INAUDIBLE]
TOMMY: Yeah the photos are useless.
Unless you're like an actor and trying to get an acting role.
This is not going to have any bearing on my hiring decision.
Again, wasting space.
How about one more?
Yeah?
AUDIENCE: There's a lot of profile like there's a big paragraph.
TOMMY: Yeah, so that's exactly what I mean by an objective, so I don't care.
I didn't even read this.
I could say well, [? I'm ?] [INAUDIBLE] for all I care.
I don't read this.
Do not do not include this on the resume.
It's a total waste of space.
So that's resume number one.
How about resume number two?
Good or bad?
Yeah?
AUDIENCE: We got some more skills.
TOMMY: Yeah, this time, they're not stars.
We got a continuous scale instead of a discrete scale this time.
But again, really, negotiation is four out of five-- not great.
Other stuff-- good or bad?
AUDIENCE: [INAUDIBLE]
TOMMY: It's sort of similar, I think.
This is like sort of easy to skim.
You've got this weird like the content sort of flows
like this, which you probably don't want.
There's also this discrete scale down here, which is lame.
Again, like the headshot, not great.
Contact animation is very easy to find.
The content here is that is actually pretty good.
There's like very specific metrics like increased CSAT by 25%.
So that's actually pretty good.
But again, there's sort of a lot of unnecessary stuff on that resume that
breaks the 10 simple rules.
OK, so that's it for resumes because we're not
going to spend a long time on it because, again, it's
not that important.
So let's move into the types of interviews.
We'll have time for questions at the end, actually.
We're saving a bunch of time for that.
OK, so let's just talk through some logistics first.
So with interviewing, start interviewing as early as you can.
It's pretty common for interns and new grads
to interview sort of like late summer, early fall-- so basically now.
A lot of people will actually interview for like job I plus one
or internship I plus one during internship I.
So like over the past summer, we interviewed lots of interns
for like the next summer, so they wouldn't have to like fly out.
So some people do that.
You don't have to.
As long as you're sort of starting around now if you haven't yet, it's OK.
You're not in trouble yet, but I wouldn't
wait three or four months more.
Just try to find an internship.
Something else to do is plan interviewing into your schedule.
Interviewing is basically another class.
So I wouldn't advise taking like five classes,
like two of which are really hard during the same semester you're
trying to do your recruiting.
You're going to have to make trade-offs against one of them,
and you don't want to do that so just sort of plan it into your schedule.
Be aware that this is going to take a lot of time, particularly in the fall.
And also, look for programs that are targeted for your year,
like I mentioned before.
But a lot of these larger companies, like Google or Facebook or Microsoft,
they have programs targeted at freshmen who
have never had an internship before.
If that's you, you've just taken a couple of CS classes.
You haven't had an internship before.
Those are the programs you should look for.
If you don't and you try to apply to these other programs,
you're going to be competing with juniors
who just have two or three years more experience on you,
and you're going to have a lot harder time being
successful in those applications.
At career fairs, try to talk to recruiters.
Say, hey, I'm a sophomore.
Here's my experience.
What roles do you recommend I look into?
Or even explicitly asking, do you have roles for freshmen?
A lot of these big companies will say yes.
A mid-sized company like us will probably
say we don't have a role just for freshmen,
but we also hire freshmen if they're great.
A small company might just say no.
So try to have that conversation with the recruiter
early on, so you don't end up on the wrong track.
So basically, what the process will look like from end to end--
many companies will start with a coding challenge.
They'll sort of give you a technical problem.
There's a lot of different products out there.
You'll probably have like 30 minutes or so to write some code.
You'll get sent into some auto-grader, which will notify the recruiting
team if you did a good job.
It will probably take around 30 minutes for these.
Make sure you set aside a quiet space, and you can solve the problem.
Some companies don't have this, and they'll go directly
to a technical phone screen.
So this will be 45 to 60-minute conversation--
usually, with an engineer.
For a lot of new grads or interns, it could just
be some random engineer at the company.
It could be an engineer who actually works on the team
that you're applying for.
It sort of depends on those tracks.
If that goes well, then some companies will do a second phone screen,
and other companies will bring you directly to the on-site.
The on-site portion, again, it's going to vary by company.
You should expect around three to five different conversations.
Again, each of those is going to be 45 to 60 minutes each.
You'll meet with lots of engineers if you're applying for an engineering
role, but you might also meet with someone like me, a hiring
manager, maybe a designer, a PM.
Again, it's really going to depend on the company and the team
that you're applying for.
But that's basically what you can expect for an interview process
from end to end.
So here are five types of interviews that you're probably
going to encounter during this process, and I'm
going to briefly walk through each of these.
So the first one is my least favorite, which is the algorithms interview.
It is unfortunately-- well, for me--
the most common for interns and new grads.
So an algorithm algorithms interview is basically
a technical problem where you're going to be given some problem.
You have to write code for a solution, but the problem
is more about discovering the algorithm and getting to that high-level solution
than it is to actually code it up.
So for example, we might ask a question where the algorithm
is sort of hard to come up with.
But once you come up with it, it's like trivial right out.
It's maybe like five lines and some crazy like recursive cool thing.
And the actual hard part is coming up with that algorithm.
So if you find yourself in an interview taking a really long time to come up
with the algorithm and you're sort of like stressed because you haven't
got any code yet, it could be OK.
That could be by design.
The problem could be you are supposed to spend 20 minutes thinking of a solution
and brainstorming and then just five minutes of writing it up
and then it just works.
So just be aware that that's sort of a class.
When you're solving these types of problems--
and this is what we'll focus on the most today--
try to optimize for both time and space complexity.
Something you shouldn't do, though, is right out of the gate try
to find the absolute best solution.
It's OK to start with maybe a naive solution, a quadratic runtime
or exponential runtime that you know isn't like the optimal solution,
but it's much, much, much better to come out
of an interview having written something than struggled for 60 minutes trying
to get this optimal solution and getting nowhere and ending
the call with you not having written any code
or gotten anywhere towards the solution.
So spend some time trying to optimize upfront.
But if you don't see it and then three or five minutes
after you see the naive solution, just start there-- write it up and then go
forward.
Something you should especially do is tell the interviewer that.
Say, hey, I've got the solution.
I think this is a naive solution.
But do you want me to just write this up first?
95% of the time, they're going to say, yeah, let's write that first,
and we'll try to optimize it later.
Because as an interviewer, I want that signal too.
You just sort of like sit there struggling for 60 minutes.
It's hard for me to be confident whether or not we should move forward or not.
So the more signal that you're giving, the better.
Another thing with algorithms problem, the solution seems too complicated.
There's like 50 different edge cases that you're trying to take to account.
It probably is, and it's probably wrong.
So try to think about creating the simplest solution possible.
Look out for ways that you can remove edge cases
or further generalize the solution that you come up with.
So, again, we're going to have much more detail on this interview
later since this is the bulk of what you're
going to be doing in the process.
So who can tell me some common classes of algorithms problems-- so
sort of like categories these might fall into.
Yeah?
AUDIENCE: Search
TOMMY: Yeah, search problems-- so like a graph search problem.
That's a good one.
Yeah?
AUDIENCE: Greedy algorithm.
TOMMY: Yeah, greedy algorithm-- that's a good one.
Yeah?
AUDIENCE: Dynamic programming.
TOMMY: Yeah, dynamic programming-- super, super common.
One more?
So here a couple that I came up with.
So the first is string manipulation is super common.
So sort of knowing how your language of choice works with strings,
how to reverse a string, index, substring, blah, blah.
Recursion, super common-- a lot of greedy stuff
can be as formulated as a recursive problem.
Dynamic programming-- talked about.
Graphs and cheese, which basically the search problems.
Now my least favorite categories, which basically math.
We try to avoid these, but not all companies
do where the solution just requires you to know some like math
thing off the top of your head, and there's
like some closed form solution you're supposed to get.
They're unfortunate, but they definitely out there.
And a lot of interview books will have a section dedicated to just this.
So the tools for solving these problems that you should really
have down off the top of your head going into this interview.
The principle here is that the less time you
have to think about how to create an array in your programming language,
it's one less thing that you're like worrying about
during the interview process.
So tools you should be aware of for solving these problems--
how an array works, how to write up an array in your language, how
linked lists work, hash tables.
You want to know the built in string methods off the top of your head.
You want to be familiar with memorization and basic caching
abstractions within your language of choice.
Know some sort of shortest path stuff off the top of your head.
A lot of stuff you can generalize into just you can fit it into a graph
and then just like run a search algorithm on that graph
and knowing this fundamentals of the top of your head
is really going to make your life a lot easier,
and this is a really good list to start with.
This is going to cover a lot of algorithms problems that you get.
OK, so that's algorithms.
So next is the coding problem, and it's basically
the inverse of an algorithm problem where
getting the algorithm is probably pretty simple but then coding it
up might be a little more complex because there's a lot of nuances
in the implementation detail.
Maybe it's just a lot of code to write, but this
is a problem where you might see the solution immediately.
If you see a solution immediately, you should probably think to yourself, OK,
I'm going to spend a lot of time writing code now
to make sure I can cover everything.
So a couple tips here.
So the first thing--
you want to decompose the problem as much as possible.
Something interviewers look for is the quality of the code you're writing.
If you just like write a single function that has 200 lines,
me, as an interviewer, I'm going to look at and say, OK, well,
we hired this person.
This is probably what they would do on the job, which we don't want.
So really make sure that you're thinking a lot about code quality, not just
the correctness of your code but the design and style as you CS50.
So do things like create helper functions appropriately,
think about how you can simplify the code even more.
If an interviewer has to prompt you like,
hey, do you see any bugs, that means we see a bug.
Or do you see a way we could make it simpler?
That means we can make it simpler.
So try to get ahead of that and be proactive and look for bugs
and look for those code quality improvements yourself.
And again, familiarity with the language is going to help you a lot here.
We'll cover that a bit later.
So the third type of interview is the practical interview.
So broadly, the interview is you'll be given an actual code base
and, often, sort of a large code base.
You'll be asked to make some changes to it.
So you could be given some app that has a bug in it,
and your job is to just like, never having seen this code base before,
go and find the bug and fix it.
This is really, really different than implementing something from scratch
because what this interview is trying to get
at is your ability to reason about an existing code base,
your ability to navigate code base, understand
how different pieces of the system fit together.
This isn't super common, but a lot of companies
will do this, particularly on the smaller end.
So some tips for this one-- so really take
the time to understand how different pieces of the code base fit together.
So there could be three or four different modules that are used,
and they're not all going to be relevant.
But the three that they are relevant, try
to understand sort of at a high level why they exist
and how they interact with each other.
That means you're going to spend more time reading than writing.
In a 60-minute interview, you could just read code for like 40 minutes,
find the bug, and fix it in two, and then that's your 45-minute interview.
In order to be successful here, you should
be familiar with some development environment.
Some companies will say, hey, bring your laptop,
get ready to code in whatever development environment you want.
Some companies will say OK you're going to use our laptop,
but we're going to give you these three or four different tools.
Be familiar with something so that you don't have to worry about an interview,
how do I set a breakpoint or what's the shortcut for doing this in the editor?
Just be familiar with something.
So again, it's one less thing you've got to worry about in the interview,
so you can focus on the problem solving itself.
A lot of these tools will have stack traces in the tools.
So if you're ever wondering you're inside some function.
You're wondering how did I even get here?
A trick I like to do is just like throw an exception
or just like divide by zero and then run it,
and then you'll get a nice stack trace of how you got to that function.
So that can be pretty useful in understanding
how these pieces interact.
The fifth is a systems design interview.
Again, it's not as common for interns and new grads, but a lot of companies
still ask it.
You could basically think about these in two categories.
The first is some technical system design.
So someone might say how would you architect the Gmail app?
What they're asking you is what classes would
you create how those classes interact with each other.
What are all the parts of the system that need to exist?
Or it could be a product design question--
could say what feature is missing from Gmail?
If you're applying to a product role or even an engineering role
with a heavy product focus, you'll probably
have to answer questions like this.
So some tips there--
the first thing to do is understand the constraints of your system.
So you should never start by going right into design.
You should start by asking a bunch of questions.
So if someone says how do you architect the Gmail app,
start asking a bunch of questions like, OK,
what constraints do we have to worry about?
Do we have to worry about network latency?
Do we have to worry about low-end devices?
Do we have to worry about the enterprise use case or just focused on consumers?
And just ask a bunch of questions like that to really narrow down the space
that you're thinking about.
So you if you try to think of a too big of a space at once,
you're just not going to make a ton of progress.
Second thing is be aware if any assumption you're making.
So for example, especially if someone asks
a question about some common product.
You might have a bunch of assumptions because you
might have used that product or had some ideas about it.
Just sort of state those out loud.
You could say like I'm assuming that we're working about the Gmail app
on mobile.
And by app, you don't mean desktop.
So yeah, I'm just worried about mobile.
But if you just go off and only think about one platform.
Your interviewer actually wanted to do some sort of cross-platform thing,
you just wasted a bunch of time going the wrong direction.
So state any assumptions you're making out loud.
Verify them with the interviewer.
There's really no downside to doing this,
and you really make sure you're on the right track.
Then, next, think of the consequences of any decision you make.
So you could say you know I want to introduce
this class that does this think about what are the consequences of that?
Does that mean that this other class is like suddenly harder to do?
Does that mean that this other feature now can't be accomplished?
So you don't just sort of propose one thing.
Once you propose something, then think about one step ahead
and the consequences of doing that because if you don't, your interviewer
is just going to do it for you.
You might sort of catch yourself making mistakes
before your interviewer has to point them out.
Along the same line, challenge your own ideas.
Again, your interviewer is doing this every interview.
Their job is to poke a bunch of holes in your system,
and your job is to make sure that there aren't that many.
So the more you're challenging your own ideas,
you're going to discover weaknesses and limitations of your solution that
sort of cover those proactively, which is much better than an interviewer
just sort of telling you exactly what's wrong.
And finally, just along the same line, just
consider how future proof anything you're doing
is, that you're not painting yourself into a corner
because then an interviewer can introduce some new use
case five minutes later.
Then suddenly, you're in trouble because you didn't think
about what could happen in the future.
And the last one is culture.
So this is often called the behavioral interview.
Probably going to be happening towards the end of the loop with someone
like me, who's a hiring manager and what we're trying to figure out here
is essentially what are your values and do they
align with the values of this company?
Again, this isn't an objective thing.
People have different values, and companies have different values.
So we're just looking to see if there's going to be a fit.
And ultimately, what I want to know is if we hire you
as an intern for next summer, will you be successful?
Because we want you to be successful.
You also want to be successful, and so we want to try to match that up.
So rarely will I say something like what are your five values
because that's not a good question.
So the way that we get this signal is a sort of two categories.
The first is looking back, and the second is looking forward.
So by looking back, that means we're going
to talk about your past internships and projects.
If you don't have any internships, that's fine.
You've taken classes.
We're probably going to talk about those.
If you have taken internships, be prepared
to talk about your most recent ones since that's probably
the easiest for you and the most interesting for me.
Some questions I might ask are what went well in your past internship?
What didn't go well?
If you tell me like nothing went well, it was the worst.
Yeah, well, I'm a little worried about hiring you.
If you said everything went well.
It was perfect.
I'm still a little worried because I bet it wasn't.
There's five things you could have done better.
I want to talk about the hardest challenges you faced.
I also want to talk about how you overcame them,
so we can see your approach to solving hard problems.
So having an example off the top of your head is really great.
What I really like is you know what would you have done differently now.
So if you were to start this internship over today
with the benefit of hindsight, what would you have done differently?
We would like to see people who give us a lot of fire and reflect
and can self improve.
So these are the types of questions you should be ready for.
Think about these in advance you don't have to think of something on the spot.
These are easy to prep for.
And then the other half is looking forward.
So basically, this job or this role that you're interviewing for-- let's talk
about that.
So really easy question is what makes you interested in this company?
If you say, well, I don't know.
Like I live next door--
which someone has said to me in an interview--
not a great answer, and we're looking for something
along the lines of maybe you really like the product,
maybe you really like the people, maybe there's
other things you're considering.
So we want to hear about those.
We want to hear your honest answers.
What do you want to work on?
Some people come in saying, I really just want to work on front end.
That's my goal.
Other people say, yeah, I don't really know.
I'm sort of flexible.
Again, we just want to hear this and hear that you've thought about it
and make sure that there's a role and ask about your goals--
either for this internship or sort of your long-term career goals.
And they might ask what are important aspects of culture to you,
particularly if you worked at some past internship that
maybe went well or didn't go well.
I want to hear sort of organizationally what happened there.
So in preparing for these, definitely take some time to reflect like I said,
you don't have to come up with these on the spot.
Think about them in advance, have some stuff ready.
One framing I like to think about in preparing for these, just
think about your ideal day.
As an intern, what does your perfect day look
like in terms of what you're doing, who you're working with,
the types of projects you're working on, the environment around you--
all that kind of stuff.
It is a really good jumping off point.
Avoid being overly negative about the past, even if you did
have a not so great internship experience, really
not a good move to sort of rent about it in an interview.
As an interviewer, if someone's ranting to me about some past internship,
my first thought is, well, if they don't have a good time here,
they're going to do the same thing.
And that's not going to be good for us.
So just don't-- it's OK to be honest and say, OK,
here are some things that went well.
Here's some things that didn't go well.
But don't just sort of go off on a rant.
And finally, if you're under an NDA and you
can't talk about where you worked on, that's completely fine-- just say so.
Some people don't say that they're under an NDA or just sorry,
I can't talk about that.
And I sort of like dance around it, and I'm just
sort of like, well, I don't even know-- maybe you're
just like a bad communicator.
So if you have an NDA and you can't, a lot of people don't say that.
So if you are, that's totally fine.
I can't look down on you.
It's not your fault. It's not a reflection on you.
If you said, yeah, unfortunately, I can't talk about that,
but I can talk about that this other thing.
OK, so I'm going to hand it over to Ryan.
RYAN: All right.
So yeah.
So now we're going to talk a bit about the interview itself,
and we're really going to focus in on the technical interview, which
is kind of I guess the thing that a lot of people
get really stressed and intimidated by.
So first, let's talk about how do you prepare for your interview?
So there's two ways you can think about this.
You can think about in the short term like you
have an interview in a few weeks.
What are you going to do to get ready for it?
And you also kind of think about the long term like planning ahead.
Like in the next few years, what do you want
to do to make sure that you're going to have the best career opportunities when
you graduate and for the next summer?
So let's start with the short term.
So I think one of the biggest things is just
to get really solid in your basics.
So if you're looking at some problems, you
want to make sure that you have a language that you know really well.
You know how to do everything--
all the basic operations.
So say you want to know how to get the characters
of a string in your language.
You want to be able to let's say make a graph in this language
and be able to define a class, an object, a node.
You want to be able to sort some numbers.
You want to be able to do that basic stuff so
that when you're in the interview, you don't have to like fumble
around and think, oh, how do I do this?
How do I do that?
You really want to just have as few concerns as possible
so that you can really focus in on just what the interviewer is
asking like looking at the algorithm, looking at your coding,
looking at your style of your coding, as opposed
to worrying about the basics and the syntax of the language.
So yeah, so few of the things I mentioned here
you want to insert, remove things from linked lists,
sort array, print stuff, BFS, DFS, know how
to use a hash table, a dictionary in Python, for example.
And I guess one thing I'd add onto here is try and pick
a language where this is really easy.
I have some people who try and interview in like C++,
and they just take a really long time to write their code.
They don't know C++ super well.
They like did one class in it.
I really recommend, if possible, try and learn
like a nice interpretable language, something like Python, JavaScript.
You can really iterate quickly on a kind of interview well in.
So another really big thing is to do a lot of practice.
So you can do practice problems from the internet.
There is a lot of sites about this.
I'm sure you've all heard of like--
I don't know-- there's like Hacker Rank and all these other things
where you can go on the site and just find a ton of problems.
I think this is a really good way to start.
I think we're giving out some Cracking the Coding Interview books at the end
too.
There's a lot of good problems in there, and you
want to kind of identify common patterns that you
see over and over in these problems.
And one thing I'd suggest when you're doing these
is to really practice efficiently.
So when you're doing the problems, don't just try it for like five minutes
and say like, oh, I have no idea what's going on.
I'm just going to go look at a solution.
I'm going to memorize the solution.
So don't do that.
I know a lot of people prepare like that.
I mean, it kind of just prepares you to do the same thing in the interview.
You run into something you haven't seen before.
You're like, oh, I don't know what to do.
I'm going to freeze.
I can't look up the solution now.
So you don't want to be in that position.
You really want to train for what you're going to do in the interview.
So I really suggest like taking maybe like 30 minutes
when you're doing these practice problems to try and really
focus in and figure out how you can learn from the problem
and learn how to do it better the next time and be kind of like retrospective
after you finish the problem and look into what you're going to do next time.
Another thing is make sure you're looking at a variety of problems.
Don't just focus on graphs or just focus on dynamic programming.
You want to get a very wide range because you really
don't know what companies are going to ask you ahead of time--
all the things that Tommy mentioned about earlier.
There's also a lot of different data structures, you should know.
Mainly, I would say probably hash tables, graphs composed of nodes,
linked lists, maybe a tree of sorts.
So basically, when you look at a problem,
you kind of want to iterate over all the different things you can do
and figure out which one makes sense.
One thing I see that people sometimes kind of do
is they kind of go down one route really,
really deep at the beginning of the problem,
and they're kind of just going down the wrong route.
So when you look at a problem, you want to have
an idea of all the big variety of things that you
could be doing for this problem.
So you kind of want to start and think like, hey, does that make sense to you?
Does a hash table make sense here?
Does it make sense to make a tree?
What are the different options I have?
And I kind of like to start with kind of a breadth first approach
because, usually, when you have a problem,
it's not going be super complex.
We don't have time to write like a 400-line program.
Usually, the solutions aren't too complicated.
So if you try it and it's not working out too well,
it's a good idea to just try something else
and really look at all the different options
before really diving down into a single one.
And this is, I guess, I think it's just a lot of the things we've
talked about earlier.
I think it's actually a duplicate slide that maybe something went wrong here.
And lastly, you want to really be focusing
in on what you're not doing well.
So if you're [INAUDIBLE] probably don't do practice over and over.
You want to focus on what's not going well.
So if every time you do a dynamic programming
problem you don't feel like you can't get it,
just practicing a ton of dynamic learning problems,
and eventually, it'll start to make sense--
cool.
Yep, and lastly, try to practice in a realistic setting.
So as much as possible, you can having your friends give you mock interviews.
There's some tools online, actually, where you can even go,
and real people will interview you.
I think it's like coding--
I can't think of the name--
interviewing.io, I think.
And you can kind of really practice with real people.
I think there's a lot that changes in a real coding environment.
You get nervous, and you kind of freeze.
And you kind of want to practice this ahead of time
so that when you go into a real interview,
you kind of feel at ease because you've done this so many times.
Yeah, and this is kind of what we talked about earlier.
You really want to try and take a long time on these problems.
Don't just look at the problem and get the solution, memorize the solution.
Focus on how to train yourself to how to problem solve because that's really
what we're going to be looking for later in the interview is your problem
solving ability, and it's not like have you memorize how to write Dijkstra
and C++.
That's not what we're looking for.
We're kind of looking for can you take a problem
and take it apart and know your toolbox and kind of solve the problem that way?
Yeah, so figure out what went well.
Ask your friends for feedback.
One small note here is sometimes people ask us
for feedback at the end of the interviews.
We usually cannot do this just because we are afraid of saying bad things
and getting sued for some reason.
So you'll have to ask your friends ahead of the time.
A lot of times, people ask in interviews.
I can't.
It's kind of awkward.
I can say like, oh, I think it went great.
The recruiter will get back to you later,
just because I can't tell you, unfortunately.
So I think another big thing is the long term.
So you can kind of cram a bit for your interviews
but what's really going to make you a really good candidate is actually
being really good at programming because that's
kind of what we're looking for in the end result.
The algorithms interview is kind of supposed
to be a proxy for how well you can do your job.
So the best thing you can do is just get a lot of experienced programming,
and this can come from a lot of different sources.
It can come from doing things like your practice problems.
It can also come from your classes--
so taking a lot of data structures and algorithms classes,
doing these mock interviews, and really just
working on becoming a better programmer.
I think algorithms sometimes nowadays get
this bad rap of like being kind of this one-off thing
that you just prepare for the interview.
I think that's ideal if that's not the case.
I think for good companies, the interview
is really trying to judge how well you are at programming
so just get better at programming.
To a degree, you can think about it like if they're not
testing how well you are at programming, do you really
want to work there or those people that you
want to work with, if they're just like testing how well you can memorize?
So really focus on just getting better as a programmer in the long term.
Cool, so now we're going to talk specifically about how
does the technical interview work.
So what is the structure?
What can you expect in the algorithms interview?
So first, we have the preamble.
This is kind of often is kind of a shorter
version of what Tommy talked about earlier with the culture interview.
So we're going to ask you what have you worked on before.
We might ask you about like maybe you describe a challenge you've had
in the past and how you resolved it.
And in this case, we're really looking for the same things earlier--
like how well do you work with a team, how well do you communicate.
So oftentimes, the way this will work is we'll just
ask you a bunch of things about your resume.
Like, hey, I see you've worked at Microsoft on their search team.
Can you tell me a bit about what you did on that team?
And you should be ready to really talk about what you've
done at your past products or your past internships
and prepare to give good answers.
One thing I would suggest this kind of thing
about why you did things that previous internships.
Sometimes I'll ask someone, hey, why did you decide to use
Redis in your internship project?
And I'll get an answer, it's like I don't know.
My mentor told me to use Redis, so I did.
So that's not a great answer.
You really want to try to have a solid understanding of everything you've
worked on and be able to have a good conversation with your interviewer
about the choices you made and how you thought about things, maybe
about how you asked on your other on your team on suggestions--
all that sort of stuff.
One thing, though, do try to keep it short.
Something to remember here is that the main point of this interview
is to judge your algorithm skills and your cooking skills.
So if you stand like 20 minutes tell me about your previous internship
and I like keep trying to interrupt you say,
hey, we should start doing the algorithms and stuff.
And it's like keep talking.
I've had people that do this somewhat frequently.
You're not going to have as much time to do your algorithms section,
and it's going to reflect poorly on you because we're doing
our best to kind of normalize for this.
But at the end of the day, we can only see what you actually get to code.
Something that we'll get to, the main meat of the interview--
the technical problems.
And specifically, I'm going to be talking about the algorithms section
that Tommy mentioned here, not so much the coding.
So I'm going to talk a little bit about why do we do algorithms interviews?
I think maybe if you read on the internet
that these interviews these areas get a fair amount of criticism
from people saying like, oh, these are like not reflective
of real-world coding.
So why do we give all these interviews?
Why is everyone in the industry giving algorithm interviews?
So I think the root of it is that we're really
looking for some common knowledge among all students.
So when we're looking for a new grad or an intern,
we're not looking for someone who can immediately start and like takeover
running our infrastructure.
We're really looking for someone who can work at the company for several years
and kind of learn and grow as an engineer.
So if we just go and we ask you like the details of how AWS EC2 instances works
in an interview, maybe that tests your knowledge,
but it's kind of like it's not going to be equal for all students.
It's not really going to predict how well you're going to learn and grow
as an engineer in the future.
So that's kind of why we kind of focus on this data structures
and algorithm because everyone takes a data structures and algorithms class.
So it's kind of this common expectation.
And so we're using it as this imperfect proxy.
We know it's imperfect, but we haven't found anything better.
So we're going to keep doing it.
So what can you expect?
There's at least one coding problem focusing
on data structures and algorithms.
You may get more in the interview.
You will never get less.
So there's five things you should really focus on here.
One of them is explain your algorithm, your approach, and its correctness.
So you should do this before you start writing your code.
So don't just start writing and then when you're done,
all I think this works.
Some people do this.
You should think about it, maybe even draw it on the whiteboard or something,
and talk to your interviewer and make sure they
understand that what you're saying.
You should be able to analyze the space and time complexity of your algorithm.
This is in terms of O notation.
So this is how much memory does it take in RAM?
How long does the program take to run as the input size grows?
You should be able to write clean code in the editor or on the whiteboard.
So some people don't realize that we're looking for this.
They think that we're just looking for the algorithm.
Even when it is an algorithms interview, you should still be writing thing code.
We'll talk a little bit more about this later.
On the whiteboard sometimes, you can shorten stuff
just because you don't have as much space
but still try to write as clean as possible.
And lastly, in some coding interviews, you also
may have to actually test your code.
I think it's becoming increasingly common,
especially with lot of phone interviews nowadays,
that you actually run your code in an environment
and verify that it's actually working.
And then lastly, we're going to have this closing,
and this is really time for you to ask questions [INAUDIBLE] I'm
talking about a lot of this stuff earlier
really just make sure that you're actually asking questions.
You're still being judged at this point.
Some people don't realize this.
They think it's all about the algorithms.
I think maybe it's perhaps overemphasized nowadays.
There's actually a huge portion of your interview,
which is really just focused on the culture and the culture fit
and similar.
So make sure you ask good questions here.
Don't ask like I've had someone ask me like is your office in the Bay Area?
Please do like basic research ahead of time.
You shouldn't be asking this stuff at the end of the interview.
Yes, so I think Tommy has covered this a bit, so we'll skip this for now--
cool.
TOMMY: We're going to do our first mock interview.
We're going to do an interview where Ryan is going to interview me.
Then we're going to talk about what went well and what didn't.
And then after that, go into a bunch of sort of more formal tips
and tricks and strategies for the technical interview itself.
RYAN: So this is a tool called Coderpad.
I don't know why it put Python 3.6 a bunch of times, but it did.
It's a pretty common tool that people will use for technical phone screens.
You sort of login, and you'll get a shared link with your interviewer.
And they'll be on one end talking to you.
You'll be on this end.
You can both see the code that you're writing.
OK, so Ryan is going to interview me, and then we'll go from there.
TOMMY: Cool.
RYAN: Hey, Tommy.
How's it going?
TOMMY: I'm here.
RYAN: Actually, we're you skipping the preamble?
I think you did it last time.
TOMMY: Yeah, just go.
RYAN: OK, cool.
So we're going to skip the preamble.
So we also have like 10 minutes talking about Tommy's background.
All right, cool.
So let's get started with the problem.
So today, your task is to make a program that takes as an input an integer,
and then you want to use the n Fibonacci number in binary format.
Does that make sense?
TOMMY: Yep.
RYAN: So do you want to talk about your program?
TOMMY: No, no, no, no, no.
RYAN: All right.
TOMMY: Yeah, one second.
OK, that's the Fibonacci, and now let's do the binary.
Yeah, and that's the spinner.
RYAN: Do you want to test it maybe?
TOMMY: It's going to work it's like--
that's right.
RYAN: Did it run?
TOMMY: Do you want that or no?
RYAN: Yeah, you can just try printing a sample test-- maybe like three.
TOMMY: Fine.
RYAN: You said three, but I'm going to do five because I like five better.
All right, that's a couple of ones, so that's binary.
So if I think about the fifth of the fifth Fibonacci number,
well, it's zero indexed.
Obviously, this for the fourth, so 0, 1, 1, 2, 3.
Well, I mean, 3 is 3 is 1 1 in binary, so that's it.
TOMMY: Let's try eight maybe?
RYAN: Why?
TOMMY: I think we should just try some other outputs.
RYAN: There you go.
TOMMY: That's not quite right, is it?
RYAN: All right.
Oh, yeah, I know.
I know.
I got this.
No, I don't.
TOMMY: So one thing to notice is that there's
no ones or zeros in your output.
RYAN: Yeah, I know.
I know.
It's because that if I just flip-flop these--
TOMMY: So why don't we try stepping through the program?
RYAN: Yeah, I mean, well, I mean, you can't.
There's the fib, And then there's the binary,
and then you do them in that order.
So this was it.
TOMMY: OK, we'll cut there.
I know really, really stellar.
Let's talk about what went well and what did not.
So [INAUDIBLE] raise your hand.
Yeah?
AUDIENCE: [INAUDIBLE]
TOMMY: Yes, do not listen at all.
So the interviewer is trying to help me along and say
like here you should try this case--
sort of tried to guide me and I just sort of ignored him entirely.
What else?
Yeah?
AUDIENCE: The code is recursive instead of entered in.
TOMMY: Yeah, that's pretty good.
The code makes no sense is sort of how I'd generalize that.
Yeah, the code is just flat out wrong so don't do that.
Other things that didn't go well or did?
AUDIENCE: [INAUDIBLE]
TOMMY: Yeah, exactly.
So you could see that what I did is I made an assumption.
I made a bunch of assumptions.
I didn't clarify upfront.
I assumed that like at zero indexed.
Well, I said it was zero indexed, and then I
didn't start by asking any questions.
With Fibonacci, that's like a very obvious clarifying question.
I just sort of jumped in and didn't ask any of that.
What else?
There's definitely other things.
Yeah?
AUDIENCE: Your attitude [INAUDIBLE]
TOMMY: Yeah, so I was very flustered or stressed out.
When it didn't work, I just sort of like freaked out
and started changing things randomly.
I didn't really reason through the code to try
to understand what's happening. was sort of flipping random signs
and hoping it was going to work.
At no point did I explain what my code was actually doing
or try to run through in my head and explain my approach.
I just sort of kept running it, changing random things, run it again,
which doesn't really give anyone confidence that I
have any idea what I'm doing.
How about one more, good or bad-- yeah?
AUDIENCE: In test cases, you didn't do extreme values
or probably like negative one.
TOMMY: Yeah, definitely.
Ryan actually suggested a test case that I ignored,
and then this piece is by no means comprehensive.
And I just sort of like printed it out.
That's not a great way to do that.
So I didn't edit reason through edge cases at all.
So, OK, so let's jump back and talk about concretely some strategies
and things to do differently--
cool.
RYAN: Yeah, so that was not so great.
So let's talk a bit about what should you do.
So we talked a bit about what the negative examples here.
So what you should do is you should make sure you understand the problem.
It's extremely common that as an interviewer, I will ask a question,
and the interviewer-- does not actually immediately understand the problem.
So one good way to do this is to take an input
and make sure that you and the interviewer
agree on the output of that input.
So for example in this Fibonacci program,
it would have been good if Tommy had verified there was zero one index
and verified like hey how do you want this?
Should it be three or should it be 1 1 1 for input 5 or what not?
And you should also ask some clarifying questions.
I think you can save yourself a lot of time here by just making sure that you
really, really, really understand the problem.
A lot of times, people think it's more complex then
it really is, or you need to handle more test cases.
You can say, hey, do I need to cover negative numbers as well?
Do I need to handle the null case?
Do I need to handle like very, very large numbers?
And it gives you your interviewer a good signal
that you know what to look for in a program
as well when you're asking these questions.
Let's talk a bit about brainstorming.
So we touched on this a bit earlier.
But one thing to remember here is that your process is
really more important than your output.
If the most optimal solution requires a heap and you're just like not
familiar with the heap, and you find like some suboptimal solution that
uses like a sorted list, you're not going
to get dinged much on that at all--
maybe not even at all.
If we're really primarily looking to see how well can you
reason through a problem, we're not looking
have you memorized this algorithm, have you memorized the data structure.
Those things you should do because it makes it easier
to get through these problems, but that's
not the goal of the interview the goal the interview
is to understand how well you operate in a real programming environment.
So you should go through a couple of different approaches
starting with the easiest thing.
So get the brute force solution.
Try every possible input and just run a verification on it.
Start with that because sometimes maybe that's like the best thing
that the interviewer is looking for.
I've had interviewers ask me questions that were
like how to close form solutions, but they didn't
want to know the close form solution.
They just wanted me to do a search implementation or something similar.
So really, even if you think it's really simple,
you just state that the simplest solution first and then go from there.
Drawing diagrams and test cases helps a ton.
I would suggest if you're doing a phone interview, have paper next to you.
I find it's a lot easier to diagram trees,
diagram your stream problems on paper, as opposed to using your laptop.
It's just so much faster to iterate, especially
on something like a graph problem.
And when you're doing your interview, even
if you're going to code on a laptop and there's a whiteboard there,
it's good I guess to just draw it out on the whiteboard.
Not only for your own benefit but also so
that you can kind of explain your process
to the interviewer who is trying to understand how well do
you work through these problems.
And lastly, make sure you do explain at a high level what
your approach is going to be.
Don't just like start writing your code.
Make sure your interviewer and you agree that's a good idea
to write the solution before you start doing it.
Let's talk a bit about writing the code too.
So again, just like the last slide, your process
is more important than your output.
So we're really looking to see how well can you work through a coding problem.
We're not looking, for example, do you know
whether reverse is a function of a string or it's like a function
that you call on a string.
We're not looking to see like how well you know your programming
language in super depth.
We want to know do you have familiarity.
We don't want to know like do you know the ins
and outs of every part of that programming language.
So secondly, your code really does matter so do not
call your functions foo, bar, and baz.
If you've had programming foreign language background,
you should not just like use single variable programming variable
names because you're trying to show your interviewer
what are you going to be like when you're on the job.
So name your tables reasonable things.
I also find that this actually really helps me
when I'm coding as well so especially when we're on the whiteboard,
for example.
You might need to like run through your code in your head.
It really helps me if I've named my variable
as something that kind of makes the program read like English.
So for example, like if I have a complex logic statement like if A and B or C
and D, I'll try to break it up into subparts like is number prime,
is the string greater than two length.
And some of this stuff makes your code longer,
but it really helps you kind of understand what's going on
and read through it and verify that everything's working correctly.
A big one is you should break your functions into helper functions.
So if you can break down your problem as much as possible
so you can test it in small parts, it'll really
help you when you're going back later and your debugging it,
either in your head or on a real computer.
So for example in the Fibonacci problem, it
would be really, really good to define multiple functions, make a function,
take something goes from decimal.
It goes to binary, produces the nth Fibonacci number--
so break down your code.
You'll find this helps a lot when you were on the job
as well if you write a really complicated program with really
big state, It's going to take for you forever debug your program at the end.
So try and keep everything as kind of separate and discrete as possible.
Yep, so when you're coding on the computer,
it's really, really hard to get things to work correctly on the first time,
but you also want to make sure that is eventually correct.
So there's kind of this trade-off here.
As we talked about earlier, helper functions will help a lot here.
And one thing I suggest is that when you're writing your code,
actually add your debug statements as you write your code.
So the first pass when I go through my code sometimes,
I'll just include print statements, so I can
verify that things are working as I expect, as opposed
to going back and debugging later.
I find this actually helps a lot for initial program writing speed.
And lastly, some final tips just in general, you really
want to over-communicate, as opposed to under-communicate.
Not only does this save us from this awkward silence where we just sit there
and watch you code.
It really helps with the thing we talked earlier about the process
that we're trying to understand what you're thinking.
And if you run into a problem, it helps us understand that like, hey, I'm
thinking about this thing.
I haven't just like frozen.
I can't remember how to program or something.
So try to communicate as much as you can.
And remember, lastly, that it is not all about just writing
solving problems and writing code.
All the other stuff that we'd mentioned earlier about like being a nice person,
communicating well, explaining your ideas is all really, really important.
I think a lot of this gets lost nowadays over focus on the algorithm itself.
And let's talk a little bit about debugging on a whiteboard.
There's some practical things you should watch out for.
Just plan your code ahead of time.
You do not have to worry about these practical things
because you have a fixed time limit.
So try to not run out of space.
Write things-- you want to spend a little bit more time planning
when you're going to write on a whiteboard
because you can't refactor it quite so easily.
And you really want to practice debugging by stepping through
in your head because you're not able to have print standard and what not.
I think it's actually a really good skill that I actually
end up using my job as well because it takes a really long time to compile
larger programs nowadays.
So this can be a very useful skill.
You can do it by just doing one of your practice problems
and then trying to figure out, is it going to be correct
before you run the code because that's kind
of what you have to do on your whiteboard problems to a degree.
Cool, so now we're going to try a second mock interview
where Tommy is going to interview me.
TOMMY: OK, so keeping all those things in mind, we go to a second interview
here.
I'll start fresh.
So this time, I'm going to interview Ryan.
And again, we'll talk about what went well and what did not go so well.
How's it going?
RYAN: Hey, It's going great.
How are you?
TOMMY: Great.
RYAN: Good to hear.
Are you ready for some technical problems?
TOMMY: Yeah.
RYAN: OK, cool.
So for this first one.
Let's start by you're going to write a function,
and it's going to take as input some number.
And it's going to output the nth Fibonacci number in binary.
TOMMY: Cool, let's see, so for Fibonacci numbers, I would be going from 1 1,
2, 3, 4, 5, I'll just give an example here.
Do we say that the top is the value, and the bottom is the index?
Is that what we're looking for?
RYAN: Yeah, that's right.
Let's go with that.
TOMMY: Cool.
Let's see here-- so I think I'm going to first break it into two parts.
We're going to start by computing nth Fibonacci number.
I think I'll do that iteratively and kind of build it up with an array.
RYAN: OK.
TOMMY: And then I'm going to do a second part.
I'm going to transfer that number from decimal to binary.
Does that make sense?
RYAN: Yeah, that sounds good
TOMMY: Cool, let's get started here.
So first of all, to make the entry point, we'll call it fib binary.
And we'll just leave this empty for now.
So first, let's make a function that takes in a number and returns
in a Fibonacci number.
So we know that a basic Fibonacci number is f of n equals fn minus 1
plus f of n minus 2.
So let's see.
So if we were to do that just fully recursively,
we'd probably run a stack space for a large int.
So I'm going to try and do it iteratively and maintain our array.
RYAN: Sure.
TOMMY: So initialize it with the size of the number of elements.
Let's see-- and we'll start from zero and build up.
So for i in range--
all right.
And then we'll return the last element.
And because we iterate up to n, we'll return n minus 1.
RYAN: Sure.
TOMMY: Cool and then next, let's take a decimal number
and convert it to binary.
Now we're making to a string.
RYAN: Yep, string.
[INAUDIBLE]
TOMMY: So I think the way we'll do this is I'll just repeatedly divide it by 2
and take the modulus of a number by two.
So that should get me the trailing 1 or 0.
And I'll iteratively build up the number from there.
So we'll do while decimal is greater than two,
ret plus equals decimal modulo two.
I'll make this into a string, and then we'll divide by two.
And then we'll finally return the result. [INAUDIBLE] say it,
and we'll add some test prints as well.
So we should be able to get--
the fourth Fibonacci number should be three, so we'll print fib of four,
and it return three.
And then we'll do the same thing down here.
I guess we'll will turn three into decimal.
So this should return 11, I think.
OK, so let's start.
Let's run that and just verify that that works.
RYAN: OK, and just for a time, let's pause there.
So let's hear feedback.
So what went well and then what didn't go well?
Yeah?
AUDIENCE: [INAUDIBLE]
RYAN: Yeah, exactly.
So you sort of say upfront here's what I'm going to do.
Does that sound right?
Yep, here are the inputs and outputs.
Does that sound right?
Yep.
And so he sort of communicated throughout what
his process is going to be.
What else?
Yeah?
AUDIENCE: [INAUDIBLE]
RYAN: Yeah, exactly.
So we sort of like broke it up into two very clear functions.
It's very clear what each of these functions does.
You can read through it and understand it very easily.
So this is pretty clean code for the solution.
What else?
AUDIENCE: If the [? code's ?] correct, this is pretty suspect.
[INAUDIBLE]
RYAN: Yeah, this isn't correct.
We just got to cut it short because we are a little short on time.
But yeah.
What else?
Yeah?
AUDIENCE: The clarifying questions.
RYAN: Yeah, exactly.
So he clarified right up front what he wanted to do and not do.
It was good.
How about one more good or bad.
Yeah?
AUDIENCE: Put it in separate functions.
RYAN: Yeah, sort of like nicely decomposed easy to follow.
Yeah.
AUDIENCE: I have a question.
RYAN: Sure.
AUDIENCE: Say a possible solution doesn't come to you immediately.
Is it OK to kind of take some time to think ti yourself or do
you recommend just talking before-- like talking through it to find a solution?
RYAN: Yeah, if you can talk it through, that's always better.
Some people would just sort of like-- it really doesn't get to you.
Just like, oh, do you mind if I take a minute and draw something out?
I have some paper here.
I think that's sometimes fine.
We're biased towards always talking out loud if you can.
We'll save some more time for some questions at the end.
So let's just wrap up.
OK, so final section is the shortest one is after the interview.
One thing to keep in mind is that interviews are really, really high
variance.
Companies, like Google, do a lot of actually
like A/B testing and experimentation from their HR department
on some of the stuff.
So people have found that there are lots of really, really great developers
who just don't do well in some particular programming interview.
That's totally OK.
So if you have some coding interview and it doesn't go great,
don't get discouraged.
It's totally fine.
I'll never forget the first technical interview I did.
It was it was for Facebook.
And it was really simple-- just like traverse a binary tree.
And I was taking 51 at the time, and I'll do this and OCaml.
And it just like completely, completely exploded.
The interviewer was like what are you doing?
And I was like I don't know what I'm doing, actually.
And then it was terrible.
And then I remember he was talking to the other interviewer
like in the elevator.
I could hear them joking how badly I did, which was like fine.
Like everybody bombs these.
It's totally, totally fine.
So anyway, don't get discouraged.
The more practice you do, the more this is
going to really start to come naturally to you.
When you're writing code, speaking out loud and coding, it's not normal.
Like you wouldn't it when you're on the job.
You probably don't do this, or the people
like next you're going to think you're weird.
So it's really unnatural.
It's nothing that comes easily to a lot of people.
But the more you practice and the more you just sort of go
through lots of reps of different practice problems,
actual interviews are really going to help
you the most-- other mock interviews with your friends or things
like workshops like this.
You'll sort of naturally start to develop these skills,
but you're not going to be great out of the gates.
That's totally fine.
It doesn't mean you're a bad programmer.
Your career is over.
This stuff is hard, and it takes some time just to really practice through.
So just want to end with some takeaways from today.
The first thing you should do, if you don't already,
is pick some programming language that you were
going to interview in and learn it.
So all those data structures we talked about,
all the different functions we talked about, sort of like syntactic sugar,
just learn all of that for some programming language.
Do not think above that during your interview.
Next, fill up that toolbox--
so not just language specifics but know the difference
between a breadth-first search or depth-first search.
Know just how to write that if you really
need to know the basics, the runtime for accessing a hash table or a linked
list.
Just know this stuff off the top of your head.
Third, do lots of practice problems.
This is really the best way to learn, and I wish there was some sort
of shortcut you could take-- or maybe I don't because it makes my life harder--
but you can't.
You just really have got to like do a bunch of practice problems
and repetition and invest in that.
When you're doing so, practice talking out loud.
It feels really weird, but you just sort of get used to it eventually.
And finally, keep interviewing.
It's something that takes a lot of time.
You've got to go through it and fail some interviews.
Everyone does.
And that's really the only way to get better.
So I'm providing everyone at the workshop with this book.
So this author is actually pretty prominent on Quora.
This book is the best interview prep book out there.
It's got tons of practice problems categorized into the things
that we talked about today.
So dynamic probing problem, strings, recursion-- whatever--
so that it helps you understand what classes of problems
that you're not great at, and so it enables you to focus on those.
And so that's all we have.
We wanted to save lots of time at the end for Q&A.
And so if you've got any questions for us
about sort of specific interview stuff, we'd love to talk about them right now.
Yeah?
AUDIENCE: So what you were saying something about breaking skills,
for example, you have more experience working
in some programming languages versus others, how can you address that?
RYAN: Yeah, so as an interviewer, it probably doesn't matter to me,
actually, like your relative skill on various programming languages.
For most interns, we don't expect you to come in knowing some technology down
really well.
We expect that you'll be able to learn a bunch on the job,
and you don't need to be an expert in React Native going
into your internship.
We just expect you've got your fundamentals,
and you're able to then learn that programming language.
So what matters most is just the language you're going to interview in.
Doesn't matter too much about like the relative skill sets outside of that.
AUDIENCE: Should we not list languages that we're not
comfortable interviewing in?
RYAN: Yeah, I think it's not a bad idea.
I think some sort of like mean interviews
have this rule that's like if it's on your resume, I can ask you about it.
So if you put assembly on your resume, we're
going to make you do a problem in assembly.
That's sort of lame, but it exists out there.
So broadly, listing languages in like the order that you know them in.
Some people like to say proficient or intermediate or whatever.
I mean, my personal view is that it doesn't matter all that much.
But yeah, don't list a bunch of stuff in your resume
that's untrue that you'd be uncomfortable talking with.
But I think if you list the language and interviewer says,
oh, let's do this language, you can say, oh, I took it for this class,
and I don't know it super well.
I'll be happy to give it a go, but this is the language
that I'd prefer to interview in.
Yeah?
AUDIENCE: [INAUDIBLE]
RYAN: Sorry, what's the question?
AUDIENCE: Should we list any relevant classes we're taking?
RYAN: Oh, should we list any relevant classes you've taken?
You certainly can.
In particular, if you don't have a lot of internship experience,
there's not a whole lot to put on your resume,
listing classes is pretty helpful.
Many times, the people like me who go to a school and talk to people
will have gone to the school as well.
So if you say something like I took CS 125,
that's like a meaningful thing to the interviewer.
So it really doesn't hurt, especially if you don't have a lot of stuff else
to put there.
Other questions?
TOMMY: I'd definitely put like if you TA'd the class as well
or if you've taken particularly like advanced graduate classes.
I think it's definitely a signal.
RYAN: Yeah, if you're taught a class, that's really, really great to see.
If you're taking like graduate classes, that's great to see.
Yeah?
AUDIENCE: If you really don't know how to do a question they ask,
is it fine to be honest if you [INAUDIBLE]
RYAN: Yeah, so what do you do if you don't see it?
Yeah, so a lot of interviewers want to help you,
and so they have hints prepared in their back pocket.
So if there's some question and you don't really see it,
you could say, hey, you know what.
Think out loud with your process.
OK, will this work?
No, this isn't going to work.
Will this other thing work?
Well, maybe it won't.
In an interview, one could like guide you based on that
and say, oh, well, actually, what if you do this, then does that approach work?
Yes.
Or sometimes say, hey, I'm honestly not seeing it.
Do you mind giving me a little bit of direction?
Interviewer will say, oh, sure.
What if you think about it in this way?
I definitely wouldn't say like, yeah, I don't know I'm packing it in.
Interviewers want to help you.
And so you say, hey, I'm not sure.
I'm sort of stuck right now.
Do you mind giving me a little bit of guidance
or do you have a hint to point me in the right direction or something like that?
Yeah?
AUDIENCE: Is it bad to Google something if you can't debug your code?
RYAN: Yeah, that's a good question.
Is it bad to Google something if you can't debug your code?
It is only bad if you do not ask.
So if you're doing a phone interview and all of a sudden
I hear like silence on the other end and like typing.
And I'm like, hey, what you doing?
And they're like, oh, nothing.
That's not good.
Don't do that.
Some interviewers really don't care if you're googling things.
Some interview questions are designed for like someone
might need to Google something.
That's totally OK.
Others are not.
There's others we don't want you to Google
because you could like stumble upon the solution,
and that's like obviously bad.
So just clarify with your interviewer upfront.
If you're sort of stuck, you say here I want to reverse a string.
I don't remember how to reverse a string.
Do you mind if I just Google it?
Usually, as an interviewer, I will say, no, don't Google it.
Just pretend there's a function called reverse
and use that because that's much more interesting than like you taking
some risk of like finding the solution.
But always be upfront with your interviewer.
That's the absolute most important thing.
And I think we have this on a slide too.
But if you've seen the problem before, absolutely say that.
A lot of people think they're going to win the best actor Oscar for pretending
they haven't seen a problem before.
It is excruciatingly obvious when you've seen a problem before.
So don't do that either.
If you've seen a problem before, just say hey,
actually, I was doing some practice problems,
and I've actually seen this one before.
Do you want me to solve it, anyway?
Sometimes interviewers say, oh, yeah, sure, solve it, anyway.
It's more of a coding thing than algorithms thing,
or sometimes interviewers say, oh, great.
Thanks for letting me know.
Let's do this other one instead.
We've rejected candidates immediately who are clearly lying so do not lie.
Yes?
AUDIENCE: Can you guys talk a little bit more about you decided [INAUDIBLE]
RYAN: Yeah, sure.
So I'll talk and then you probably have a different story than I do.
So let's see, so I went to Quora in 2013.
The recruiter at the time actually used to work with CS50 as well.
But for me, what I cared about most was sort of the mission of the company.
Before Quora, I did a lot of stuff with CS50 in education and edX and all that.
So I was really excited about sort of that mission of online education
and learning.
And Quora is one of the few companies operating in that space that's also
sort of in the consumer world as well.
So it's not this like academic or enterprise thing.
It's like a consumer web company that moves fast,
and you can have a lot of impact.
But also in that space that I care a lot about so that's why I picked Quora.
TOMMY: Yeah, I think, for me, I think a lot of people thought about the people,
so I had known people who had graduated before me and gone to work for Quora.
I knew that they had a strong engineering reputation.
And I think there was a lot of problems that were really interesting to me
at Quora.
So that's initially why I was interested in it.
RYAN: Other questions?
Yeah?
AUDIENCE: Is it OK to tell your interviewer [INAUDIBLE]
RYAN: Yeah, so the question is, is it OK to sort of say like, hey,
this is my first interview.
I'm kind of stressed.
That's a good question.
I've actually never thought about this one before.
So off the cuff, I don't think it's going
to help in a sense of like even if it is your first interviewer,
that doesn't change the rubric of the question or something like that.
You probably will not get some outcome where
like the interviewer goes easy on you or something.
So I don't know if there's a whole lot of value to that.
If it helps you feel better, makes you more comfortable to say like,
hey, I realized, oh, this is a real thing, how you feel,
and your stress is really important.
So if it makes you more comfortable to say that,
then there's not a lot of downside.
But there's also probably a pretty low upside as well.
What do you think?
TOMMY: I don't know.
I think like to be completely honest, you shouldn't fake things for us
to get better results.
But we do take this into an account when we're looking at decisions
like if I'm seeing that you're like crazy nervous
and I think part of that came into play when you're doing interview,
I think we do write that down in the feedback.
So yeah, I guess technically it could come into account,
but I don't know if like saying that-- like it's
really obvious when you're nervous.
You don't really need to say it.
RYAN: But it's OK if you're nervous.
That's why I'm doing a bunch of these is good.
Yeah?
AUDIENCE: You mentioned that interviewers won't give feedback
if you get rejected from the job, can you then ask for feedback
or will they be honest about how you could improve?
RYAN: Yeah, so the question is when is it OK to ask for feedback.
Even if they can't say it in an interview, suppose you get rejected.
Can you ask for feedback?
An unfortunate reality is there's a lot of legal risk in a company divulging
feedback about somebody.
So for a company, there's really high downside and basically
no upside for you, as an individual, there's a lot of upside in learning.
But unfortunately, most companies just can't do it.
So my advice would be to just not ask, use like these mock interviews,
use interviewing your friends, use interviewing
with people who did get internships at some company, get feedback from them.
That's really a feedback opportunity.
If you do ask, you sort of put the company in this uncomfortable position
of saying, well, we can't.
We can't give you feedback.
And some people like push really hard.
It's not really a great look.
I wish that weren't the case.
That's why we do stuff like these mock interviews
where you can go crazy and tell you exactly what you need to improve.
But yeah, I wouldn't recommend it.
TOMMY: For us, what if I've tried this and it didn't work?
RYAN: Yeah?
AUDIENCE: I'm not sure if this is appropriate for this
but how similar would the algorithms and that those kind of code questions
be in more of a data science role [INAUDIBLE] questions that
can be asked there too?
RYAN: Yeah, so the question is, how did these questions compare
between data science and engineering?
So typically, with data science, they'll be
less sort of coding heavy since as a data scientist,
you're probably not writing a whole bunch of production code.
And people need to worry about are you testing things correctly.
There's a separate set of questions, which would
be sort of like here's some problem.
How would you design metrics to evaluate the success of this product thing?
Or like questions that require you about a big SQL query,
for example, as opposed to Python.
So I think it's a different set of questions.
All the process stuff 100% applies and like
localizing what you're doing asking for, hints at the right point,
knowing the basics of whatever it is you need down cold,
but you're get a different set of questions.
TOMMY: I think another thing that's different
is I work in' machine learning.
So it's kind of a bridge between those two.
So we get similar interviews.
There's probably going to be more knowledge-based interviews.
So we do actually look to see like how well do you know machine learning?
How well do you know statistics in these interviews?
Which I guess we're not looking quite as much like
do you know infrastructure super well in your new grad interview,
but we might look more for the data scientist interview.
RYAN: Yeah?
AUDIENCE: Is there any book you recommend
for a data science role or just the generic machine learning [INAUDIBLE]
TOMMY: Let's see.
I think the field's evolving pretty fast right now,
so there's not like a ton of really good books on it.
I think there's a number of good online classes
that you can take to skim through.
Yeah, sorry.
Basically, I don't have a good answer to that.
I didn't use any books for preparing, so I don't know.
RYAN: Yeah, so the question was is there books
recommended for data science or ML?
I think your best shot is probably courses like there's courses here
you can take on ML and data science.
And then those course will point you to various resource.
I would start there.
Something like Cracking the Coding Interview
is sort of like your canonical answer for interviewing.
For other stuff, there's no real canonical answer yet
since the fields are sort of new.
Yeah?
AUDIENCE: For knowledge-based interviews, what kind of questions
are asked?
Do they see how much you remember [INAUDIBLE]
RYAN: Yeah, so the question is so for these knowledge-based interviews,
like what types of questions are asked.
We probably can't tell you exactly what we ask-- just give you a flavor.
TOMMY: I think it's going to be like do you understand the key algorithms used
in machine learning and statistics?
So we probably will not ask you to implement--
I'm sorry, I can't give too many specifics.
RYAN: Yeah, I can try to give some examples.
So for some [? end rules, ?] like mobile, for example,
like mobile's a very specific domain in the same way,
like data specific domain.
And so we might ask questions about like parts of the framework.
So like when do you use this API versus this other API?
Or like what are trade-offs between these two APIs
or what's an API with an [? iOS ?] that you think is badly designed?
So that they're not like that really like gotcha
either-- just sort of like, hey, can you demonstrate
a depth of understanding in this field?
Hard to give too many specifics, unfortunately.
TOMMY: Yeah, for machine learning, I guess
you could ask when should you be using linear regression
versus a neural network?
What are the different upsides and downsides
of your very basic similar things?
RYAN: Other questions?
Well, we're almost at time, anyway.
So we'll hang out here for another 5 or 10 minutes
if you have any questions for us that you want to talk through.
And if not, then thanks so much for coming.
[APPLAUSE]