SPEAKER 1: Hello, everyone.
Welcome.
Let's get started.
We are so grateful to have Tommy MacWilliam here with us today
to do our prep and practice workshop.
What number is this for you, Tommy?
TOMMY MACWILLIAM: I want to say it's like, seven or eight, maybe.
SPEAKER 1: Wonderful.
We're so happy to have him here.
Thank you, again.
I'm going to let Tommy give more of an introduction of himself
and the rest of his team from Figma, but again, welcome, Tommy.
TOMMY MACWILLIAM: Well it's really, really good to be here.
I'm so excited to be back in person and not just be a square in a Zoom screen,
so I'm really excited to see all of your faces as well.
So I'm Tommy.
I grew up in Boston, currently living in New York.
I graduated from Harvard in 2013, which now feels forever ago,
but I was one of the head TFs of CS 50 from 2010 to 2013.
I was in Mather House.
No one's in Mather House.
Well, I was so that's great.
And I'm here today with a few folks from Figma.
We have Ashley, Carolyn, and Hannah, who'll be on the Zoom chat,
answering questions.
So today, I'm really excited today to talk about how
to prepare for technical interviews.
Really, the genesis of this talk was helping
people learn all of the sort of unspoken rules
and secret handshakes that go into succeeding in a technical interview.
It's the type of stuff you don't necessarily learn in a course,
and so I'm really excited to help fill in those gaps
and help set you up for success as you begin or continue your journey
through technical interviewing.
So today, we're really trying to cover the whole end
to end process of interviewing.
We're talking about choosing companies, how to format your resume, and then
the whole interview process.
What to do before?
What to do during?
We'll have a mock interview, we'll go through it
in a live example of what to do or maybe not do during a technical interview.
And then we'll wrap up with how to think about and reflect
after your interviews are done.
So the first thing I want to talk about today is choosing companies.
This is a really non-obvious thing, and the one thing
I want you to take away from this is that everybody is different.
You know, what you're looking for what your friends are looking
for might be totally different things, and so don't feel bad
if you feel like your place is at a larger company
or your place is at a smaller company.
There's no right answers here.
And so rather than telling you exactly what companies to apply for,
other than Figma, I want to give you these principles and frameworks
to think about how you might narrow down that list.
A lot of folks have a tendency to apply to 500 different companies,
but you're probably setting yourself up for failure
with doing a bunch of interviews every day,
so here's a framework for narrowing that down a bit earlier in your process.
So number one is asking yourself, what are you looking for?
Again, this might be really different than what your friends are looking for
and your peers are looking for, so don't feel
like you ever have the wrong answer.
Some folks are looking for a more structured company
with a lot of mentorship, particularly early on in your career,
to learn from more experienced folks, while other folks want
to join somewhere a lot smaller.
Sort of learn by doing, don't have mentors telling you exactly what to do.
Neither one of those is the right answer,
but they are very different companies and very different experiences,
so think and reflect for yourself what it
is you want to get out of your internship or first roll out
of college.
Second thing to think about, especially as you go through the interview process
is would you be excited to work with these people every day?
During your internship or role, you're going to be spending a lot of time
with people.
There's a tendency to Zoom in on what projects am I working on,
what team I'm working on, but the people around you
are really what's going to define this experience for you.
So as you're going through the interview process,
think about who is being represented there
and how they sort of vibe with what you're looking for.
A related thing is looking at a company's values page.
Every company has them, Figma included.
Learn about what a company values more than other companies.
Every company will say they value hiring the best people
and shipping impactful changes, but there's
layers below that will give you a flavor of what the actual day to day work
looks like.
Finally, a really easy heuristic for thinking about where you want to work
is what size company you're working for.
So this is a graphic from Dustin Moskovitz, the Asana CEO,
back when he was giving tech recruiting talks.
And this sort of--
I won't go through this whole table, but this kind of
lays out what it looks like to work at a small, medium, and large company.
I will say this graphic is quite old, so the numbers on the top here
I would double or triple what you call a small or large company at this point.
But you can generally see that at a small company,
you're not going to have a super well defined role.
You might be wearing a bunch of hats.
You might show up in your first day to assemble your desk.
Where at a large company, you're going to have a lot more structure,
a lot more road mapping and planning and strategy defined for you,
and you're sort of going to come in and have a lot of impact through execution
and working with other experienced engineers.
So again, I'll say one last time, there is no right answer on this chart.
What people are looking for is very, very different,
so think about and reflect what it is you want and use
this chart as a heuristic to start filtering down
the wide spectrum of companies.
So that's it on choosing companies.
So next let's talk briefly about resumes.
And I say briefly because resumes are really not
as important as a lot of people think they are.
Does anyone have a guess for how long me as a hiring manager or recruiter
might spend reading your resume?
Any guesses?
Ten seconds?
Five seconds.
Ten seconds.
I've given this talk too many times.
It's actually been more generous.
I'm going to say 30 seconds is my like, median time reading a resume.
So you don't need to spend six months perfecting your resume
to get through to the next step.
We're really just looking for a few key things.
And so I'm going to leave you with my ten patented resume rules.
If you follow these ten things, you almost certainly cannot mess up
your resume, and that's your goal here.
Number one, most importantly, one page.
No exceptions.
I've read the resumes of engineers with 30 plus years of experience
across five to ten different companies.
Their resumes were one page.
That means your resume can be one page too.
I know you've done a lot of great stuff, had a bunch of internships, done
a bunch of extracurriculars.
I am not reading past page one, period.
So don't make your resume more than one page.
Second, make it easy to skim.
I am your audience.
I just told you I'm spending 30 seconds of my time on this.
If I'm spending 20 of those seconds trying to figure out where the heck
you worked because it's not formatted well or it's not easy to skim,
you've only got ten seconds left for me to read your content.
So make it really, really easy for me as the hiring manager or the recruiter
or whomever to skim your resume and get the key details.
Three make your contact info obvious.
The goal of submitting your resume is to be contacted by a company
to move forward with the next steps.
I don't know how many resumes I've read that didn't
have an email or a phone number or an obvious way to contact this person.
Super easy mistake to make, so just make sure it's really easy
to contact you from your resume.
Number four, and this is maybe the advice you hear the most,
try to highlight specific accomplishments.
If you can talk about you improved the performance of some system by 5%,
you increased revenue by 3% by optimizing some system, talk about that
and try to use specifics.
Many companies or internships might put you
under some nondisclosure agreement that prevents you from disclosing
the total ARR of some company.
However, you can still be specific about what you worked on
and what the impact of that was without getting yourself
sued by the Google legal department.
Number five, try to include your interesting personal projects.
In particular, if you only have zero or one internships under your belt,
this is your opportunity to showcase what
you've built outside of internships.
Maybe it's a cool class project where you built something and kind of went
above and beyond the requirements.
Maybe it's just something you built in your free time
because you wanted to solve some problem or build some cool app.
Please highlight that on your resume.
I literally do click click on GitHub links and flip through projects
and try out apps, and it really does help you stand out in particular
if you don't have a bunch of that experience already,
which everyone has zero experience at some point.
And so this is a way to cold start your resume and get it in front of folks So
that's a bunch of do's.
How about some don'ts?
Number one, no charts or ratings ever, period.
Please.
Don't tell me that you're a four out of five stars on JavaScript,
or an eight out of ten on collaboration.
I have no idea what that means.
I don't think you do either.
So don't waste the space on your one page of resume telling me precisely
the three significant figures how good you are at some tool.
Number seven, don't include an objective statement.
Again, waste of space.
There's a bunch of resumes that say I'm looking
for a fast paced internship in the field of software engineering
at a fast growing company.
Like, duh.
I mean, that's what everyone's doing, right.
There's no point in wasting your space with that objective statement that
doesn't separate you from any other resume in the pile.
Number eight, please use a professional email.
I've had some pretty ridiculous emails across some resumes
like, thegolfninja12345@gmail.com.
Create a resume, first initial, last name's a super great template.
Really, lots of free email services.
Don't use a silly email.
Nine, include relevant links.
If you've got a LinkedIn, included it.
You've got a GitHub, include it.
If you're a designer or a data scientist, you've got a portfolio,
please include that as well.
Like I said, especially for folks who might not
have a bunch of previous internship experience,
we literally do click these things, so please put them
on there to give us the opportunity give you the opportunity
to showcase your skills really fully.
Number ten, don't sweat the aesthetics.
A lot of folks are really concerned about getting the correct shade of blue
for the header on their resume.
I don't care.
Just make sure the content is really what's coming through in your resume.
Don't spend a bunch of time trying to design stuff.
So those ten rules in mind, I have two fake resumes.
I promise they're not real because I googled fake resume.
And so I want to hear from the group what we think about this resume.
It's not all bad.
It's not all good.
So what's good and what's bad according to those ten rules?
Feel free to raise your hand.
Yeah, in the back.
AUDIENCE MEMBER 1: I think that it's easy to navigate,
and you can clearly see what is the job title that they have and dates,
and stuff.
That's the good side.
The bad side, it's--
he has the ratings that you mentioned.
So it's very subjective.
And also, it is misusing the space, in my opinion, in this thing of putting,
I think header you can eventually make that a bit more simple.
And I cannot actually read too much the points,
but it doesn't seem that they are focused too much on the achievements.
They have some of them like, in the last one that says like,
[INAUDIBLE] of something.
But the rest doesn't look like, very focused points.
TOMMY MACWILLIAM: Yeah.
So just so just to recap, so I think this is definitely well structured.
Words like data scientist are in bold.
Great.
I can read that really easily.
We've got this very strange chart over here,
where it seems like they're a good team player,
but they don't have great attention to detail.
I'm not really sure how that adds up.
Maybe one other observation from someone else?
Good or bad.
Yeah.
AUDIENCE MEMBER 2: One good observation is
that they're using a professional email address,
but a bad observation is that they have a profile which
is sort of like the objective and it's unnecessary.
TOMMY MACWILLIAM: Yeah.
I think that's exactly right.
So good contact information easy to read.
However, they've got this waste of space and this waste of space.
The actual content is really this small square over here
and this small square over here.
There's probably a lot more room for them
to be highlighting specific achievements by removing a lot of this cruft
that I'm really not that interested in.
OK, that's one.
And here is google images fake resume number two.
What's good about this and what's bad?
Yeah.
AUDIENCE MEMBER 3: I just have a [INAUDIBLE]..
TOMMY MACWILLIAM: Yeah.
It is really, really dense.
Pretty hard to read.
I like that they've kind of highlighted their roles,
but there's just so much going on here.
It's not easy for me to read compared to the last one.
Yeah.
AUDIENCE MEMBER 4: Positive is that they have their LinkedIn,
but it's sort of hard for me to find with how much text--
TOMMY MACWILLIAM: Yeah.
Exactly.
So it's there, but it doesn't really jump out to me at the starting point
either.
One other observation?
Yeah?
AUDIENCE MEMBER 5: I think that they use way many points under each experience,
and if they have more experiences that they share, they can just like,
condense some of these things--
TOMMY MACWILLIAM: Yeah.
I think that's right.
There's a whole lot of verbosity here.
I think that's in part what's making this easy to skim.
Yeah.
AUDIENCE MEMBER 6: I think another positive is they like list
their like, positive attributes [INAUDIBLE]..
TOMMY MACWILLIAM: Yeah, I agree.
This part is actually maybe the most memorable part of the whole thing.
Sort of what they're doing, what their area of expertise is.
I'll add one more thing.
I'm surprised nobody pointed out.
I have literally no idea what this is.
I don't know what they're trying to convey here, but they didn't convey it.
So don't try to get fancy.
Don't think about too much the aesthetics here.
Simplify your resume.
Make sure the content is really being highlighted, not some thing.
So that's it on resumes.
I'm not spending any more time on resumes in this workshop
because like I said, they're not that important.
They're a way for you to get your foot in the door,
but at no point am I ever in a debrief for candidates saying,
well their resume had the best font I've seen in weeks.
We've got to give them the role.
[LAUGHTER] So let's talk about what to expect before the interview.
So first, here's things that you can expect.
One, if you can, try to interview early and plan it into your schedule.
Interviewing is nearly another class for you to take on.
There's a whole lot of coordination and it's a stressful experience.
So I'm not telling you to take an easy class or two,
but I'm not not telling you that either if it's
going to help you with your schedule.
And third, try to look for opportunities that are geared to your experience.
Many companies, the Googles, the Microsofts, the Metas,
they have internships geared specifically at first year students
or folks who don't have any experience.
Try to apply to those first if that's the category of person you are.
If you have three internships under your belt,
don't try to apply to one of those first year programs.
Look for something that's a bit more tailored to you.
There's no sort of like, secrets here.
Just read the opportunities.
They'll usually be pretty clear.
This is a fellowship for a first year, and then this
is, sort of, our standard internship with an eye of converting
towards a full time person.
So here's a sketch of what the process might look like.
So many, many processes will start with you
meeting with a recruiter coming to an event like this to meet with folks.
The first technical assessment will probably
be some kind of online coding challenge.
Maybe there's someone human there moderating it.
Maybe there's not.
There's lots of tools these days to just allow
you to work on a problem in the comfort and space in your own time.
There may be some sort of take home assignment.
Maybe that's something that's a bit longer
in scope, maybe three to four hours or a weekend to build something.
There could be a technical phone screen, which
is a conversation live with an engineer going through a coding problem,
like the one we'll see later today.
And then there's going to be an on site that's
sort of a blend of different interviews, and we'll
go into what those interviews look like.
And I'll say that every company doesn't have all of these steps.
It's more that these are the steps you may encounter.
Companies will probably pick and choose two of these maybe
to define their process, but here's all kind
of the enemies you may encounter along the way.
So here are five types of interviews that you might encounter.
We're going to focus the most on algorithms
and coding today because especially for early career
folks that's the bread and butter of your technical interviewing.
But we'll also briefly touch on systems design, practical interviews,
deep dives, and values interviews as well.
So that's what you can expect, but I also
want to talk about what I expect of you as an interviewer.
So this is pulling back the curtain.
This is the lens of what your interviewer wants you to do.
Broadly speaking, they want you to be able to think through a problem.
Some problem that you haven't seen before,
you're sort of drawing on past experience,
but you haven't seen exactly this, we want
to see how you're thinking, the way you approach problems,
and how you solve them.
We want you to write functional code.
We don't want a verbal description or a paragraph description or a pseudocode.
We want actual code.
In some language, often whatever language you want,
but we do want the code to work and for it to be real code with real syntax.
Three, nobody's perfect.
And so we want you to fix issues along the way.
Ideally if you're writing code, you're identifying those issues yourself.
Maybe you found a bug, maybe you found some improvement.
We're looking for you to be on the lookout for those and fix them,
but that doesn't always happen.
Sometimes your interviewer might point out,
hey it seems like you've got a bug if you consider this edge case.
We're looking for you to be able to fix that and not sort of stress out,
maybe being able to adapt your code to new Information.
Looking for you to reason about runtime.
We'll talk about that in a bit, but be able to say
is the solution linear or logarithmic or whatever.
And lastly and most importantly, we're looking for you to communicate clearly.
The interview is a conversation.
Your goal in that conversation is to communicate your solution
through words, through code, so make sure that's
really clear to your interviewer.
So now let's talk a bit about preparing for interviews.
And like I said, we're going to focus the most on these algorithms encoding
interview, which is going to be what you're mostly going to see.
The first thing you want to do as you're preparing, really
start with the basics.
When you're in an interview, it's really stressful.
No matter how many interviews you do, I did some interviews recently,
it's still really stressful.
The number one thing you can do to reduce that stress is to practice.
The more types of problems you've seen, the more
times you've been in a time setting with some weird-looking Leet Code
problem you've never seen before, it's going to reduce
the stress as much as possible.
It'll never be zero, but you can reduce it with practice.
More specifically, pick a language and stick to it.
It's very rare, possible, but very rare for a company
to say you must interview in precisely this language.
So instead, what you should do is pick a language
that you feel comfortable with.
Maybe you've used it in a bunch of classes.
Maybe you had an internship where you use Python.
Pick one of those languages like a Python or a Ruby or a JavaScript
that's fairly simple, has a bunch of built in tools, and use it.
The last thing you want to do going into an interview problem
is say, all right, what language do I want to use to solve this?
You should know that cold before the question even gets asked.
And once you pick a language, try to learn the foundations of that language.
Syntax, built ins, error handling.
If you're in an interview and you're trying to remember,
how do I get the length of a string in Python?
Is it Len?
Is it dot size?
It's just stress, right?
You want to eliminate that variable completely.
Just have these basics down cold and be ready to use them,
so that all of your stress and all of your energy in the interview
itself goes towards solving the problem and not all the boring stuff
around that.
So really want to start with these basics.
So having heard this, what are some things
that people think you should know how to do cold?
Raise your hand and let me know.
Yeah.
AUDIENCE MEMBER 7: Like, write a loop.
TOMMY MACWILLIAM: Yeah.
That's a great one.
Being able to write a loop.
What's the syntax?
Does it have braces?
Is there a colon?
Is there even a y-loop in this language?
Right a loop.
That's a really good one.
What else?
Yeah.
AUDIENCE MEMBER 8: Conditionals.
TOMMY MACWILLIAM: Yeah.
Conditionals.
Exactly.
What's the state for conditionals?
What is the syntax there?
How about one more, and then I'll give you my list.
Yeah.
AUDIENCE MEMBER 9: How to visualize an array?
TOMMY MACWILLIAM: Yeah, that's great.
List an array is super, super common in Primitives.
Being able to know, is it called a vector, is it a list.
Having that really, really comfortable.
So here's a few other things that-- along the same line
of what we just mentioned.
One is making sure to create a function.
You'd be shocked at the number of interviews
that I've started where someone has said, how do I create a function again?
You don't want to be that.
Just have that down cold.
Define classes.
Work with strings.
Tons of interview questions have to do with strings.
Lists, as someone just mentioned, and trees as well.
So just have this practice down.
You shouldn't have to be wondering, oh crap,
how do I represent a binary tree in Ruby?
Just know that going in.
An interesting thing about-- interesting interview problem,
is that we're is going to ask you what's the runtime.
It's like baked into every interviewer's trainings.
Like, just say the words, what's the runtime.
And what's interesting is that interview problems really rarely
have complex complexity.
Your answer is never going to be 2 to the n divided by log n factorial--
it's not that.
It's going to be all of the simple ones.
So with that in mind, what are some common runtimes
that you might encounter for an interview problem?
AUDIENCE: Log n.
TOMMY MACWILLIAM: Yeah, log n.
That's a good one.
What else?
AUDIENCE: Linear.
TOMMY MACWILLIAM: Linear, and what else?
AUDIENCE: N square.
TOMMY MACWILLIAM: N square-- we've basically got them all.
Honestly, that's not going to be more complicated than that.
So you've got-- to add a couple more, you've got constant, we didn't say.
Polynomial is just the generalized form of quadratic and cubic.
And then exponential as well.
If you answer the question and you say exponential,
that almost always means your interview is not
done yet, because you can do better than exponential.
Not always, but that's kind of a signal that you can get it
into one of these other runtimes.
So if you find yourself deriving some math principle
or proving some theory where you're answering the complexity question,
you're probably wrong.
Just say one of these five words and that's what your interview wants.
So along the same line, you also want to build out your toolbox of concepts.
There's a whole bunch of interview questions out there, but many of them
are really just dressing up some core CSS concept and disguising it.
So some of the concepts you'll probably encounter, one is recursion.
So how can you take this problem divide it into subproblems,
and solve the original problem with the sort of combination of the subproblems?
Graph searches.
A bunch of things can just be reduced to graph searches,
so knowing what breadth-first search or depth-first search is.
What a binary tree is, for instance.
Greedy algorithms.
A lot of questions sound like they've got some crazy solution,
but the answer is just sort of approach it greedily.
A lot of string questions are out there.
Things Like palindromes versus string and one of our marketing questions
it's a string question so just being really comfortable with strings.
How to access them, create them, mutate them.
And then, lastly searching and sorting.
Ton of interview questions, sort of, take the form,
find a path through the trees, or transform this into that,
just boils down to some kind of search or some kind of sort.
So have these basics down.
Sort of be really comfortable with recursion, which I know
is a scary topic, but if you get comfortable with it,
you're going to be able to start unlocking the solution to a whole bunch
of interview questions.
And again, it doesn't get much, much fancier than this.
One sort of advanced topic here, if you've taken 121 or 124,
is this thing called dynamic programming, which
is this way of caching values and transforming some exponential solution
into something polynomial, hopefully.
So you might see that as well as you're searching around topics,
but that's a bit more of an advanced one and sort of for the--
maybe for the new grad roles, as opposed to the intern roles.
So those are the topics.
And so how about the tools that you have at your disposal?
So one is arrays and linked lists.
Be comfortable creating those, knowing what
the difference is, how to use them.
Hash tables are a super easy way to make some runtime faster,
so know how to use those.
Binary search comprises a huge proportion
of interview questions for some reason are just disguised binary search,
so get really good at that.
Shortest path algorithm.
Sort of, how to navigate a graph, and sort of memorization,
which is one of the techniques possibly behind dynamic programming of caching
values and reusing previous computations.
So these are the things just sort of practice different problems
with these different tools.
And whenever you encounter a problem, your first thought
should be, OK, well what's in my toolbox,
and how can I apply these tools to this question that I just got?
So that's the preparation, the intellectual part of preparation.
And so now let's talk about the actual tactics here.
So one is simulate the environment as much as you can.
I have a tendency, and I've seen many people
have a tendency, to read some question like in the books
that you're looking at, think about it for like a minute, be like,
oh, yeah it's probably something like this.
Like, yeah, I got it.
Flip to the answer key, and then be like, oh yeah, I totally had it.
If you find yourself doing that, that is totally the wrong thing to do.
Many, many people overestimate the degree to which they have it.
So I'd really encourage you to actually sit down, write out the solution
to the problem yourself.
Don't look at the answer key.
Try to time yourself.
Put yourself on a, I don't know, 30 to 45 minute clock,
because that's a real thing in the interview.
Try to get used to that.
Don't try to-- if you're in an interview that doesn't let you look up something
on Google, simulate that yourself.
Know what it's like to work without your autocomplete or without your answers
on Google.
And as you're doing that, try to look for patterns in your own performance.
Again, everybody's really different.
Some people are amazing at recursion, but sort of struggle with graph
algorithms.
Some people just never really get behind dynamic programming,
but are really good at these kind of string problems.
Everyone's different and try to assess your own strengths and weaknesses.
If you're looking online and you're sort of looking at questions,
they're almost always categorized by something.
Divide and conquer, or whatever.
So try to do a few of those different categories
and see where you're good, where you're not, and zone in on the areas
where you're not.
And then lastly, if you can, try to practice with friends.
You can get an interview buddy and practice being the interviewer,
being the interviewee.
Even if you've never done interviewing before, you kind of get the idea of,
oh maybe, I know the answer.
I can give hints.
It's also a lot less lonely.
It's not a fun thing to do by ourselves, so if you can get an interview buddy
and practice together, you can just, sort of, help
simulate a more realistic environment, which ultimately that's
your North Star here.
When you're sitting in an environment with an interviewer,
you want to feel like you've done this before.
You're as comfortable as you can be.
This doesn't feel weird and new.
And the way to do that is to really take the time,
simulate the environment beforehand.
So that's all of your prep.
So now let's talk a bit about strategies during the interview itself.
The thing that I'm going to repeat a bunch of times today
is that as an interviewer, I care about process
a lot more than I care about output.
There have been many, many, many interviews
I've done where the person I'm interviewing
didn't get the correct answer, their code didn't work,
didn't think of some edge case, and they still made it through the next round.
And the reason is because their thought process was really clear,
they were able to articulate the trade offs of their approach,
and I'm confident that with a couple more minutes and maybe 10% less stress,
they could have gotten the answer correct.
So think about that as you're interviewing.
Don't zone in and get really lasered in on did I get the right answer.
Laser in on your process for getting that right answer,
which we're about to talk about.
So the first part of the interview will be some sort of icebreaker.
I always advise people before they start an interview,
take a deep breath before you click the blue button on Zoom.
Just take a deep breath, center yourself, and get ready.
Have an intro prepared.
As an interviewer, they'll introduce themself.
I'm Tommy.
I've been an Figma for nine months.
I work on these teams.
Have a quick intro prepared on your end.
I've seen some candidates sort of like, ramble for like,
ten minutes about their cat's name in second grade.
So just have a quick 30 second intro prepared on your end.
Again, just don't even think about this.
Like erase the variable.
Have this stuff down cold so your energy is going towards the problem.
Your interviewer might ask you about some project.
It might be like an hour long interview where maybe 40 minutes of that
is coding, but 20 minutes they're going to say, oh, tell me
about your last internship, so be ready for that.
Pick a project you can talk about for five to ten minutes.
What the challenges were.
What went well, what didn't.
But again, just have that down cold, and don't ramble.
When people are nervous, myself included, maybe I'm doing it now,
they have a tendency to ramble and not end their sentences and keep talking.
So try to be mindful of that in your interview conversation,
to stop and pause and let your interviewer interject
and ask questions.
Next piece of advice, you're going to receive some technical problem
you haven't seen it before.
It probably has scary terms like integer and sorted list.
Don't panic.
Sort of, practice, get used to this.
If your reaction is panic, try to practice
and get used to solving these sort of new and unfamiliar problems.
If you've seen the problem before, like exactly that problem,
tell your interviewer.
I've interviewed a bunch of folks who think they can win the Academy
Award for pretending they haven't seen an interview problem,
and I haven't handed one out yet.
They never win.
And it's really, really bad and borderline unethical for a company
to be like, cheating in this way on an interview.
So don't do that.
You're just sort of setting yourself up for failure.
Many times, the interview will say, OK, cool.
Thanks for telling me.
We're going to do it anyway.
And you sort of proceed that way, and the interviewer
can kind of keep that in mind.
But if you have seen it, just tell your interviewer.
Don't try to get away with it.
After you get a problem, ask clarifying questions.
A really good thing that I like to see is say, OK, well here's the problem.
So let me just confirm.
With this input, the output should be this.
Your interviewer is like, oh, yeah.
That's right.
And you've concluded to yourself, I now understand the constraints
of this problem, rather than jumping in and assuming it's something,
and then your interviewer doesn't realize you're on the wrong track,
and 20 minutes later, the two of you realize, oh,
we're actually solving the wrong thing, and you just burn those 20 minutes.
So just confirm you have a full understanding of the problem,
and a great tactic is just to say, here's an input,
is this the correct output.
As you're solving a problem, you're going
to do this really weird thing that you don't do when you're coding normally,
and that's you're going to be constantly speaking out loud.
It's really sort of tempting to say, OK.
Thanks for the problem.
See you on 20.
I'll shoot you over solution.
Don't do that.
Be constantly vocalizing your thought process.
So say things like, all right, so first I'm going to create a function,
let's call it find minimum.
We just need to take one argument here.
It's a list.
So the first thing we're going to do is loop through the list.
Things like that.
Articulate what you're thinking, and code as you're speaking.
That's the best way to communicate your thought process to the interviewer.
Also, try to think through multiple possible approaches.
There's probably a chance that you'll think
of approaches that aren't very efficient,
and approaches that are very efficient, so
try to talk that out loud before you write a single character of code.
Explain a possible solution to your interviewer, get on the same page
that you're aligned and you're like, roughly on the right track here.
If it's helpful, draw a diagram.
Some interview tools will have a whiteboard attached
where you can draw some things.
Some won't, so you can just use a pen and paper.
Maybe show it to your interviewer, maybe you don't.
But some people are very visual, and don't
feel like you're not allowed to be visual in one of these settings
because you just have some coderpad or replit.
So drawing a diagram can be a pretty helpful way
for some people to visualize a problem.
So we talked a lot about all these things
that you're going to do and prepare for.
And again, it's not a very long list.
None of these lists that I've showed you, intentionally,
have more than like five things.
So when you have a problem, try to pattern match against what you know.
Against these core concepts we just talked about, and against these tools
in your toolbox.
For instance, maybe you're given some problem that say, OK, maybe you're
like, running across a river, and there's rocks floating on the river.
What's the fastest way to get from one end of the river
to the other way to the river?
Maybe that's a graph.
Maybe you could formulate that as a graph.
Maybe you could formulate it recursively,
sort of divide the river into sub rivers.
Maybe there's a binary search.
Maybe there's some way to decomposing problems.
But just sort go through, one by one, the tools in your toolbox,
and see what applies.
There's a very, very, very high probability that one of them applies.
So just make sure you've got them down, and you're
going through what's going to make the most sense for this problem.
A common tendency and a common mistake I've seen,
again, is for folks to think really specifically about problems,
rather than more general solutions.
So for instance, maybe there's a question that the input is some number.
And maybe it's really obvious what the solution is if you pass at zero.
And so some people are like, all right, well, if it's zero,
then I'm just going to return one.
And they'll say if n is zero, return one.
And if it's one, I'm going to return two.
And then, if n is 1, return two.
That's almost always not the right way of approaching the problem.
Try to think more generally with solutions,
rather than just kind of zeroing in on some specific instances.
Or put another way, start with high level ideas,
rather than starting with low level ideas.
In general, if you're writing a solution and it seems really complex,
you've got all these data structures, you've got like 500 lines of code,
if it seems really complicated, it's probably is.
Very few interview problems have extremely complicated solutions
with all these different things.
Many interview questions are designed intentionally
to be solved in just few lines of code and really using the right concepts.
So if you think it's too complicated, it probably is.
And check in with your interviewer.
If you have this crazy complicated solution,
say does this seem like it's on the right track,
or is there a simpler way that I could approach this?
Your interview will give you some feedback and some guardrails
to guide you in the right direction.
If you're really, really stuck, don't be afraid to ask for help.
Certainly, don't ask your interviewer every three minutes
what the next line of code should be or if you're on the right track,
but at the same time, if you just hit a wall and everyone hits that wall,
you just don't see a path forward, just be honest about that.
Say, OK, well I've got these concepts, but I'm not exactly sure
how we can solve this case, or where I should go from here.
As an interviewer, I promise I want to help you.
It's really not fun for me either for someone to not do well in an interview.
So I don't want that as much as you don't want that.
So ask for help if you're stuck and give your interviewer
an opportunity to help you.
If you're just talking constantly and don't give me the opportunity
to jump in, I can't help you and you're setting yourself up for more failure.
And last, make sure you explain a solution
before touching a key on your keyboard.
I mentioned this before, but align on a high level
idea before you start writing code top to bottom.
Many of yours won't stop you if you start
writing code from top to bottom, because maybe you get it,
and I don't want to get in your way and mess you up.
But almost always that's a bad idea.
You want to make sure that we're on the same page
before you start typing some Python.
And all of this is to say the process matters so much more than the output.
Having people communicate, check in, receive feedback well,
ask for tips, that's what we're looking for here before we're thinking about,
did they get exactly the right answer with the precisely correct runtime.
So another failure mode here is folks who
will try to jump to the most optimal solution to a problem
before they just get something working at all.
Very more often than not, it's much better
to leave an interview with some sort of solution.
Maybe it's not the perfect runtime or the cleanest code
you've written in your life, but it's much better
to leave an interview with something rather than nothing.
So in your process of constantly communicating,
try to get something working in the time slot of the interview,
and after something works, then start simplifying your code, optimizing it.
As your interviewer, again, I'm going to want to help you.
Many times I'll say something like, have we considered using a list for this.
The answer to that question is never no.
Many people will say no.
Like well maybe we need-- maybe this isn't
working because we haven't restarted the server.
No, that can't be it.
If I give you any sort of hints or guardrails, please take them.
As an interviewer, I'm looking for you to respond to feedback well,
and I'm trying to help you.
So don't just sort of get really zoomed in on your approach
and getting your code to work.
It's a conversation and make sure that it's a two way
street during the interview as well.
As you're writing code, a really, really simple thing
that if you haven't done interview before this might not be obvious.
Your goal is to write a function that returns the answer, unless you're
told otherwise.
So you're not trying-- your first line of code shouldn't be int main, int r,c,
whatever.
It should be the definition of a function that takes in some inputs
and returns some outputs.
As you're writing code, decompose that into functions as needed.
Again, get something working, but if you sort of observe that it would be easier
to solve the problem if you had some helper function to do x, y,z,
feel free to tangent, write that helper function, and then come back.
All the sort of practices that you learn about in CS 50
are on clearly designed code and code style, they apply here too.
You don't have to go crazy like commenting your code and putting doc
strings on everything, but do use readable variable names,
reasonable names for functions, as opposed to just a,b,c, x,y,z.
And as you're going, if you can, factor out common logic.
Try to create well designed code, but that's secondary
compared to your first goal of get something working,
then start thinking about code design.
Process, not output.
You'll have two kind of types of coding interviews.
There's those where you can run code and there's where you can't.
Neither is better, there's no sort of like, right answer here,
but you're going to find them both.
And so, I just want to give you some tools for each situation.
If you're not allowed to run your code, your job is to be the computer, right.
When you write down your code, you're going to say, all right, does it work.
Literally run through your code line by line.
Sort of, maybe you write down the state of variables,
walk through what branches of a condition are going to hit,
how many times you'll go through a loop, but step through line by line
as if you were a debugger or a CPU running your code
and say out loud what's going to happen.
In the process of doing so, you will either build confidence
that your solution is correct because your code is doing the right thing,
or you'll find bugs.
It's a great way to find bugs if you're really literally going through what
the code says it's going to do.
And this is how a technique you can use to proactively find bugs
before your interviewer.
Always a great sign if someone finds their own bug before I have to say,
I've seen this problem 1,000 times, you didn't think about the zero input case.
If you are allowed to run code, you might not have to do that sort of line
by line verbal run through because you can actually physically run your code.
Some people like to do that run through anyway just
to build more confidence in your code.
That's totally fine.
But if you can run your code, I would highly advise you to run that code.
So some specific tactics here, write some test cases,
you agreed on some of these cases at the start of your interview
with your interviewer, actually encode those.
Put them at the bottom of the file so when run it, you can see if they pass.
Don't just randomly guess and check even if that's
how you write real code, which is not necessarily invalid,
don't do it in an interview.
So don't just be like, oh I got a plus one, I'll try plus two,
and I'll try minus one until it works.
Reason through the changes you're making and try
to convince yourself and your interviewer
that you're making a change to solve the problem correctly.
And try to print and debug a lot of state.
If something's not running, don't just sort of like stare at it and think.
Start printing out different variables.
What's the state of this input?
What's the counter?
When the counter is three, how long is this list?
And then that's going to help you identify and spot bugs.
So it's not all that different than probably actual writing code
for a problem set or some project, but don't
be afraid to do that in an interview either.
I would not recommend dropping down to some debugger,
or trying to val grind or interview code or something.
You just don't have time for that stuff.
So printing out code and printing out all the relevant state
can be a really useful tool.
Again, it's about the process not the output.
We want to see how you're finding bugs, not necessarily
that you wrote perfect bug free code.
So that's everything on algorithms and coding.
What I want to do briefly is talk about each of these other interview types,
and then we're going to dive into a mock interview that
goes through an algorithm and coding question.
So the second type of interview you might encounter
is a systems design interview.
So a systems design interview is basically
a question where you're not going to be writing a bunch of code,
but instead you're going to be architecting some larger system.
And so just like we talked about those code building blocks, your loops,
your strings, your functions, your linked lists,
you also have some systems design building blocks.
Things about how do we want to store data, what type of database
do we want to use, what type of tables should we use to record the users
or who's following whom, or what the likes are.
So think about how to represent data and databases.
Caching layers, if we're going to be reading from some database a bunch.
Is there a way to cache that?
Things like message queues.
Maybe we want to have some service that talks
to some other service along some queue.
Maybe some parts of the questions should run online, like when I load a page,
this stuff should happen.
Other stuff should happen offline.
So we'll like, run some process every minute
that writes some data to some database that some other thing just reads.
Similar thing here.
Just know these building blocks in advance.
And then during the question, all you're doing is piecing them together.
You know what a database is, you know how to represent tables,
so let's tie all these tables together into something
that represents your application.
Create some visuals draw arrows between services and things.
And also, think through the requirements of your system.
Ask your interviewer, is this going to have to support
10 users, 1,000 users, a million users?
The system you architect is really going to vary
based on the answer to that question.
So make sure you're asking that and getting
on the same page with your interviewer.
A practical interview I've seen kind of take two shapes.
One shape is that you are given a code base, like maybe it's
a huge code base, some GitHub project, and your job is
to make some change to it.
So maybe it's some app, but you want to change the color of some button
to blue, or make the behavior do some other thing.
If that's the case, these can be really scary,
because you're like I haven't seen this code base before.
This is like 500 lines of code.
What am I supposed to do here?
Searching code is your friend.
Try to search for concepts.
If you're trying to change the home feed,
search around the code base for feed or home feed.
And then as you're running code, stack traces are your friend.
One of my favorite things to do when I'm looking at some code base
and I'm like, all right, I'm in some function,
but like, what's calling this function, is I just go and divide
by 0 inside of that function, because what that's going to do
is it's going to crash your program and you're
going to get a nice stack trace of all the things
that are calling the functions, and how did you end up in this place.
So that's a really easy way to start getting a grasp of a new code
base quickly, which is the goal of this question,
because you're sort of having to learn this huge thing and just 45 minutes
or so.
If you're not given a code base, this is what
a take home interview might look like.
It might be build an app or write a script to scrape this website
or represent something.
If that's the case, you really want to focus on code quality
with your solution.
Here we're really, really less concerned about did you do it
the right way, and more about what is the design of your code look like.
The question to ask yourself consistently throughout this
is would I actually push this to production
if I were an intern at this company.
If the answer is no, take some time to fix it up,
because as an interviewer, as I'm reading this I'm like, all right,
well this is literally what would be put to production if this person were
an intern on my team.
Am I happy with this?
Yes or no.
So that's what a practical interview might look like.
A deep dive is actually something we're starting to see a lot more.
We do one at Figma for some roles.
Your job here is just to present some interesting past project.
Maybe it's a class final project.
Maybe it's a past internship.
And as you're doing so, what we're really
looking for is for you to know the details in and out.
If you built some system, but then you can't tell me
how some component of that system works, I don't really
have confidence that you knew what you were doing,
or that you actually built the system.
So try to know the details and the lower level stuff in and out.
And I don't really care as much about exactly the order
in which you wrote something.
I'm much more interested in your trade offs and thought process.
This is some design that you built. What else did you consider?
What other designs did you end up not going with?
What was your thought process in making trade offs?
Maybe it's around speed or usability or whatever.
So discuss all the things you thought about on the way
to arriving to this final solution, not just the final solution itself.
And finally, highlight the challenges.
What parts of this were really non-obvious, not
intuitive, the hardest things for you to build.
That's what I'm interested as an interviewer.
What was the hardest thing that you did?
What's the most what's the thing you're most proud of?
And you should highlight that yourself.
And last is the values interview. so this
is a totally non-technical interview, with someone like me, like a manager,
and not necessarily with someone on the engineering team.
And to think about values interviews, you're
really going to be talking about your past experience, the collaboration,
prioritizing projects, working with others, all the stuff
around writing code.
And I generally think about this interview as having two parts.
The first part is you looking back on your past experience,
your past internships.
What did you learn?
What are you proud of?
What was really hard for you?
How did you work with others?
So look back and just start reflecting on those past experiences
and be able to talk about them.
And the other half of this interview is looking forward.
You know, why are you interested in this internship?
What are you looking for in your next role?
Where do you want to be in 6 to 12 months?
What skills or languages do you want to learn?
But also, where do you want to be in three to five years, which
is this crazy like, long timeline to think about,
but I'm really interested in your long term career goals.
Maybe you want to be a technical lead working on back end.
Maybe you want to be a manager of some team working on front end.
I'm genuinely interested to know where your goals and aspirations are.
And if your answer to this is, I don't know,
that's not a great signal for me as an interviewer,
because I'm a little bit worried that you don't have that growth mindset
and sort of that appetite for learning.
And so the best way to be ready for this is just think about this in advance.
Do some reflection and introspection on your own,
both your past experiences and where you want to go next,
and just have some talking points around questions like this.
Many of these questions will also take the form
of tell me about a time you blank.
And so the more you're reflecting on your past experiences,
the more you'll be able to pull stories out and talk about things effectively.
So that's an overview of all the things to think about
before and during an interview.
So now, we're going to do one.
So I'm excited to welcome up our first mock interviewer.
if you want to come up here and we'll simulate an interview.
[APPLAUSE]
All right.
Yeah.
Let's get some hype.
All right.
So do you want to-- let's see.
Maybe we can just use the mic.
So here's our problem.
It's up here in the docstring, but we're going
to be working with an array that has been rotated.
So let's define as rotated array as one that's assorted array,
but all the elements have been rotated over some number of times.
So you can see here, if you take the array 1, 2, 3, 4, 5, rotate it
three times, you get 3, 4, 5, 1, 2.
So your challenge is given some rotated array,
find the number of times it has been rotated.
INNOCENT MUNAI: All right.
Will folks hear me if the microphone is here.
TOMMY MACWILLIAM: Yeah.
Maybe I can-- maybe I'll like awkwardly hold it.
This doesn't happen in real interviews I promise.
INNOCENT MUNAI: All right, so my name is Innocent Munai.
I'm a sophomore at the college studying computer science.
I'm one of the members of the teaching staff this year for CS 50,
and I'm excited to take part in this mock interview.
So yeah, and a little nervous, so let's see how this goes.
All right, so hi, Tommy.
How are you
TOMMY MACWILLIAM: Doing great.
Thanks for joining the interview today.
INNOCENT MUNAI: Thank you.
How is your day been?
TOMMY MACWILLIAM: Not too bad.
It's a little rainy here in Boston, but I can't complain.
INNOCENT MUNAI: Oh, yeah.
Sure.
I mean, my day was good as well.
I just came out from leading a lab session for an introduction
to computer science class that I'm teaching for.
TOMMY MACWILLIAM: Nice.
First time teaching it?
INNOCENT MUNAI: Yeah.
TOMMY MACWILLIAM: Very exciting.
INNOCENT MUNAI: And it's been great.
So I'm glad.
TOMMY MACWILLIAM: All right.
All right.
INNOCENT MUNAI: All right, sure.
So I guess we can get started.
TOMMY MACWILLIAM: Yeah.
Let's jump right into it.
INNOCENT MUNAI: All right, sure.
So I will first read through the problem.
And I usually use pen and paper to sort of digest the question.
TOMMY MACWILLIAM: Yeah, that's fine.
INNOCENT MUNAI: If that's OK?
Yeah, so if you see me looking like, at the bottom of the screen,
just know that I'm trying to look at the paper.
TOMMY MACWILLIAM: All right.
That sounds great.
INNOCENT MUNAI: Sure.
So the prompt says let's define a rotation array as a sorted array
where the numbers have all been rotated to the right some number of places,
with numbers wrapping around when they reach the end of the list.
And we're given a list right here with elements 1, 2, 3, 4, 5.
If it's rotated three times, then it becomes 3, 4, 5, 1, 2.
All right.
So given such an array, we need to find the number
of times it was rotated, right?
TOMMY MACWILLIAM: That's right.
INNOCENT MUNAI: All right.
So in this case, if this is the rotated array--
I'll just copy it and paste it right here.
If this is the rotated array, then we expect our function
to roturn three, right, because this means
the array was rotated three times.
TOMMY MACWILLIAM: That's right.
INNOCENT MUNAI: All right.
So let me think of like a different rotated array,
and try to see whether I actually got the point of the problem.
All right, so I'll think of one that begins with 2, 3, 4, 5 and 1 right
here.
Will this be rotated four times?
Is that true.
TOMMY MACWILLIAM: Yeah, that's right.
One more than the previous.
INNOCENT MUNAI: Oh, right.
Sure.
So then in this case, just before I proceed,
I would try to come up with a solution that works on my example,
and then sort of like generalize for all kinds of inputs.
All right, so looking at this problem right here, it seems that--
looking at the pattern, it seems that what we are actually looking for
is the index of the number that is like less than the previous one.
So sort of like, I could narrow this down to a search problem
where we are looking for the index of the number that
is less than the previous.
TOMMY MACWILLIAM: Yeah.
Put another way there, or the minimum element.
You're looking for the index of that.
INNOCENT MUNAI: The minimum element.
All right.
Just because all the elements on the right
will have to be like, greater than this one, because they are sort of sorted.
TOMMY MACWILLIAM: Yeah, exactly.
INNOCENT MUNAI: All right.
All right.
So we are sort of looking like the minimum.
Right.
So then in this case, I will have to define a function that
works along the lines of this solution.
I will call my function find rotation key,
and then this function is going to take in an array,
let's call it nums, because it's like an array of nums.
And then, this function is going to return
the index that is required, right?
TOMMY MACWILLIAM: Yep.
INNOCENT MUNAI: All right.
So working through what happens here, what I need to do is go through--
I'll need to go through each element of the array,
and then I will check for an--
I will check for an element that is less than the previous.
I mean, I'm looking for the minimum, but like,
I could check for both, whether it's less
than the previous one and the next.
But for this case, it's sufficient to just check
whether it's less than the next, right?
TOMMY MACWILLIAM: That's right.
That's right.
INNOCENT MUNAI: Sure.
And then what I need to return is the index of that element.
How does this--
TOMMY MACWILLIAM: Yeah.
That makes sense.
That makes sense to me.
INNOCENT MUNAI: All right.
Thank you so much.
All right, so then I think I can just go ahead and change this into code.
TOMMY MACWILLIAM: Yeah.
Let's do that.
INNOCENT MUNAI: All right, sure.
So I need to go through each element of the array.
So I'll use for loop for i in range.
I want i to be in the range of my array, so I'll just use i in range nums.
And then right here, I need to check for an element that
is less than the previous.
So it means-- right now I'm at index i, so what I need to do is--
if an element at index i is less than an element at the previous element,
then I will return that index, right.
That's what I'm looking for.
TOMMY MACWILLIAM: Makes sense.
INNOCENT MUNAI: So sort of like, this.
And then in this case, this has to be semicolon.
All right, this comment should go up because it
describes what is being done here.
All right.
So let me try going through explaining what
happens in each line of this program for my input.
TOMMY MACWILLIAM: All right.
INNOCENT MUNAI: So for i in range nums, and that
means from the very first element to the last element.
so for my first element, this will be two.
And for that case, it will check whether it's less than the previous element,
so it will do this check where i is 0 at this point.
So my numbers 0 is 2, right?
And then, I will check whether it's less than the previous one.
Nums i plus 1, and i plus 1, in this case, is 1.
And nums one will give me three, which is the next element and not
the previous element.
TOMMY MACWILLIAM: Exactly.
INNOCENT MUNAI: So I need to change this--
TOMMY MACWILLIAM: Yep.
INNOCENT MUNAI: --to i minus 1.
And then, right here, what happens is that since it's 0 and it's minus 1,
it will check with the last element, and it will return
whether it's truly less than that.
And if it's not, then it will run the entire loop over and over again,
and come up with the point where the element is less than the previous one.
So for that case, if my algorithm works for this particular input,
I'm going to try to come up with several other inputs
and try to see whether it works for those inputs as well.
TOMMY MACWILLIAM: Sure.
INNOCENT MUNAI: I will come up with one input, when--
let's see.
Let's use this one, the one given from the example, and in this case,
let's say we have 4 right here where we have duplicates.
4 and 4.
So in this case, this is just rotating the same three times,
so we should expect the same number-- like the rotation key to be the same.
And then, I would also think of a situation where we have an empty array.
And in this case, it should just return 0.
TOMMY MACWILLIAM: Yeah, that's fine.
INNOCENT MUNAI: There's nothing that's happening really.
And then in a case where we have the numbers just without any rotation,
and in this case, it should really give me 0 as well.
TOMMY MACWILLIAM: Yeah, not rotated.
INNOCENT MUNAI: All right.
So a number can be on a rake, could be rotated
0 times, 1 times, 2 times, all the way to the length of that array,
or even more than that.
So in this case, I would check to see whether if this array would be rotated
five times, which is the length of the array, it would sort of go in a circle
and still be the same.
So it means my test case is cover when arrays
rotate at like, at 0 times, rotated like the maximum times,
and like, all the middle cases.
So my assumption is that if my algorithm works for these cases,
it will work for all cases.
TOMMY MACWILLIAM: Yeah.
That looks right.
INNOCENT MUNAI: Yeah.
So you have maybe any ideas of more test cases?
TOMMY MACWILLIAM: Yeah.
Let's try a few these, and let's try running it.
See it works.
INNOCENT MUNAI: Sure.
So first I will work through this with one of my age cases.
And in this case, let's say the empty array.
So it will go through the empty array, try to check,
but it won't return anything.
But I want-- if there is not any element in that array,
this loop won't be executed.
So I want to handle that case too.
So in this sense, I might have to have return zero, just
to account for the case when this loop won't be executed.
And that's for the empty array.
TOMMY MACWILLIAM: Makes sense.
INNOCENT MUNAI: All right.
So now I think I should run some--
TOMMY MACWILLIAM: Yeah.
Let's try running it.
INNOCENT MUNAI: All right.
Sure.
So I will say if name is main, I want to run the main function.
So I will sort of print, calling this function onto several inputs.
Let's see.
So I just want to order inputs in the same--
so I'll just do this one and then take this one.
Put it right here.
Second input three.
Oh no.
TOMMY MACWILLIAM: No worries.
I have some hot keys, that's all.
You're good.
INNOCENT MUNAI: All right.
Then I will take this input, pass it to this function, this time around.
TOMMY MACWILLIAM: Yeah, let's try just these two.
INNOCENT MUNAI: Oh, yeah.
Sure.
So I'll just run this.
Oh, it yells at me.
It tells me this object cannot be interpreted as an integer.
Oh, that's true because at this point here
I needed my range to be from 0 to like one less the length of the nums array.
And I know that there's a function that can give me the length of nums.
Do you happen to know what it is?
Could I just--
TOMMY MACWILLIAM: Yeah.
Len is right.
INNOCENT MUNAI: Len is right.
Thank you.
So I'll just call Len here, and run the program once again.
All right.
So seems like the first two cases have passed in this case.
I will also try to run this case.
TOMMY MACWILLIAM: Yeah, actually.
Just for time, I think we can actually pause there.
So thanks so much.
INNOCENT MUNAI: All right.
TOMMY MACWILLIAM: We'll pause there for the interview.
[APPLAUSE]
So observations from folks.
What went well and what could have gone better?
Overall I think this was great.
AUDIENCE MEMBER 9: Well, the best part I thought
was the communication was so consistent in every step of the process,
as well as this is a big part of any interview, the tone of respect
he had for you as he was going through the codes.
TOMMY MACWILLIAM: Yeah.
I totally agree.
The communication was amazing.
You sort of saw it at every step along the way,
sort of vocalizing exactly what he was thinking, and sort of doing that.
It's a tough tightrope to walk, talking what you're thinking and writing
the code, but that's exactly what you want to be doing in an interview.
Exactly what we just saw.
What else?
Yeah.
AUDIENCE MEMBER 10: Kind of adding on to that idea,
I like before he actually got to typing up the code,
he wrote out into his long process in comments.
It works as a guideline, but also you as the interviewer
can see his long process.
TOMMY MACWILLIAM: Yeah.
That's exactly right.
We aligned on a solution before he started typing, wrote that out
in pseudo code, and the two of us were super confident together
that he was on the right track.
Maybe one last thing, and then I'll add what stood out to me.
Yeah.
AUDIENCE MEMBER 11: The fact that he didn't panic when the code didn't
go how he expecting it to.
TOMMY MACWILLIAM: Yes.
I don't know if that was planned on your end or not,
but I thought the way you react is exactly how you
want to react in an interview.
So you didn't panic.
So it looks like here's the error, read the error message.
A lot of people just see red, and they're like [YELLS]..
You sort of read it, and then asked me is it Len or sighs.
I was confirming that with you.
So I thought that was really great.
Maybe I'll just add a couple other things
that I really liked as the interviewer.
So one is you caught a bug proactively and fixed it.
You sort of saw how running through the code verbally,
you can kind of catch those things.
So I thought that was really, really great.
And then, I thought the other thing that was really great
was sort of thinking about all these edge cases as well.
So we took a lot of time up front agreeing on inputs and outputs.
And I think because we spent so much time
up front, that's why this went so smoothly
and we're able to cover all the cases as we went.
So as the interviewer, those are two things
that stood out to me in the really positive direction.
So thanks so much for the mock interview.
We appreciate it.
INNOCENT MUNAI: All right.
[APPLAUSE]
TOMMY MACWILLIAM: All right.
So I have some closing thoughts here.
And I want to make sure we have at least 15,
20 minutes or so for questions for me about whatever is on your mind
when it comes to interviewing.
So last we're going to wrap up with after the interview.
Usually, at the end of an interview, the interviewer
will leave you five minutes or so at the end of the interview to say,
what questions you have for me?
Have some questions ready in advance.
Can anyone think of a question they've asked an interviewer before,
or that they might want to ask an interviewer.
I'll give you some examples, but want to hear some from you too.
Yeah.
AUDIENCE MEMBER 12: What's a day in your life?
TOMMY MACWILLIAM: Yeah.
That's a good one.
What is the day to day life look like at your role?
What else?
Yeah.
AUDIENCE MEMBER 13: I guess, what is--
if you have an end goal, what is the end goal with something technical,
like these type of tools to use, and like,
why are you even coding in general?
TOMMY MACWILLIAM: Yeah.
That's a great one.
So what are the big problems your team is solving?
What are you really trying to solve at a higher level?
I love that.
Maybe one more, and then I'll give you some ones that I think are good.
Yeah.
In the back.
Sorry?
AUDIENCE: [INAUDIBLE]
TOMMY MACWILLIAM: Yeah, that's a great one.
What have you learned recently?
What has been your experience, and where are you growing?
I think that's really great.
In general, try to bias for questions-- exactly, day to day is the first one.
Try to bias for questions that aren't Google-able.
Like asking questions like, how many employees are at your company,
or what year was your company founded?
Highly Google-able.
You're like, not using the best use of your time
or your interviewer's if that's the type of stuff you're asking.
Instead, try to ask questions that could only
be answered by someone at this company.
Things like their day to day, their team's culture,
what they like about their team, what they would want to change, something
they're proud of, what their growth path has looked like.
These are really great questions for you to get
a sense of what it's actually like to work at this company,
and for your interviewer to share a bit more about their personal experience,
which is going to be way more valuable than some stat around fundraising.
So the last thing I want to say with after the interview, don't worry.
Interviews are very, very, very high variance.
Everyone bombs interviews, myself included.
I like to share this story.
I was once interviewing at a large social network
site that will not be named.
[LAUGHTER]
The question was something around like, traversing a binary tree.
I decided that OCaml would be the best language to write this in.
Nope.
So I totally bombed it, and a lot of people are like, no Tom.
You didn't do that bad.
I did because when I was walking out of the interview, I
my interviewer was in the elevator with another interviewer
from this large unnamed social network talking
about how bad I did in the interview.
So I like, walked into this elevator, I was like, oh that--
really no doubt that I bombed that interview.
So it happens to everybody.
If it happens to you, don't worry.
Interviews are not fun, and they're really high variance.
There's a lot of candidates who just-- you get a question
and it just doesn't click, and then they don't do well
and they don't move forward.
But I bet they're a great candidate, and they would have possibly
been a great addition to the team.
But just the whole variance of interviewing, don't worry about that.
View each interview as an opportunity to get better.
It's really easy to get discouraged when you're constantly
getting no's all over the place from different companies,
but try to view that as a growth opportunity,
reflect on what went well, because it wasn't all bad probably,
as well as where you can improve, and try to grow and get
better and better at interviewing.
It's a skill.
It's a muscle you can develop.
Nobody has it out of the gate.
And you're not going to pass 100% of your interviews.
If you do, maybe you can join me up here next year.
But don't worry if you don't do well on some of your interviews.
So some takeaways from the talk.
Number one, make sure you have the basics down.
This is the best way to reduce stress and increase your success
rate of technical interviews.
Number two, build out your toolbox.
Be familiar with all the concepts and tools you can
use to solve a problem in an interview.
Number three, do lots of realistic practice problems.
Sit down, time yourself, don't just look at the answer key.
Actually walk through the solution, and communicate a solution
before writing code.
Verbally run your code, look for issues, make
sure you're creating this bidirectional conversation with your interviewer,
and in case you thought I wouldn't show this slide again,
it's about the process, not necessarily the output.
So think about how you're getting to that answer
and how you're working together with your interviewer.
So that's the end of the talk.
I'd love to take questions from the audience.
[APPLAUSE]
Yeah.
AUDIENCE MEMBER 14: What are some resources
that you suggest to find like, technical interview questions?
TOMMY MACWILLIAM: Yeah.
So what are some resources for finding technical interview questions?
So we'll put some links in the Zoom chat.
So one is Leet Code has a ton of stuff.
What's cool is you could sort of write the code and run it and see solutions.
Project Euler is another one.
Just a lot of problems.
Cracking the Code Interview is one of those books that
just has a ton of practice problems.
But honestly, even just googling around.
Like, if you find yourself like, man, I just
can't get recursion no matter how many times I've done it,
just googling practice recursion interview problems,
you'll probably find some good sites.
Like Geeks for Geeks is pretty high on their SEO there.
So, yeah.
Those are some good ones I'd recommend.
Yeah.
AUDIENCE MEMBER 15: When you're-- two questions.
One, when you're searching for internships that are technical
or to find technical interviews in general,
do you remember when you were searching for internships, if you ever did,
what the best process was to do this?
And number two is when trying to feel ready enough
to apply to one of these tech internships, other
than building your toolbox, which is when
we saw specific examples, what makes you get to the point where you're like,
yeah.
I'm ready to go for this interview stage.
Because at my point of coding, I don't think I'm ready for that right now.
TOMMY MACWILLIAM: Yeah.
That's great.
So two questions.
One is how to top a funnel sourcing for companies to apply to,
and then two is how do when you're ready.
So number one, I think honestly a really great thing
is to just like open your phone and look at the products that you use every day.
Those companies are probably hiring interns.
As well as talking to friends and other people in--
if you're in CS--
excuse me, the CS department, hearing about what
internships were really great.
Many companies, including us, are recruiting on campus,
so try to join the email lists a company blast out these events and invites on.
Those are some ways to identify things.
And then how to know when you're ready, it's kind of tough.
Everyone's a bit different.
For me, there gets a point where I'm sort of refreshing these practice
problems.
Maybe I get like, three in a row, and I'm just feeling a bit more comfortable
or I'm solving things consistently, maybe not 100%
correct 100% of the time, but in general, I'm given a problem,
I can probably get most of it in 30 minutes or so.
But again, everybody is really different,
and even the difficulty of problems is going to be different
and depending on how far you are in your CS career.
But I'd say the best way to learn is honestly
by going and doing the interviews.
Simulating is great, but if you interview a few times
and you totally bomb them, that's a really, really valuable experience.
So don't wait too, too long before just jumping in.
The worst thing a company can say is no.
Well, the worst thing they do is tell you in the elevator how bad you did.
The second worst thing I can do is say no.
And so don't worry too much about that.
Yeah.
AUDIENCE MEMBER 16: Do you have any suggestions
for things you did at Harvard that you felt like were very beneficial as you
entered your career?
TOMMY MACWILLIAM: Yeah.
So stuff I did at Harvard that was really beneficial for my career.
So some classes, I think, are just better geared
towards getting good at interviews than others.
124 I'd recommend.
182 they do like graph algorithms all day long,
or at least they used to when I was there.
So classes that are a bit more data structures or algorithm
focused, I think, are really good.
Another thing is I tried to join all these different email lists.
And I can't tell you the names of them any more
because they're probably all different, but try
to get on the lists for a bunch of these different events.
There's no like-- a lot of times there's no invite lists.
Just sort of like, if you knew that Figma
is going to be in this room on this day you can show up.
So try to get on all these different lists
and look out for events just to learn about companies,
learn about opportunities, and also just meet more folks who can get to know
and practice with.
I was on like, every email list you could think of.
AUDIENCE MEMBER 17: How did you find those?
TOMMY MACWILLIAM: I would just sort of ask around friends, like oh
like-- if some friend was like, oh are you going to the x event?
And I was like, not only what is that event, two
how did you find out about it?
And then go and join that.
Yeah?
AUDIENCE MEMBER 18: How important are career fairs?
TOMMY MACWILLIAM: Yeah.
How important are career fairs for recruiting?
I think as you're thinking about what companies
do I want to apply to, even like what companies are out there that
are hiring interns of some given degree, I think there they're really, really
helpful.
Oftentimes, it can be great to meet a recruiter and give them your resume.
For many folks, it doesn't make too much of a difference
whether you like meet a recruiter in person versus
apply through the early career channels.
So I'd say they are more useful for you to find opportunities
you're excited about that are sort of aligned
with your experience and your skill level, as opposed to,
oh this is my in, like I gave a paper copy of my resume to some recruiter.
Yeah.
AUDIENCE MEMBER 19: Any advice that could be particularly more helpful
for PM interviews.
TOMMY MACWILLIAM: Yeah.
Any advice for PM interviews?
I would say that PM, of all the interview
types we talked about here, I'd say the PM interviews
are most or closest to the systems design and values interview.
Values is sort of someone that anyone's going to go through.
So I'd spend some time thinking about that.
A lot of PM interviews are about critical thinking like,
pick an app on your phone and tell me how you would make it better,
or here's some problem.
Maybe like, Uber is thinking about expanding into jetpacks.
How would you think about the go to market?
It's sort of like that type of problem to think about,
which is more less about writing code and more about critical thinking.
So there's lots of example problems online for not just engineering
interviews, but other domains.
And so I go through this same process of getting used to it,
building that toolbox, and be getting comfortable.
Yeah.
AUDIENCE MEMBER 20: How many companies would you
recommend applying for in one season?
TOMMY MACWILLIAM: Yeah.
How many companies would I recommend applying for in one season?
It's a really good question.
It varies a bit.
I'd say that, especially early on, interviews can be tough,
and as you're sort of building up that muscle, you might have a higher number.
I'd say, a good number is maybe in the like five to ten
ballpark on like, the high end.
Like if you find yourself applying to like 20 different companies,
and you've got like three on sites a day every day for two weeks, that's
probably too many.
But if you're only applying to one or two,
it can be hard to get the full breadth of experience.
And there's a reality thing here that is at some point,
companies will sort of fill up their intern class.
And so if you're sort of waiting until January or February to start applying,
sometimes it could be harder to get an internship.
So make sure you're not like, spreading it out too much either.
Yeah.
Well, thanks so much for coming.
I'll hang up here--
Hanging up here to answer any other questions you have.
But thanks so much for coming, and best of luck on your technical interviews.