DAVID MALAN: All right.
Well, hello, world!
This is CS50's now annual workshop on how
to prepare for technical interviews.
This is an opportunity that we hold traditionally on campus and nowadays,
also on Zoom, for students here at Harvard, at Yale University, as well
as now anyone online who are thinking about pursuing summertime opportunities
in the technology world or full-time opportunities after school
or perhaps are pivoting later in life and are exploring
computer science and programming and software engineering
and want to ultimately move into that world.
This workshop is specifically on how to prepare for the kinds of interviews
that you might encounter in industry.
It's one thing to take classes like CS50 or anything
else that sort of prepare you indirectly for a foundation in software
engineering and the like.
But it's another thing to actually ready yourself
for the concrete opportunities that might be of interest to you
at a tech company or really any other company at which you might
be applying your technical skills.
So thanks to CS50's own Tommy MacWilliam,
who was one of CS50's former head teaching fellows today,
we should have an amazing workshop for you
that should give you the mindset of how to go about preparing for interviews,
how to go about preparing your resume, and really, ultimately, how
about applying what you might learn fairly theoretically in school
to the actual practical world of interviewing and ultimately working,
as well.
And wonderfully we're joined here by some
of our other former and current head teaching fellows, Maria and Connor.
So allow me now to introduce our friend and former colleague, Tommy MacWilliam,
who most recently worked at companies like Quora.com
and most recently his own startup, Serenade.AI.
Tommy is hands-down one of the smartest people and best engineers
I've ever met.
Indeed, in preparing for today's interviews,
I got to thinking that I'm not sure if Tommy interviewed me,
I would get the job.
And so it's always quite interesting to hear about the advice he has,
the types of experiences he's had, because not only was
he a former student and a former teaching fellow,
and now go out there in the real world, hiring and building software,
he's really seen it all.
And so I think we're fortunate to have, not only him,
but also Maria and Connor joining us here today.
And so without further ado, Tommy, welcome back to CS50.
TOMMY MACWILLIAMS: Thanks, David, it's always great to be back.
I love doing this interview workshop and helping everybody
think about how to prepare their resume, get ready for interviews,
do a great job interviewing, and then think about what to do after that.
I've been on both sides of interviews.
I've probably done thousands of interviews as the interviewer.
I've also been on the other side, and I've also bombed interviews myself,
so I know exactly how that feels.
And helping with this workshop, I'm really
hoping to help everybody just give the best interview performance they can
and really demonstrate the skills that you have as an engineer.
So joining me today are Maria and Connor,
so I'll turn it over to Maria to introduce herself, as well.
MARIA ZLATKOVA: Hi, everyone, super awesome to be here,
and very excited for our session today.
I used to be [INAUDIBLE] in CS50 years back until 2018,
since then have worked at Instagram as a software engineer
and most recently as a co-founder of my own startup called Kangaroo.
And I'm very excited to be here today.
As Tommy said, I've also bombed my very fair share of interviews.
I have some very clear memories of the ones I bombed.
I've also been on the other side, done probably hundreds, definitely not
thousands, at Tommy's level just yet.
But the interview process is definitely something
that I'm eager to help everyone master, so I'm excited to be here.
And I'm going to hand it off to Connor.
CONNOR LEGGETT: Right, hi, everyone.
I am Connor.
I am currently a head CA for CS50 at the college,
and I am currently a junior at the college.
So I am applying for internships for next summer, 2023--
or yeah, 2022, sorry.
And so I have been having several interviews a week for the past week,
so I'm right in the middle of it.
And just like other people have been saying,
I've had some of those interviews go very, very well and some of them
go very, very badly.
So I'm really excited to learn more about how
to help those go a little bit better than they could, possibly,
and also to help all of you get started in interviews.
TOMMY MACWILLIAMS: So today, we're going to cover a few different things,
sort of the entire interview process from end to end.
So first we're going to talk about how to choose companies and pick
opportunities that are great for you and where you're
going to have a great experience.
Next, we're going to talk about resumes.
I'm not going to spend a ton of time on this, but just some quick simple rules
for putting together a great resume.
Then we'll talk a bit about how to prepare
before a tech interview happens.
Then we'll walk through during the interview, what's expected for you,
as well as some tips and tricks for doing well in the technical interview
portion itself.
Then we're going to have a couple of mock interviews, so one with Maria
and one with Connor.
We'll simulate an actual tech interview.
We'll use real questions that I've used in the past,
so these just aren't fake, random questions,
but these are real questions that you could see at a tech company,
and we'll go over some techniques there.
And then last, we'll wrap up with some things you can do after the interview
and looking ahead as you improve your interviewing skills.
So the first thing I want to talk about is choosing companies.
So obviously, as you're looking around at internships
and full-time opportunities, there are so many companies and opportunities
out there.
And so what you want to do is help narrow that down into a small set.
Nobody wants to be doing 500 interviews a month.
You're going to exhaust yourself, it's tiring.
And so the more you can narrow down your selection up front, more efficient
you can be in your interview process.
So I come up with here just four questions
that you can ask yourself as you're evaluating
the space of possible companies.
So the first thing you'll want to ask yourself
is, what are you looking for out of this internship or this full-time role?
So for some folks, especially if you're early on in your career,
the thing you might be looking for out of an internship
is you really want to maximize for learning.
You really want to go somewhere where you're
able to have a lot of mentorship, where you'll
be in a space that emphasizes learning and even
failure as a learning mechanism.
And that might be different than somebody
who, say, is five or six years into their career, and rather than learning,
they're looking for something more of a leadership role or to be in a place
where they can have more impact and take on more responsibility.
So I'll say that everybody here is different.
You might have friends who are also interviewing,
and maybe what they're looking for is an opportunity in some specific city,
and they really want to be there.
And then you say, oh, should I should I go there too?
That's where my friends are going.
Not necessarily.
Everybody is really, really different.
And I think when I was interviewing in college,
something that I kind of got bogged down in is, well, I think I want this,
but my friends are doing all these things that are different,
so maybe I should do that too, when the reality is
that everybody is really different.
And so just ask yourself, what are your goals,
and what are you looking to get out of your next internship
or full-time opportunity?
The next question that I would ask yourself
is, would you be excited to work with this team every day?
You're going to be in an internship or a full-time role,
you're going to be working with these people a lot on their mission
and on their products a lot.
And so I'd make sure that you're as excited as you can be about that.
During the interview process, you'll have a lot of opportunities
to meet with different people on the team and hear their stories
and ask them questions.
And that really is an opportunity for you to get more information about,
is this a team that I'd be excited to join?
Is their working style something that aligns with my working style,
their goals align with my goals?
And so it's really a good opportunity to ask yourself that.
I think a similar question here is whether or not
your values align with the company's values.
So in many, many, many tech companies, you can find on their website
or on their careers page something with values.
And a value is basically something that this company values more
than other companies.
So for instance, a company value might be something like--
an early Facebook one was, done is better than perfect.
And what that communicated was that we're not a bunch of perfectionists.
If you're the type of person who wants to get everything perfectly correct
and be super pedantic, then this isn't the company for you.
Because we're the type of people who are going to get things done just as
much as they need to be, maybe 80% of the way
there, and then ship it and iterate and get feedback.
And that value isn't necessarily good or bad.
It's just something the company has decided about their own workflow.
And so you can look at the company values
and can compare that to your own internal values and say,
is this going to be a good fit for me?
The last thing to ask yourself is whether or not
this company size matches what you're looking for.
I've talked to a lot of candidates in the interview process.
So I'll ask them, what size company are you looking for?
And they'll say, I don't know.
It doesn't really matter.
I could join a four-person company or I could join a 4,000-person company.
And the answer is, it does matter.
That's maybe a bad answer to that question,
since your day-to-day experience at a four-person company and your day-to-day
experience at a 4,000-person company, they're just going to be really,
really different.
No matter how much the large company says, oh, we're just like a small team,
or no matter how much a small team says, but we're
really organized and stable like a large company, the reality is just
there's some things that become possible and impossible at various company
sizes.
So this is a chart that I really, really like.
I think it was originally published by Dustin Moskovitz at Asana.
But it breaks down startups into these three different categories,
based on how many people are there.
So you can see, at a small company, mentorship doesn't really exist.
People help you as you need it, but there's
no sort of formalized internship program.
Your autonomy is just like, whatever you've got to do,
you figure out what you have to do, and then you go and do that.
It could involve wearing a variety of different hats,
being in a variety of different roles.
And then on the other end of the spectrum
is a large company, where you're going to be hired into a specific role,
onto a specific team, where maybe you're a backend engineer hired
onto the infrastructure scaling team for the machine learning
at this company, which is much more narrow.
Your agency there is, you're going to have much more clear goals set
by the team, set by management.
So it's very much not to just figure out whatever
you need to do, and then do it.
It's going to be, here's our team's goals
for the quarter, here are the metrics we're trying to hit,
here are the projects that we think are going to make those metrics possible.
And mentorship can be much more formalized.
You might be assigned a formal mentor on your first day,
have a variety of different support systems, internal documentation,
things like that.
And again, something I really want to emphasize here
is that there is absolutely no right answer.
Everybody is really, really different.
And as your career progresses, what you're
looking for might even change over time.
So definitely don't look at this chart and say, oh,
the small company's the best or the medium company's the best.
It's more about what's the best for you, not
the objective, correct answer for what to do after you graduate college
or what to do as the second company you join in your career.
You'll probably read a lot of blog posts on the internet claiming
there's some objective truth here, but I promise you, there is not.
And so it's more about reflecting on what you're looking for yourself.
So that's it on choosing companies.
I think really the takeaway here is just spend a little bit of time
up front narrowing down your search and also reflecting
on what you're looking for personally.
As we'll see later, a really common question in interview
is, what are you looking for, and why would you want to join this team?
And so the more you can reflect on that up front,
the better you're going to do on those types of questions.
So next we're going to jump into resumes.
And the first thing I'll say about resumes is they are not that important.
So a lot of people spend a ton of time agonizing over,
should this be a em-dash or a semicolon in my resume?
Which is going to get me the job?
The answer is that it doesn't really matter that much.
I think on average-- we've talked to a lot of recruiters,
I've been a hiring manager myself.
I'd say the average amount of time I spend
reading a resume is about 30 seconds.
And so as you're creating your resume, really, really optimize for that.
The person reading this is not going to spend more than a minute
or so reading it.
And so what I've done is I've created these 10 resume
rules that are all pretty simple.
As long as you follow them, you'll probably have a pretty good resume.
But before I jump into my rules, I'd love to turn it over to the audience
and hear, what are some resume tips that you've heard in the past?
DAVID MALAN: Tommy, Martin mentions one page.
Jessica notes that resumes mean a lot in South Africa.
Anna proposes that it be easy to read.
Johnny mentions keywords.
Rocky mentions targeting for the job.
Assard mentions concise.
Jessica also notes to add skills in it.
Abhishek echoes the sentiment that it should be one page.
Keep it plain says, Tamika.
Moaz says one page, also nothing too colorful; concise and clear;
not to make it too long; skills at top; focus on the role you played;
tech stack on top; clear font; has to be concise.
I think we can keep going and going here, Tommy.
TOMMY MACWILLIAMS: Yeah, lots of great advice there.
I love a bunch of people piling on the concise, simple, and often takes
the form of one page.
I think if I had to give one piece of advice, it would be that, as well.
So here are my 10 rules that, as long as you follow these,
your resume is going to be in good shape.
So number 1-- one page, no exceptions.
There's a lot of folks--
and again, this is going to vary a little bit by role,
so I guess here's an exception to my no exception.
If you're in academia, for instance, a really long CV is much more common.
But if you're looking for a typical tech job,
one page, and don't make any exceptions there.
The author of Python, the person who created the Python programming
language, he used to be at Dropbox.
And at some point, he published his resume and just said,
oh, here's what mine looks like, and his is one page.
And so if the person who created the Python programming language
can put all of his achievements and skills onto one page, so can you.
Number 2-- I think folks mentioned this, as well--
is make it really easy to skim.
As I mentioned, the person reading this resume,
they're not going to spend hours poring over every little detail.
And so if you make it really hard to find key information like,
what is your name, what is your email, what roles have you had in the past,
what are your technical skills, if that's hard to find on your resume,
they could just end up giving up on your resume
and not taking the time to try to find it.
So keep in mind, the person reading this, they're trying to go fast.
Make it easier on the reader of your resume to find important things.
Number 3, make your contact info obvious.
I've had resumes in the past where I've said, wow, this is great.
Some recruiter just passed it along to me, this resume looks great--
no way of contacting the person on the resume.
There is no phone number and no email, no link to a portfolio, anything.
So it's like, OK, now what do I do?
And the recruiter had to go and track them down, which was a pain.
So the whole point of your resume is to get in the door
and start the interview process.
So make sure it's really easy for the company you're
applying to actually reach you.
Number 4, you want to highlight specific accomplishments.
The more specific and concrete your resume can be, the better.
So rather than having a line on your resume like "improved company
metrics"-- it's really vague--
what are the metrics?
What does improved mean?
Improved by how much?
As much as you can, be specific on your resume.
A line that said, "improved the performance of our critical machine
learning ranking system by 23% by implementing
backend optimizations like improved caching," that was super specific.
I gave a metric, I said what the system was, I said what I actually did there.
The more specific you can be, the more that a recruiter or a hiring manager
can understand what your actual impact was, and that often
reflects well on you.
I will say that some companies will have nondisclosure agreements, where
you might be working on a project that hasn't launched yet.
Or some metrics might be confidential and internal to the company.
So certainly don't break any of those nondisclosure agreements.
But many times, metrics of the form--
improved performance or scaled some system to some number of users--
those are the types of things that are typically public
and that you can put on a resume.
If you have any doubts, you can also just ask your manager or someone
at the internship you're at.
Just say, hey, this is my resume.
Is it OK if I disclose this particular metric?
Next, definitely include interesting personal projects.
So especially for folks who are a little earlier on in their career
and might not have experience at multiple companies yet,
definitely include personal projects that you've worked on.
Maybe that could be an interesting final project for a course.
Maybe it could just be something you built in your spare time.
But it's something that's great to highlight
to show that you have a lot of passion for what you're doing
and show off what you're capable of building.
I will say, I'll caution against, if you're
able to have a project that's a little more unique
and something that you designed yourself, compared to--
many courses have a final project that everyone builds the same thing,
and it's kind of standard.
I would highlight something that you created yourself,
rather than some kind of standard final project, if you're able to.
But if you're not, that's OK too.
Something here is certainly better than nothing.
Next, no charts or ratings--
this is maybe my number one resume pet peeve.
A lot of people have on their resume some chart that says, I'm a 5 out of 10
at JavaScript, and I'm a 7 out of 10 at CSS.
To me, this is just a total waste of space.
I have no idea what your 7 out of 10 at CSS means.
Is the inventor of CSS a 10, or is someone
with three years of experience a 10?
It just makes no sense.
A lot of people try to do this as a way of kind of creatively expressing
their tech stack.
I really don't like it at all, and it doesn't
communicate the information you think is communicating, more likely than not.
Next, I would not have a specific objective on your resume.
Many resumes I've seen have at the top some objective
that says objective, colon, to secure a spot as a software engineer
able to have impact on this company.
It's a total waste of space.
We know that the objective of you handing me a resume
is to get a spot at the company that I work at.
So it's a total waste of space.
You've only got one page to work with.
Putting that there doesn't really offer a lot of value.
Again, there might be some exceptions here in different industries,
where maybe it's not actually clear what role you're applying for.
But in the case where you've gone through some sort of online application
that says, here's the role I'm applying for, or you're talking to a recruiter,
and it's really clear what role you're applying for,
don't waste space with an objective on your resume.
Number 8, use a professional email address.
I remember one resume I got--
I forget what the person's name is-- and they
said it was their name, 123456789, 87654321,
and that was the email they used.
And I was like, you've got to be--
I instantly think less of this person, because this is their email.
If you're still using the same gmail address you used 20 years ago,
just create a new one.
First initial, last name is great.
Last name, first initial is great.
Your full name is great.
It's super easy to create a professional looking email
using Gmail or free email service.
Definitely do that.
Don't have some kind of cute joke email.
Number 9, include relevant links if you have them.
So if you have a LinkedIn, a GitHub profile, a personal portfolio,
especially if you're applying for a design role,
include them on your resume.
I think sometimes a hiring manager, before they interview you,
they might spend a quick 30, 60 seconds skimming through your portfolio
so you'd have something to talk about during the interview.
I've certainly clicked on someone's GitHub, saw, oh, they created
this library for progress bars of the command line.
That's kind of cool.
And I'll ask them about that during our interview.
So that just helps your interviewer understand a bit more
about your background.
And last, definitely don't sweat the aesthetics
and the visuals of your resume.
And many times simpler is much better.
Simpler is often very easy to skim.
But don't worry about things like colors and photos and fonts.
You can create a really simple resume that gets your point across
without having to worry about all of that.
So next I have, a couple example resumes,
and I'd love to hear from folks in the audience things that
are good and bad about these resumes, taking into account these 10 resume
rules.
And I will note that these are fake resumes.
These are not real people.
So we're not roasting anyone on the internet right now.
So here is the first one.
What do people think?
What is good and bad about this?
DAVID MALAN: Tommy, the answers are starting to fly in here.
The skill graph is commented on.
Ratings are bad, too hard to read, the skill bar, the rating
bar is TOO MUCH AT ONCE, in all caps.
Bad, in a word, hard to find information,
charts and ratings are bad, using charts,
two columns are good, more used space, font, CHARTS BAD, all caps, bars,
scale bars equal bad, hard to skim.
Progress bar must not be included, BAD in all caps--
I think I'm now encouraging it.
And there seems to indeed be a theme developing.
TOMMY MACWILLIAMS: Yes, I'll go through a few things about this.
So the first thing that I like about this
is that under the work experience and education,
it's pretty easy to skim there.
So I can see they worked as a data scientist.
For some reason, in the two work experiences,
they changed the order of the role and the companies.
That's a little weird.
But otherwise, I like that it was really easy to see what their experience was,
where they worked.
The content of the resume here, I'd say it's reasonably specific.
I'd say, saying that they collected and studied interpreted large data sets
to develop new forecasting models--
I think that's pretty good.
I'd say the part, I'd make it a little more specific,
because if you can be specific about how big the data sets were
or exactly what you did to analyze them, I
think that would make this a little bit better.
But I just call this reasonably specific.
This profile at the top, this top left, I think this is a waste of space,
saying that they're a highly accurate and experienced data scientist.
And I look at here, and they have three years of data science experience,
so I don't need to be told how experienced you are.
I can look at this from the resume.
So I don't think that's a good use of space.
Then yeah, I included this one on purpose, because it has charts.
I don't really know what these charts mean.
I don't know if you do, either.
But this person looks like they're a fantastic team player,
but they don't have attention to detail.
And so like they say, well, do I want someone who doesn't have attention
to detail being a data scientist?
I don't know.
I'm not really sure this communicates with what they wanted to communicate
if this person were a real person.
DAVID MALAN: Can I relay a couple of questions now from the chat?
TOMMY MACWILLIAMS: Go for it.
DAVID MALAN: Sergei asks a question about the CV.
Do we need to adapt content in key words for ATS, application tracking systems?
TOMMY MACWILLIAMS: Yeah, that's a good question.
So in many companies, they'll have what's
called an ATS, which is, as you mentioned,
an applicant tracking system.
So it might be Lever or Greenhouse, just some software that you apply to.
And some of these will kind of look at your resume and filter out for keywords
and, say, if it doesn't have the word JavaScript, throw it in the trash.
So I wouldn't go overly--
I wouldn't go crazy and try to put every single keyword on your resume.
But at the same time, just having a short list of languages you know
or technologies you've worked with--
I think even I have this on my resume, just listing out the languages
you've worked with in the past.
If you want it to have a little bit of this or proficient with this language,
or I'm new to this language or something, maybe a little bit of that
is OK.
But in general, just having a quick list that doesn't take up a lot of space
is what I'd recommend.
DAVID MALAN: And Tommy, another question was asked, which might vary,
I imagine, by country.
Provolika asks, should I add a photograph to the resume?
TOMMY MACWILLIAMS: Yeah, this might vary by country.
I would say that if you're applying to a US tech company, I wouldn't do that.
It just falls into the same category.
It's a waste of space.
You can probably change that photo and put much more detail
about the impact you had at an internship or a company.
But again, this is going to vary a bit by country, and it's hard for me
to speak to too much outside the US.
But within the US, I would definitely not do that.
DAVID MALAN: I'll continue to chime in, Tommy, as more questions arise.
TOMMY MACWILLIAMS: Awesome.
So let's jump to the next resume, things about this that are good and bad.
DAVID MALAN: And as the comments start to come in, Tommy--
too long, verbose, too convoluted, too much text, it's a dissertation,
unstructured.
Is that a page from a novel, question mark?
Hard to read, hard to skim, looks like a wall of text.
Your school email will eventually expire,
so I wouldn't use that, hard to read, very hard to read, hard to skim,
it's too much.
And there seems here to be a theme.
In fact, Jose perhaps says it best, TLDR, too long, didn't read.
TOMMY MACWILLIAMS: Yeah, I think that's sort of the same reaction I have here.
I'll start with the things that I like about this.
The sort of middle section here where it says "core expertise,"
I actually like this.
If you were-- this is an engineering manager,
and so their expertise here might be a little bit different.
But seeing that they have experience in vendor relations
or global projects and managing different time zones,
that's pretty interesting.
If you're an engineer a data scientist, a designer,
this is probably where I'd put your languages or technologies you've
used in the past.
But this is actually kind of a nice way of-- maybe the only part of this
that skimmable, but this is a reasonable list where I can quickly skim.
Yeah, my main feedback on this resume is basically
what everyone else mentioned, is that there's just so much text here.
The font is really, really small.
It's not really skimmable.
To find the companies they worked at is shockingly difficult.
Even though they're in all capital letters,
it's pretty hard to see where they actually worked.
A good thing is that their name and the contact information
right at the top-- that's nice.
But then again, this sort of top section here where they're
writing, "merging visionary leadership with technical software engineering
expertise," my reaction is like, OK, don't need to have that.
It doesn't really add any value.
So that that section at the top could be removed
in favor of making this a little bit easier to skim, not having so much text
crunched in here.
So I'll pause for any questions.
Yeah.
DAVID MALAN: Some questions came up from Remington.
If I'm a non-CS major, what would be the best
way to add courses such as CS50 to my resume, and perhaps
massive open online courses outside of college more generally?
TOMMY MACWILLIAMS: Yeah, that's a great question.
I put it in that same section where languages you've used,
technologies you've used, courses you've taken,
especially for undergrads or even people making a career shift,
where they don't have a lot of that experience yet.
We'd love to see courses, especially online courses,
to show that you've taken the initiative,
and you've gained some certain set of skills.
So I remember when I was an undergrad, I had, basically, name, contact, and then
languages I know, courses I've taken.
I'd say CS50, Introduction to Computer Science, CS61, Systems Programming.
And since the course number might not mean something to anybody, so just
highlighting the courses you've taken as an undergrad can be great.
DAVID MALAN: And Tommy, a couple of folks, Pragya and Achin,
have asked about tools to use when writing a resume.
Should they use an online resume maker, LawTech, Microsoft Word,
something else?
TOMMY MACWILLIAMS: Yeah, I would say to use what you're most comfortable with.
I was a pretty big LaTeX person in college,
and so I was a big fan of that.
And so my resume was used in that.
But I wouldn't recommend like, oh, I'm going to learn some new tool just
for the purpose of creating this resume, since you might end up--
it might be harder than the tool that you already know.
So I'd recommend just sticking with what you know already.
If you don't know anything yet, even something as simple as Google Docs
can produce a pretty good-looking resume.
DAVID MALAN: And a formatting question, too-- a few folks
have asked about two columns versus one column in the use of color or graphics.
Your thoughts there too?
TOMMY MACWILLIAMS: Yeah, a little hard to give a blanket answer there.
I would say, write the content of your resume first.
The first thing, most important thing is the content,
where you work, highlighting those specific achievements,
listing out those key skills you have.
So do that first, and then try a few different layouts.
I think people with a ton of experience or a lot of content
might land on a different layout than somebody who is just getting
started and doesn't have as much of that yet.
So I would say, try a few things, see what looks best for the content
that you have.
But if your resume is starting to look something
like this, just this wall of text, then I
would take a step back and reconsider.
DAVID MALAN: And perhaps one final question right now,
amalgamated from Harsh and Kyle, who asked questions along the lines
of, should your resume be job-specific or applicable to any role in tech?
And if someone has unrelated experience, for instance,
from chemical engineering, should you, or how should you
include that on a technical resume?
TOMMY MACWILLIAMS: Yeah, that's a really great question.
So I've seen the spectrum here.
When we were at Quora and also at Serenade,
I've seen resumes that are literally like for Serenade, people
who will talk about, explicitly, Serenade, their background,
and why it's the right fit for exactly our company.
I'd say you can do that.
You don't need to.
I think if you're applying to 10, 20 companies,
doing a good job on 20 different resumes is a lot harder than doing
a good job on one resume.
So where I would make it specific is for the role, not the company.
So if you're applying to an engineering role,
try to put as much engineering-related experience as possible.
If you're applying to a design role, and their resume just
has a bunch of backend engineering stuff,
I don't know if that makes a ton of sense.
I'd try to put in some design side projects you've worked on
or courses you've taken or projects you've built.
And then the question around unrelated experience, I'd say it depends.
I think for some people, they've had a career in,
let's say, I think you mentioned chemical engineering,
and they're looking to make a career transition into another industry.
If that's the case, then for sure, show the experience you have,
show the impact you've had at companies, and make it clear to the recruiter,
or make it clear to whoever you're talking with at the company
that you are making a career pivot.
You've worked in this field for some time,
and here's why you're looking to make this pivot,
and here's what you're excited about.
But definitely don't submit a blank resume,
just because the experience isn't exactly in that precise field.
At the same time, I think if you're earlier on in your career,
and you're an undergrad, I wouldn't just put every club you've ever joined
and everything you've ever done on your resume.
I try to keep it focused to the role you're applying to.
So I guess my answer is a little bit different
if you've had a career that's several years,
and you're looking to make a pivot, versus you're just starting to graduate
college and start to break into tech.
DAVID MALAN: We have an infinite supply of questions,
but why don't we let you go on, and I'll weave them in over time.
TOMMY MACWILLIAMS: For sure, and I'm sure it will save time at the end,
as well.
So that's it on resumes.
Like I said, resumes are really just a tool to get your foot in the door.
When I say they're not that important, that's basically what I mean is that.
I've never been in a meeting where we're talking about a candidate and saying,
well, they really didn't do well in interviews,
but their resume font was just so perfect,
we've got to give them the job.
So when I say that they're not that important,
I mean once you're in the door, your resume no longer matters.
Obviously, your experience does, but the specific typeface on your resume
doesn't matter anymore.
So when I say not that important, just to be clear,
I don't mean spend no time on it.
But I mean, that's the extent to which they matter
is that they're getting you into the interview.
They're not going to carry you through the whole interview process.
So next, let's talk about what to do before the interview.
So the first thing I want to talk about is what to expect.
So with timing, it's always better to interview early.
So especially if you're still in school, whether that's
an undergrad or a grad program, try to interview as early as you can.
To put concrete numbers on this, for a summer internship starting
in May or June, people interview as early as the previous summer.
So I've interviewed people in August 2020 for an interview for an internship
starting in May 2021.
I'd say the peak season is around October, November
of that year for that following summer internship or following
full-time opportunity.
So as much as you can, if you can get into that wave, that's great.
If you can't for some reason, something comes up, or coursework is there
and you have to interview in, let's say, February or March
for a role starting in June or May, it's still possible.
But keep in mind that some companies might fill up their internship class,
and it might be harder to get a role once a lot of people
have already accepted their offers there.
So if you can, interview early.
If you can't, it's not the end of the world.
Also, especially if you're in school, plan interviewing into your schedule.
I'm not going to say try to take some easier courses at the same time
you're interviewing, but if you were to do that, that
wouldn't hurt your interview chances.
It can be really hard to just assume interviews and, like,
oh-- an interview isn't just an hour.
You're going to spend a lot of time practicing.
The hour is going to be emotionally draining.
You're going to be exhausted after that.
So just keep in mind that interviewing takes a lot of time,
and don't think of it as just a couple hour-long meetings you
have to worry about.
And the last thing I say is, look for opportunities
that are geared at your experience.
So in particular, if you've only taken a few CS courses,
you're a freshman or sophomore or maybe early on in your CS career,
there's plenty of internship opportunities out there for you,
especially at larger companies like Google, Facebook, Microsoft.
They have programs explicitly designed for people who
just have a few years of experience.
So look out for those.
Don't apply for the senior manager tech lead role
if you only have a year of experience.
Try to find the role that's designed for you.
You can find these just by looking at the job description.
They'll often say, we're looking for three years of experience,
we're looking for 10 years of experience,
we're looking for zero use of experience.
Even if you have 2.8 years of experience, and it says three,
still apply for that.
But if you have two years of experience, and looking for 10,
that's probably not the right role for you.
So next, just a bit on the process.
So every company is going to have a different process,
but these are the things you can probably expect.
So the first is some online coding challenge.
So many companies, as a first step, they'll
send you a link to some site where you can
go on and solve some coding problem.
Maybe it's timed.
Maybe you're allowed to run your code before submitting it.
I've had things that are just like a Google Doc,
and they're like, here just write your code in this Google Doc,
and whenever you're done, just let me know.
I see a pretty wide spectrum here, but that's often a first step.
And they'll be really clear with you around what the time limits are,
if you're allowed to use external resources or not.
And if they're not, just ask whoever gave you
the challenge what the constraints are.
The next is a take-home interview.
So this will usually take the form of, here's some larger project to build.
Maybe you're supposed to build it in two hours,
maybe they're supposed to build it in two days.
It's going to vary, but will usually be a bit more on the practical side,
will be, write a little command line app that takes this as input
and outputs this, or write a little web application with the login
functionality or something like that.
So that's another interview type you might expect.
The technical phone screen I'd say is probably the most common early step
in the interview process.
And this is what will spend the most time on today is technical phone screen
and on-site, where technical phone screen is often,
you'll meet with someone over the phone or over video,
or an engineer or designer or data scientist at that company.
And they'll still do some technical questions together.
We'll ask you to write some code to solve a problem,
and you'll share your screen and write that code.
And then lastly, on-sites--
pretty similar to technical phone screens often.
Many on-sites are conducted remotely, so you'll just
do this over video, which makes it almost the same as a technical phone
screen, the difference being in an on-site,
you'll probably meet with a wider variety of people,
solve a wider variety of problems.
Maybe you'll do something that's more design-oriented, rather
than just writing code, and we'll go through those.
But these are the four types or four interview settings you can reasonably
expect in the interview process.
So next I want to go through some expectations of you.
So before I give you mine as an interviewer, what I expect of you,
I'll turn it over to the audience.
What do you think your interviewer expects you to do in an interview?
DAVID MALAN: Be honest, says Colleen, Tommy.
Talk, says Jacob.
Communicate well is a theme here too.
Good communication skills to behave professionally, says Aisha.
Be precise, clear communication, being honest, another theme.
Don't say "um" too much, specifically.
Ask questions to clarify, to know enough about the company.
Dress up professionally, being smart, smile,
ask questions, research the company, explain your own projects well.
Good info about the job applying, because--
TOMMY MACWILLIAMS: Yeah, those are all really good ones.
I think in particular, around communication
is maybe the most important thing, being able to communicate clearly
what you're thinking.
How you're approaching the problem is super, super important.
So I have a few more specific ones here.
So the first thing I'll be expecting you to do--
and this is related to communication-- is be able to think through a problem.
So the whole point of an interview is that I'm giving you something
that you've never seen before.
That's by design, because what I'm looking
for is understanding how you would think through this new challenge
and how you would tackle some new problem that
came up if we were working together.
So that's the first thing I'd expect, is your ability
to think critically and think through a problem.
Second, maybe this is obvious and maybe why nobody said it,
because it's so obvious.
But be able to write code that works.
Sometimes that code might not have to be exactly correct, depending
on the interview.
Maybe some interviewers are just looking for pseudocode, rather than perfectly
functional code.
Your interviewer will tell you what they're looking for here,
but we're looking for you to be able to write code that works.
I think if I ask a question that you can only describe like,
oh, here's how I would do it, and I said, OK, let's write some code,
and you say, I don't know how-- that's not great.
It happens more often than you might expect.
But being able to actually write the code for the solution
is something I'd expect.
Next thing is I expect you to be able to fix issues.
So oftentimes when you're writing code, there are bugs.
Being able to fix those bugs, and even better
is identifying those bugs yourself, but not relying on the interviewer
to say, OK, here's your code, here are all the things wrong with it,
and here's how it fix them, instead, being
able to identify problems with your own code
and fixing yourself is something I expect.
Reasoning about runtime is really important.
So if I say, OK, this code looks like it works, how fast is it?
Being able to answer that question is important.
You don't have to do this sort of like-- oh, there's always fancy math
that you might want to do or write a proof.
I'm really just looking for, is this linear,
is this polynomial, not anything much more fancy than that.
And the last one, which everybody mentioned,
is communicate really clearly.
So we really expect you to, whether or not you're right or wrong,
be able to communicate what you're thinking
and why you're thinking that way and make sure that I as the interviewer
can understand you.
So next, just some types of interviews that you might run into.
So the first one is the algorithms interview.
So this is an interview where the solution to the problem
might only be like five or 10 lines of code.
But the challenge is figuring out the algorithm
and behind those 10 lines of code.
So oftentimes in the interview, you might
spend 20 or 30 minutes talking through cases together, whiteboarding,
and thinking.
And then once you see the algorithm, the process
of translating that algorithm into code is usually pretty simple,
and you can just do-- and sometimes the interviewer might be like, OK, great.
Let's just go through this really quick, because the interesting part is over,
because you figured out the algorithm.
The opposite of this is a coding interview, where there isn't really
any fancy algorithm or any fancy trick.
It's just like, hey, we're going to write some code to solve a problem.
That code needs to be really clean.
You might be writing 50 to 100 lines of code
and factoring things out into functions, where the code you're writing
might be straightforward, but there are some interesting design challenges,
or how you'll structure the code.
And I will say, with these two, your interviewer will probably not
tell you up front, like, hey, you're in the algorithms interview now.
But many times behind-the-scenes companies actually do do this.
When they design an interview loop or sort of your sequence of interviewers,
they'll say, OK, the first interviewer, you're
going to ask an algorithms question, second interviewer,
you're going to ask a coding question, third interviewer
are you going to ask something else.
So you probably won't be explicitly told this,
but you can probably tell within the first few minutes
which kind of interview type you're in.
But the more important thing here is, for our purposes,
just making you aware that these different types of interviews exist.
If you find yourself writing five lines of code,
and you think you've solved the problem, that might be right.
If you find yourself writing 150 lines of code to solve the problem,
that might be right too.
Next is a practical interview.
So these interviews are intentionally designed
to be more like real world situations.
So rather than whiteboarding some solution to some problem
that you probably wouldn't actually run into on a day-to-day basis,
these will be, write a web application that implements a to do-list.
Maybe you're applying to Asana, which is a software that
helps you make to-do lists, and they ask you to write a to-do list application.
It's much more practical, because it reflects on the day-to-day work
you might actually be doing.
So that's another interview type that exists.
Another one is systems design.
I'll say that these are certainly more common for folks
who are more experienced and have designed scalable large systems before.
But these will often take the shape of, let's say
that you are designing the back end for Google Calendar.
Tell me about how you would do that.
And then the question ends, and it's your job to say, OK well first,
let's talk about the database.
Here's the database tables I'd create.
And now let's talk about the tech stack I would use.
And these are often really, really open-ended
on purpose, because there is absolutely no right answer.
The goal is to just have a conversation with your interviewer
and go through the process of creating some system together.
So I would say, worry about this the least,
especially if you're earlier on in your career,
because these are often targeted more at folks with more experience.
But it's not crazy that you would get one, even earlier on in your career.
So just be aware that it exists, but I'd say a word about it the least.
And then last is a culture interview.
So this will be an interview, at least one interview,
where you'll write zero code.
You'll just talk with somebody-- maybe they're a hiring manager,
maybe they're from HR, or maybe not.
They're just some person that you'd be working with on a day-to-day basis.
And they'll ask you questions about your prior experience, projects
you've worked on in the past, internships you worked on in the past.
Maybe they'll ask a question like, when you
were at this company, what are some things that the company did well
and some things you wish the company did better?
Or what are some of the biggest mistakes you made?
Or what are the biggest things that you learned while you're at this interview?
And so the way to prepare for these is really just
reflect on your own experience before the interview.
Be ready to talk about-- if you worked at Google last summer,
be ready to talk about that.
Talk about the projects you worked on, talk about the obstacles
you overcame, talk about the team.
Don't be caught off guard if someone asks you, how was last summer?
You're like, oh, I don't know, actually haven't really reflected on that.
It's really easy to just take some time reflecting on your previous experience
and also what you're looking for next.
That's sort of the other half of these questions will be,
what do you want out of this role?
What are you looking for?
And remember those questions that we started with, questions to ask yourself
before the interview.
If you're asking yourself all those questions,
you're probably going to be ready for that part of the culture interview.
Because you've already you've picked this company for a reason,
and so you're ready to answer.
DAVID MALAN: Tommy, a good question that came in was from Sara.
How do act if you can't solve a problem or can't write some code?
This scares Sara a lot.
TOMMY MACWILLIAMS: It's a great question.
I've been there.
I think probably everybody has been there.
So I would say that if you get a question,
and you're not sure how to solve it--
well, I'll say most people when they first get the question are not sure
how to solve it.
And so we'll go through this, but the techniques
are really about thinking out loud, going through your thought process.
You might not be exactly sure, but you can say something
like, OK, well, we know this list is sorted,
so let's think about the different algorithms for searching a list.
There's binary search.
Will binary search work here?
Well, let's see.
Just think out loud like that.
And if you hit a wall-- which you might hit a wall--
hopefully, your interviewer will be proactive about guiding you
along and giving you hints.
But sometimes you just hit a wall, and your interviewer is just
kind of staring at you, and you can just say, you know,
I'm honestly not sure what to think about next.
Can you give me a hint, or can you help me out?
That's much better than just spinning your wheels
and staring at the wall in silence.
Awesome.
So going back into preparing for interviews,
so definitely don't go into interview cold.
Always do some practice problems beforehand.
The amount of preparation you put into an interview really, really
makes a big difference in your success.
Some people go so far as to say that interviewing is really
just a learned skill.
Nobody is good at it by design.
Everybody just-- the more you practice, the better at it you get.
And it's just the skill that you can have by practicing it.
So we'll definitely say that the more you practice,
the more that is probably going to decrease your stress in the interview,
as well.
Everybody knows that interviewing, it's really stressful.
It's scary, there's a lot of anxiety.
The more you've practiced in advance and the more problems you've seen,
the more times you've been in this situation
with somebody asking you an unknown question
and having to think out loud and type--
the more you've done that, the more used to it
you get, and hopefully, the less stressful it becomes.
So definitely do a lot of that in advance.
The second thing I do in advance is pick a language
you're going to interview in, and then do
all of your practice in that language.
So let's say that you like Python.
Great.
Learn Python really well.
You shouldn't have to Google, how do I reverse a list in Python,
or how do I get the length of a list, or how do I create a class.
If you have to spend any time thinking about that,
it just create stress for you.
You just want to have this totally down cold.
Don't even worry about how to create a set in Python, because you've just
memorized it in advance.
And I would say choose one language, maybe two, for some reason,
if maybe you want a backend language and a frontend language.
But you should never be in a situation where
an interviewer asks you a question, and your first reaction is, what language
do I want to use to solve this?
Just have this down already and be ready with a language.
So some things that you should know how to do in whatever language you pick--
one is create a function.
Again, this sounds obvious, but you'd be surprised how many people I've
interviewed who the first thing they asked me
was, how do I create a function again?
Or they had to Google how to make a function.
You should just know this in advance.
Similarly, for defining a class, you might not
use a lot of object-oriented programming,
but sometimes it can be helpful, depending on what language you're
using, to have a class to represent some object
or represent some collection of data.
So just know how to do that in advance.
A lot of interview questions are string based.
And so when I say work with strings, I mean how to create a string,
how to concatenate strings, how to index into a string,
how to make a string uppercase or lowercase, how to get a sub-string.
All of these different standard library operations with strings,
just know them.
Again, the more you have to think about, like, is it dot size or count,
it's just going to make you more nervous.
You're going to create stress for yourself.
And knowing all the stuff down cold in advance
can just make your interview go a lot better.
Same thing with lists-- many, many interview questions have,
take the form, you're given a list.
Those are the first four words of many interview questions are,
you're given a list.
And so just being able to be aware of all these different list
operations like list slicing or concatenation
or removing indexes or pushing and popping,
all of those operations you might do to a list,
you don't want to be asking yourself, is it push or is it append?
I forget.
Just know that.
Same thing with trees--
another really, really common interview question
is you're given a binary tree, you're given some sort of tree,
just do some sort of traversal on it.
So being able to write depth-first search or breadth-first search,
even create a tree in whatever language you're in,
just knowing how to do that in advance is going to save you a lot of trouble.
So next around complexity--
we mentioned that many interviews will just
ask you after you've written code, what's the complexity of this code?
It's pretty rare.
I'll say it's not impossible, but pretty rare
that the complexity they're looking for is n
cubed plus n factorial over something.
It's usually just going to be, is it linear, is it polynomial,
is it exponential?
And that's probably it.
So being able to have these down cold is really, really helpful,
whether something is constant, log, linear, polynomial, or exponential.
Just knowing these five and being able to identify,
is your code one of these five, that's going
to get you through the vast majority of what interviewers
are looking for when they say, what's the complexity of your solution?
So next thing I'll say is to build up your toolbox.
So many, many, many interview problems are
kind of fancy ways of phrasing or framing the same few core concepts.
So here are a few.
So one is recursion or divide and conquer,
basically taking some large problem, being
able to split it up into smaller subproblems
and then solving those smaller subproblems.
So as you're doing practice problems, be really familiar with recursion.
And I think recursion is something that for many people
is really scary, especially if you're early on.
So if it is scary for you, just practice it.
You don't want to be caught in a situation where you get a problem that
probably should be solved recursively, but you're
uncomfortable with recursion.
So the more you practice it, the more comfortable you're going to be.
Definitely don't be put in that situation
because you just didn't want to practice recursion.
Next one is graph searches.
We mentioned this with trees, but many problems just
reduced to, just model this thing as a tree or a graph,
and then just do a search over that tree.
So being able to practice writing depth-first search
or breadth-first search, just do it a few times in advance.
Make sure you're comfortable with it.
Greedy algorithms is another one.
As you're sort of looking around at interview practice problems,
this is often the category, so just being
able to practice these and recognize when something might be there.
We talked about strings.
Many problems are just string manipulations at the end of the day.
So really, as you're practicing, you should
be building up this toolbox as you go and just
be familiar with all these concepts.
And searching and sorting is another really common one.
How do I sort this array efficiently?
Given assorted array, how do I search it efficiently?
And dynamic programming-- this one's a little more advanced.
But if you're taking algorithms classes, dynamic programming
is basically a way to speed up algorithms and sort of cache
the results of problems as you're solving them.
So some tools you have at your disposal--
so when you get a problem, you should really think about,
what tools do I have?
What core algorithms do I know?
What are some core data structures that I know?
And then try to pattern match which of these data structures or algorithms
fits this problem.
So one is arrays or linked lists.
Be really comfortable using arrays, understanding what a linked list is,
and understanding what problems should fit into a linked list or an array.
Hash table is another super common one.
You can sort of ask yourself, OK, given this problem,
can I model this as a hash table?
Does that, therefore, instantly speed up my runtime?
Binary search is another one.
Many, many, many problems that take the form
of find X, or given a list, look for something,
can be reduced to a binary search problem.
So just be aware of that.
And maybe that should be your first check if you get a search problem is,
can I model this as binary search?
Shortest path algorithms or another one.
I think given that we mentioned these a few times.
We've given some tree.
How do I search through that tree efficiently?
And memoization, which is similar to dynamic programming,
but once I've solved the problem, can I reuse that solution
to solve some larger problem?
And we'll go into some examples of this once you get into the mock interviews.
So some more general advice-- as you're practicing,
try to really simulate the environment accurately.
So something that I know I do when I'm practicing is I look at a problem,
and I'm like, oh, yeah, I think I can basically see it.
And then I'll look at the answer and be like, oh, yeah, I could have done that.
But then if I tried to force myself not to look at the answer,
I'm like, oh, actually I don't see it at all.
So really, really simulate that environment accurately.
If you know your interview is going to be 45 minutes,
put a 45-minute timer on your interview.
If you know the interview is going to be on a coder pad,
or it's going to be on a whiteboard, practice on a whiteboard or pen
and paper.
And as you're doing that practicing, look for patterns.
Everybody's different.
Some people are really great at recursion,
some people are really bad at it.
So if you've done 10 practice problems, and you
found that you got them all right except for the three recursion ones,
go practice more recursion.
Everybody is going to be different in what they're skilled and not skilled
at, and so really look for patterns in your own approach.
And then lastly, if you can, practice with friends.
It can be fun to go through practice interviews
with you being the interviewer or your friend being the interviewer
and you going through that problem.
What this does is just simulates the environment
and makes it even more familiar, so that once you're
in that situation of being on a real video call,
writing real code on a Google doc, it's not
the first time you've done that, you're sort of used to it,
it's really familiar to you.
So now some tips for during the interview.
So all of that was what you should do in advance, preparing for the interview.
And so now we're going to jump into, the Google Meet just started,
the Zoom call just started, what do we do?
So throughout this, what I really, really
want to emphasize is that the most important thing for your interview
is your process, not your output.
I've been in many interviews where the person did not get the correct answer,
but we hired them, and many interviews where the person did
get the correct answer, and we did not hire them.
And the reason was, their process was significantly more important.
If you can demonstrate that you're thinking really critically
and that you're able to reason through a problem
and find issues with your solution and optimize it,
even if you don't get to a perfectly correct answer,
that's so much more important than somebody who isn't able to communicate,
who isn't able to think critically, but is
able to write correct code just because they've seen the problem before,
or they got lucky.
Or maybe they did understand the problem,
but their communication wasn't there, and so
it isn't something that you want to hire onto your team.
So throughout all this, really, really emphasize
that it's not the most important thing to get the perfect answer,
but obviously helps.
But your process is so much more important than what you produce.
So the interview will start.
The interview won't start with just a problem on the board,
and someone will say go, but have the interviewer there.
They'll probably introduce themselves and ask you to introduce yourself.
Something I like to do for the call starts to just take a deep breath
and relax.
Tell yourself that it's going to be OK and that every interview is stressful
and everybody hates them.
So take a deep breath, relax.
Have an intro prepared, just like a minute or two,
like, hi, I'm Tommy, originally from Boston, worked at Quora for six
years on back end, looking for my next role,
looking to transition into a frontend role,
because I want to have a lot of impact there,
and I think that space is really interesting right now.
Done.
It doesn't have to be super fancy, but if someone
says, hi, introduce yourself, and you're scrambling,
and you don't have an introduction ready,
it's getting yourself off on the wrong foot.
So just have something ready.
They might also ask you tell me about the recent project you worked on.
Have a quick three minutes ready to go there, but don't ramble.
This is meant to take three to five minutes,
just make sure everybody feels comfortable.
So if you're introducing yourself for 30 minutes, which I've had people do,
you're probably doing it wrong.
And then you'll get the problem.
So after the intros, the interviewer will give you
the problem that you're going to solve.
First thing-- don't panic.
You're going to get a problem.
You're probably not going to know the solution off the top of your head.
That's expected.
Don't freak out.
If you have seen the problem before, tell your interviewer that.
So maybe you just practiced some palindrome problem on LeetCode
last night, and your interviewer says, given a string,
tell me if it's a palindrome.
Just tell them if you've seen it.
Or if you've seen something similar, just say, oh, yeah, this
was one of the problems I practiced last week, so I have seen this one before.
They might say, OK, great, thanks for telling me.
Let's solve a different one.
They might say, OK, that's fine.
Let's just solve it anyway.
Even if you've seen it before, I still want to see your approach.
It's up to the interviewer what they want to do there.
But the thing to not do is be dishonest.
I catch people all the time being dishonest.
One way to get caught is we sometimes at an on-site,
two interviewers talking to the same person
will ask the same question, because they forgot
to share what questions they asked.
And then the second time, the person would be like, oh,
I haven't seen this before, let me solve it.
It's just an instant rejection.
Unless you're an Academy Award winning actor,
you'll probably get caught trying to act.
So just be honest.
Don't try to do anything sneaky here.
Just let your interviewer know if you've seen the problem.
After you get the problem-- let's say you've
disclosed if you've seen it before.
After that, the first thing you probably want to do is ask clarifying questions.
Really good clarifying questions are of the form, OK, so let me just be clear.
So if this was the input, then this would be my output?
And they'll say, yes, it is.
You say, OK, great.
You're on the same page, you've understood the problem.
Then as you're solving it, always think out loud.
You should basically, as an interviewer, never
be silent for more than like 30 seconds or 60 seconds at a time.
It's going to feel really weird to constantly just be thinking out loud,
because that's not how most developers or day scientists or designers think.
They just think in their head and not speaking.
Your interviewer will expect you to do this.
It will feel weird if you've never done it before,
but it is what you're supposed to do.
Sometimes you might say, OK, do you mind if I just take a minute to think
or draw something out on a piece of paper?
The interviewer will say, sure.
But if you're sitting there in silence for five minutes
typing away at your keyboard and not making much sense,
your interview is not going well.
If you can, try talking through multiple possible approaches.
Usually when you're given a problem, you might have
a couple ideas for how to solve it.
And talk through all of them.
You can say, OK, I have a couple ideas here.
One idea is to build a graph that has these as nodes.
Another idea would be to create a hash table, where this is the key,
and this is the value.
Sort of explain it out loud.
Your interviewer is probably going to help you here and say, OK, yeah,
those both might work.
If I were you, I'd go at the second one.
You can say, OK, great, now I'm going to go with the second one.
You're sort of making it more of a conversation
and giving your interviewer an opportunity to help you.
Many folks are sort of visual folks, so feel free to draw a diagram.
Even if you're doing this over video, having
a little whiteboard or a piece of paper handy,
that can be helpful if you're a visual person.
So if you want to draw the diagram, hold it up to the webcam if you want,
or not, depending on what the situation is.
But have the supplies ready if you think you'll need them.
Then after you've got the problem, you've
articulated some solutions, what you really want to do
is try to pattern match.
We mentioned that most interview problems reduce down
into a really small number of core concepts
like search problems, strings, graph problems.
So try to pattern match against what you know to what
you think this problem is getting at.
So for instance, maybe someone's described something where
you're searching for something that could
be a bunch of different possibilities, ask yourself, OK,
could we formulate that as a search?
Or maybe somebody has described some problem, and you're like, OK, well,
maybe there's some recursion here that I can formulate,
or maybe binary search is applicable.
But take all those things we talked about earlier in your toolbox
like lists, strings, trees, hash tables, and just go through them in your head.
Does a hash table apply here?
Does a list apply here?
Does a tree apply here?
Hopefully, the answer to one of those is yes,
and that can really help kick start your solution and get you off the ground.
And then you sort of figure out, why is it a graph problem,
or how is this different than a standard graph search?
But it can help get you to a starting point for your solution.
Rather than trying to invent some new algorithm on the spot or derive
something totally new in the spot, pattern match against what you know.
And you know a lot, because you went through all of the toolbox and prep you
should be doing in advance.
As you're writing up your solution, try to write general code
before really specific code.
And what I mean by that is, let's say that your interview problem is, write
a function to compute a factorial.
What some people do as their first instinct is they say,
well, I know the factorial of 3 is 6.
So I'm going to say if input equals 3, return 6.
And then they come up with like three or four corner cases first.
I would say, don't do that.
That code is probably not going to last--
you're going to end up deleting it.
But it can also sometimes create this mental block
where you fail to see this general solution,
because you're zoomed in on a small number of cases you know work.
So try to think about this generalized solution, and then find corner cases,
rather than enumerate all the possible corner cases
and then try to find some general solution.
For the most part, too, if it feels like your solution is really complicated,
like it's got a bunch of corner cases and a bunch of branching and four
different helper functions, if it just feels pretty complicated,
it probably is, and there probably is a simpler solution.
Sometimes there's not, and it's kind of hard to tell,
but your interviewer is probably going to be there asking you to simplify it,
or maybe there's a better way.
But just as a heuristic for yourself, if you're looking at your code
and you're like, wow, that's a lot, it feels really messy--
it's not because like, oh, the problem is so hard--
it's probably because your solution is overly complicated.
To get out a question that we asked earlier, if you get stuck,
ask for help.
It's much better to say, honestly, I'm a little bit stuck here.
Can you give me a hint?
Or can you point me in the right direction?
Saying that is so much better than just staring at a wall for 30 minutes
and getting nowhere on the problem.
It's obviously better if you solve the problem without asking for hints.
Someone who's constantly asking for hints and needs a lot of hand-holding
to get to the answer--
that's not a good interview either.
But sometimes you do hit a wall.
You can ask a question, and with a small little hint, you can get unstuck,
and then you're back off to the races.
And also make sure before you type a single line of code,
explain your solution.
Be aligned on what you're about to write before you write it.
You don't want to create some situation where you've written a bunch of code
in the back of your head, your interviewer
is like, they didn't even tell me what they were trying to do.
I don't even know what they're trying to do, and this is super wrong,
and you don't have enough time to fix it.
And then you interview's over.
You lose.
So make sure you're aligned on the same page of what code you're about to write
and what your general approach is before you go and write it.
And again, this is what I mean when I say process, not output.
If you're aligned in an approach, and you're thinking critically,
and you're communicating well, maybe your output isn't perfect,
but that's what we're really looking for for a good interview.
OK, some few last tips before we get into the mock interviews here.
So as you're writing code, constantly communicate.
Sometimes I'll even kind of narrate the code I'm writing.
I'll say, well, first, I'm going to create a function called Cache.
And then that's going to take two parameters.
It's going to take the key, and then it can take the size of the cache.
And the first thing I want to do is I'm going to create a base case here.
That kind of communication is really helpful as you're typing.
Again, it feels weird, it's unnatural.
Practice it.
I promise that's what your interviewer wants you to be doing.
Next thing is always get something working.
Sometimes people will see some simple or naive solution,
they know it's not optimal, and rather than writing up the naive solution,
they sit there and they're like, no, I don't
want to write anything until I get the perfect, optimal solution.
Then they end the interview having written zero lines of code--
really good chance that the interview didn't go well.
You're not going to move forward.
It's definitely better to have something than to have nothing.
Once you have something, then go ahead and try to simplify,
make optimizations, and get to that optimal solution.
But even if you can't ultimately get to the optimal solution,
but you're thinking really quickly, you're
communicating well, maybe with five more minutes you would have gotten there,
that's a really good interview outcome.
Last, listen to your interviewer.
I've had many candidates who do not listen to me
as I'm trying to help and give hints.
Your interviewer wants you to succeed.
As an interviewer, it's so much less fun watching somebody struggle,
and you're trying to help, and they're telling you, no, you don't understand
the problem you just gave me.
It's like, I probably do, and I want you to succeed.
So if your interviewer is giving you little hints
and guiding you in the right direction, really listen to what they're saying
and take it seriously.
It's really, really rare that some interviewer
is going to intentionally try to fool you or give you some hint
to lead you down the wrong direction and be like, oh,
is that your final answer, when it's actually correct.
It's pretty rare.
I assume the interviewer is not doing that, unless you know they've already
done it once or something.
So really listen to your interviewer.
They want to help you.
Take advantage of that and listen to their feedback.
Oftentimes people ask, what code do I write?
What we're looking for specifically is a function that returns the answer.
So don't just write a linear--
the first line of code shouldn't be like, if this,
and assume some variable exists.
The first line you write should be creating a function
that will ultimately return the answer.
If that function needs to be more than one function, great.
Decompose that into separate functions as needed.
Don't go crazy here.
And make sure you have something working before you spend a bunch of time
refactoring code and cleaning it up.
A lot of good general engineering and programming principles apply here too.
Don't create variable names with crazy acronyms or abbreviations.
Make sure everything is readable.
If you have common logic, factor things out into helper functions.
Again, this is all about the process.
If you're doing this and demonstrating these things,
that's way more important than your function being perfect at the end.
Last part is testing it.
Once you have written code, your job now is to be a computer.
So take your code and run through it line-by-line.
Execute the code as if you were a CPU.
Make sure that if you run the code, it's going
to end up returning the correct answer.
And again, do that out loud.
So what I would say is, let's say you have that factorial function saying,
OK, well, let's try passing in 3.
Well, it's 3.
My base case is checking if it's equal to 1.
3 is not equal to 1.
So let's move on to the next line.
We're going to enter this recursive case.
And just walk it through and make sure that you get the correct answer
at the end of it.
As you're doing this, be on the lookout for bugs.
Sometimes in your head, what the code is doing
is different than what's actually written.
So as best you can, do exactly what the code is actually doing,
and that's going to help you find bugs.
And just verbally reason about that out loud and walk through,
sort of narrate the process of this function executing to your interviewer.
Sometimes in an interview, you'll be given a computer and the ability
to run code.
Sometimes you won't, either because it's on a whiteboard,
or because the interviewer says you're not allowed to run code.
I want to see your reason about it.
In the mock interviews we're about to do,
we will be allowed to run code on the computer.
So if you can do that, I advise to write a few test cases, if you can.
Maybe they're just like print statements at the end or something that's
going to run the code and verify the output is correct.
But what I wouldn't do when you're given the ability to run the code
is take advantage of that just by running it a million times.
And let's say you have an off by 1 error somewhere,
just randomly adding plus 1's and minus 1's and then
running it until eventually you get the correct answer.
Even if the answer is correct, that's a great example
of a process that is not good.
We want to see reasoning about things and arriving at a solution
confidently, rather than just randomly locking your way into a solution.
And the ability to run code a bunch can be this temptation that
can lead to that kind of outcome.
And last, if you can, add print statements
or debug the state as your code is executing.
Definitely do that.
I think sometimes people will run the code, look at the output,
say that's wrong, change something, look at just the output,
and say that's wrong.
We're printing out intermediate state, and what your code
is doing along the way.
Maybe you have a recursive function.
You're going to print every time the recursion is called, print the inputs.
You can make sure the stack is what you think it's going to look like.
And that's usually the most effective way to fix issues.
I think I'll say it one last time--
the process matters way more than the output here.
OK, so let's jump into some mock interviews.
So what we'll do is we'll have Connor, and Maria will be the interviewee.
I will be the interviewer.
And we'll try to simulate this really as realistically as we can.
So like I said, these are real problems I've really given
in the past at real tech companies.
And then Connor or Maria have done lots of real interviews,
and so they'll give you what a real performance looks like, just so you
can take a look at how things go.
So I'll read the problem first, and then we'll flip into screen sharing
and start the interview.
So this is the first problem that we're going to be working on.
So I'll read it out.
So let's define a rotated 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.
So for instance, if you've got the array, 1, 2, 3, 4, 5,
and you rotate that three times, you're going to get 3, 4, 5, 1, 2.
So the problem here is given, a rotated array,
find the number of times it was rotated.
CONNOR LEGGETT: All right.
Well, hi, Tommy.
How are you doing?
I'm Connor.
TOMMY MACWILLIAMS: Good, nice to meet you Connor.
How's your day going?
CONNOR LEGGETT: It's going pretty well, and yours?
TOMMY MACWILLIAMS: Awesome, not too bad.
It's pretty sunny out here in San Francisco,
which doesn't happen too often.
CONNOR LEGGETT: That's great.
Yeah, it's pretty warm out here for October in Cambridge.
DAVID MALAN: Nice.
All right, well, thanks for taking the time.
Let's jump right into the question.
So you've got the Replit open, that's great.
I notice that you've selected Python there.
Is that the language that you want to use for this?
CONNOR LEGGETT: Yes, it is.
TOMMY MACWILLIAMS: Perfect, that works for me.
So here's the question that I'd like you to solve.
So let's define a rotated 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.
So for instance, if I give you the input 1, 2, 3, 4,
5, you should return back 3, since--
oh, sorry, when I rotate that three times,
you should return back 3, basically, as you've written in the comment there.
So that's the question that I'd like you to solve.
CONNOR LEGGETT: OK, yeah, that sounds good.
So I'll start out by asking some clarifying questions,
if that sounds good to you.
TOMMY MACWILLIAMS: Yeah.
CONNOR LEGGETT: So just to make sure, it does say, given a rotated array here.
I just want to clarify that something like this right
here would be our input.
So I don't get this original array at all,
I just get the rotated array as input?
TOMMY MACWILLIAMS: Yep, that's right.
CONNOR LEGGETT: All right, and then my other clarifying question
is, in this one, all of these are consecutive integers, so 1, 2, 3, 4, 5,
all right next to each other.
Can I assume that that will be the case, or might there
be a case where my original array is like 1, 3, 4, 7, 10?
TOMMY MACWILLIAMS: Yeah, so that could exist.
So they're not necessarily consecutive, but they are sorted.
CONNOR LEGGETT: OK.
Yeah, that's good to know.
All right.
In that case, let me just look at a couple of examples
just so I can see if we can start to see a pattern here.
TOMMY MACWILLIAMS: Sure.
CONNOR LEGGETT: So we see when we get this first example,
we want that to map to 3, because we're rotating that one 3 times.
Let me see if I were to rotate that one more time,
then it would look like 2, 3, 4, 5, 1.
And so that would be as if I had rotated it 4 times.
And then I'll try some ones with different numbers.
So if my original array has some different numbers in it,
a rotated one might look like 6, 8, 12, 1, 3.
In this case, we would have rotated it so one
would have been the original one.
And so we've rotated it 1, 2, 3 times.
So we would also want this one to return 3.
And then just one more kind of edge-ish case is if it's not sorted at all.
I'm assuming that we would want to say that that was rotated 0 times.
TOMMY MACWILLIAMS: Yes, that's right.
CONNOR LEGGETT: All right.
So just to check in, do all of those cases seem good to you?
TOMMY MACWILLIAMS: Yeah, nothing else you'll probably run into here.
CONNOR LEGGETT: All right, great.
So in that case, let me go ahead and run through, looking for patterns.
So I can see just how I would figure this out
if I was looking through this as a human, is I would go to the first one,
and I guess the important thing I'm looking for is all of these numbers
are increasing.
And I want to look for the first time that they decrease,
so they start going down.
So in this case, I go to 0, I go to 1, it's increasing.
I go to 2, it's increasing.
And then when I get to element 3, it's decreasing,
which means it's rotated 3 times.
OK, and then just to verify that, I'll go through this one.
So in this one, I started element 0, then 1, it's still increasing,
2, still increasing, 3, still increasing.
But at 4 it decreases again.
So I think that is a pretty good pattern to use there,
is that when we get to an index when it starts decreasing,
that's the index that we want to return.
TOMMY MACWILLIAMS: Yeah, that looks exactly right to me.
Yeah, that point where it goes from increasing to decreasing is the index.
That tells you the number of times it had been rotated.
CONNOR LEGGETT: All right, perfect.
In that case, I think I'll go into writing some code,
if that sounds good to you.
TOMMY MACWILLIAMS: Yeah, let's see that.
CONNOR LEGGETT: All right.
So I'll go ahead and define a function here.
And so I guess I'll just say, get rotate number.
TOMMY MACWILLIAMS: Sure, sounds good.
CONNOR LEGGETT: And it's going to take in this array.
Ah, that looks like it might be reserved, so I'll take in a list, ls.
Now I want to go through all of the elements in ls.
And the index is important here, so I guess I'll
go ahead and say for i in range ls.
And now what I want to do is for each i-- like when I'm here, i is 2--
I want to compare it to the one before that and see if it's less than that.
So let me--
I guess I would say something like, if ls bracket
i is less than ls bracket i minus 1--
so we're saying, if my current element is less than the element before that--
then I would go ahead, and I know that that's the place that I want to stop,
so I can go ahead and say return i.
And now, looking at this special case here where nothing happens,
I guess I would go through this entire list and never get to that point.
So I guess if I finish this whole thing, so I don't find any point where
an element is less than its predecessor, I'm going to go ahead and return 0,
since I know that the list is not rotated at all.
So now, just as a sanity check, I'm going
to go through this with this first example here.
So acting as the computer, I take in ls, which is this list I've highlighted.
And then I go ahead and say, for i in range ls,
so that's going to start me off at 0.
And I'm going to say if ls bracket 0, which is 3,
is less than ls bracket 0 minus 1, is going to be ls bracket
negative 1, which is this 2 here, which I guess will not be a problem here.
Because the only case when this first element is
going to be less than the last element is when the array is not
rotated at all.
So I would want to return 0 in that case.
So that actually makes me think that I may not need this return 0 at the end
here.
Just kind of a peculiarity of Python indexing,
where if I say ls bracket negative 1, it's
going to be the last element of the list, instead of giving me an error,
like it might in C or Java or some other programming language.
TOMMY MACWILLIAMS: Yeah, thanks.
I hadn't thought of that, but I think you're right.
CONNOR LEGGETT: All right.
And then finishing, go through that example, for this one,
it would start out at 0 and see that 3 is, in fact, greater than 2,
so it'll continue.
It'll get to this one.
It'll say that 4 is greater than 3, so it will continue.
It'll get to 5, say 5 is greater than 4, so it'll continue.
But then when i is 3, we'll see that ls bracket i is, in fact,
less than ls bracket i minus 1.
So we'll go ahead and return i, which is 3, which is as expected.
So just running through it as a human, that seems to work.
So now let's move on to writing some tests.
Yeah so I can go ahead and say--
I'll just print one out first to verify.
So I'll go ahead and say, print, get rotate numbers of our first list here.
And hopefully, this will end up with 3, so I can go ahead and run my code here.
And we've got a problem here, where I'm saying list object cannot be
interpreted as an integer.
OK, and I think what's going on here is I can't just say for i in range lists,
because range has to take in an integer.
So I actually have to look at the length of the list--
TOMMY MACWILLIAMS: Yeah, that's right.
CONNOR LEGGETT: --instead.
So now I'll go ahead and try that again.
All right, nice, and so that's looking pretty good.
So that's looking like it's printing 3.
And then I'll just go ahead and try with our other lists here.
So hopefully, this second one should translate to 4.
This third one should translate to 3.
And this last one should translate to 0.
And we'll go ahead and run that.
And it looks like I added--
oh, I forgot a--
TOMMY MACWILLIAMS: Yeah it's the appropriate.
CONNOR LEGGETT: --bracket here, I'll run that.
TOMMY MACWILLIAMS: Looks right.
CONNOR LEGGETT: And it looks like that has given us the result we want.
So that's looking pretty good to me.
So I guess I'll check in at this point and see if there's anything
that you notice about this or any other corner cases
you think I should try out.
TOMMY MACWILLIAMS: Yeah, this looks right to me.
What is the runtime of this?
CONNOR LEGGETT: Yeah, of course.
So going through the runtime, since I'm going through i in range length of ls,
I'm going to go through this loop a maximum of n times if there's
n elements in ls.
And then just accessing elements of a list in Python is 0 of 1,
and comparing to integers in Python is going to be 0 of 1,
in terms of the size of the list.
And so this whole operation inside the for loop is going to be constant time.
So I going to say that the entire runtime is going to be 0 of n.
So if there are n elements in the list, it'll take a maximum of n times.
TOMMY MACWILLIAMS: Yeah, I think that's right.
Can you think of any ways to make it faster?
CONNOR LEGGETT: Yeah, let's see.
So if I'm working on making it faster, I wonder--
so I guess any way that we could make it faster would be to-- hmm.
I'm actually a little bit unsure, because going through it as a human,
I can't think of anything else I would do than go through each element.
So I'd love to know if you have any hints, if you could nudge me
in the right direction a little bit.
TOMMY MACWILLIAMS: Yeah, so keep in mind that the list is sorted.
Even though it's rotated, we have this property that it's sorted.
So is there any search we could use that leverages the fact that it's sorted?
CONNOR LEGGETT: We could use--
so generally, with the sorted list, we could use just a binary search.
So if we're going through and doing that,
then how would I apply a binary search to this problem?
So I guess I could--
let's see.
So if I go through the motions of doing a binary search
with a problem like this, I would start in the middle
and see that I've got a size 5 here.
OK, so I guess I would have to look at the first element first,
see that my first element is a 3.
And then when I head to the middle, I see
that I'm at size 5, which means that it's been increasing since then, which
means, I guess at that point, I can go ahead and narrow my search down
to the latter half of the list after I've checked that one.
And vice versa, if I, let's say, for-- what's a good example?
For this one, if I start at--
I guess I don't have a great example for that one.
But if I were to get to a point where I was checking this 3 here,
then I would know if I'm checking at this 3,
I know I can just look at everything before the 3.
So yeah, I think a binary search would be able to help us out there.
Just want to check in time-wise.
Is it all right if I go ahead and try and implement that,
or do you think we should move on?
TOMMY MACWILLIAMS: Yeah, let's try to implement it quickly,
and then if we run out of time, that's totally fine
CONNOR LEGGETT: Yeah, sure.
So let me leave this other one here, just to have something to reference.
And now this newer version here, I don't necessarily want to go through each i
in this range.
I want to go ahead and say my--
I only care about when I'm going from a high number to a lower number.
So I'll go ahead and say that my highest number that I've seen so far
is going to be the first element in the list, is ls bracket 0.
And then I can go ahead and say that my lowest element that I've seen so far
is--
we can go ahead and look at the last element of the list,
because I know it's going to be somewhere in between.
Or I guess we don't necessarily know that's the lowest.
Let me think about how we would want to initialize those.
So 5, if that is the lowest, then--
yeah, I guess I'll just start out with 0 and go through the logic of this.
And then-- although I think I'm going to actually want--
so if I'm looking for an item that is lower here,
I'm also going to want to keep track of the indices that I'm working with.
Does that seem like it's going to be on the right track?
TOMMY MACWILLIAMS: Yeah, I think in general,
you'll probably want to look at the--
keep track of the left and right endpoints of the search.
And then you can compare wherever you land on in the middle
to those left and right endpoints.
CONNOR LEGGETT: Yeah, yeah, that's a good point.
So let me go ahead and say that left for now is going to be 0, the first index.
And then since we're starting our search with the full list,
our right is going to be the length of the list minus 1.
And then what I can go ahead and say, I can go ahead
and instead of having this whole for loop here,
I can say, while right is greater than left,
so while we're still working on converging n.
Then I'll go ahead and say that my current index is going
to be equal to right plus left, 5 by 2.
Let me get some parentheses in there.
And so that will take the middle element.
And then since we're working in Python, I
realize I should probably do some integer division here.
TOMMY MACWILLIAMS: Yep.
CONNOR LEGGETT: So that'll get us our current index that we're working with.
And then I can go ahead and say--
and let me look at this example to see what we should do.
So in this example, if our current index is greater than the index on the left,
then I know I can narrow my search to the right half.
So if ls bracket current, so if that current number is greater
than ls bracket left, it's greater than the left number, then I can go ahead,
and I can narrow down the search to this right half of the list.
So I can go ahead and say that left equals current.
And then I can go ahead and say, otherwise
if ls bracket current is less than ls bracket left,
then I can go ahead and say, right equals current.
So I know that we are going ahead and changing our rightmost there.
And so now we just have to work on what happens
after we do narrow in on that case.
So let's go through the example with this top one again.
So we get to this point with this 5 here,
and so now we know that our difference is going to be between 5 and 2.
And actually, now that I'm thinking of--
yes, we're looking between 5 and 2 here.
So our left at this point is going to be 2, and our right is going to be 4.
And so now our central one is going to be 1 here.
And so now, since 1 is less than 5, we would hit this case,
and so we would say right equals current.
So now our left is going to be 5, and our right is going to be 1.
So we know that we're ending here when our right one is just 1
more than our left one.
And so let me go through what the example would do in this if left is 2,
as we have here, and right is 3.
So when one left is 2 and right is 3, our current is going to be 3.
And so this is going to say, if current is greater than the left one, which
isn't true, because they're the same thing, and then we'll say,
if current is less than the left one, which
isn't going to be true, because they're the same,
then we can have an else statement here.
And if it's an else, then we know that this current one
is kind of 1 below where we want to do.
So can we try and return our right here.
So now, just running through with another example
as kind of a sanity check, so we'll take this one here.
Let's say, so our left is 0 to start, right is 4.
We can find the one in the middle, which is going to be element 2.
And then we're going to see 2 is greater than our left.
So that means that we're going to narrow our search down to these last three
elements here.
And now we're going to go ahead and say that--
yeah, so now we're going to go ahead and find the middle element here,
which is 1.
And we'll say that left--
yeah, so this is our current, and then we're checking
is current greater than left.
No, that's not true.
Is current less than left?
Yes, that is true, so we're changing our current to this,
or we're changing our right to this.
And so now we're just looking at this section here.
These are our left and right.
And when we compare left to current and right to current,
they're both going to be the same thing, so we get this else here.
And we return what's on the right, which is 1, which should be correct.
So just basic conceptually wise, it looks like things are working out here.
Oh, let me run through it real quick with the unrotated around
to see how things are going there.
So in this case, we're going to get to this middle one.
We're going to see that the current is greater than the left.
So we'll get to this one here now, and we'll
see that the right is still greater than the left.
So now our current is still greater than the left,
so our left is becoming this one.
And now we're going to go ahead and say--
the left is still going to be this one.
So that's not going to give us the right answer here, it looks like.
TOMMY MACWILLIAMS: Yeah, I think the stop condition you're
looking for is in that first example.
You can see with the one, the number to the left is bigger,
and the number to the right is bigger.
So that's kind of the stop condition for your search.
Otherwise, though, I think the binary search is right.
CONNOR LEGGETT: OK.
Yeah, so that makes sense.
So maybe I can go ahead and check that condition.
So if we're looking at our current one, do you think for each time,
we would look at our current and check if it's smaller than the left one,
and smaller than the right one?
TOMMY MACWILLIAMS: Yeah, that's seems right.
CONNOR LEGGETT: OK, sure.
So we're already checking if our current is smaller than the left one here.
And so I can go ahead and nest a little bit of ifs
here and say, if our current is also smaller than the one--
oh, sorry.
But we're not looking at direct neighbors there.
So let's look at direct neighbors up here.
So that would look like if ls bracket current minus 1
is less than ls bracket current, which is
less than ls bracket current plus 1-- which
is a nice thing we can do in Python is just combine
these different inequalities.
And I'll take away those parentheses for now.
And so in this case, we know that current
is the one that we want to return.
So we can go ahead and return current here.
And then let me just do another sanity check with these--
TOMMY MACWILLIAMS: Yeah, I think this looks basically right.
Just for time, we're basically at time, but yeah, overall, this search
looks pretty good.
CONNOR LEGGETT: All right.
TOMMY MACWILLIAMS: Awesome.
Well, thanks for taking the time for chatting with me today,
and have a great rest of your day.
CONNOR LEGGETT: Yeah, thanks, it was great to meet you.
TOMMY MACWILLIAMS: Awesome, see you later.
CONNOR LEGGETT: Bye.
And then for feedback, is it best to keep my screen shared?
TOMMY MACWILLIAMS: Let's actually just switch to Maria, just for time's sake.
So Maria can flip into screen sharing, and we can go into the next question.
All right, so I'll describe the problem, and then you
can take it away from there.
So what we're going to do is, given a string,
we're going to be looking for the length of the longest substring
without repeating characters.
So, for instance, if I gave you the string abcabcbb, the length
of the longest substring there is 3.
So there's abc where it doesn't have any repeating characters in there,
and there are a few other ones like that.
So your function would take that as input,
and then just return the length of that string, which is 3.
MARIA ZLATKOVA: Awesome.
Hey, Tommy, how are you?
TOMMY MACWILLIAMS: Awesome.
How's it going?
MARIA ZLATKOVA: Good.
How's your day going?
TOMMY MACWILLIAMS: I'm good.
It's a sunny day still in San Francisco, so I'm loving it.
MARIA ZLATKOVA: Beautiful.
It's kind of a gloomy day in New York, but still pretty warm,
which is about all we get.
TOMMY MACWILLIAMS: Nice.
Well, thanks so much for jumping on the call.
Let's jump into a coding problem.
MARIA ZLATKOVA: Awesome.
TOMMY MACWILLIAMS: All right, so it looks
like you've got the Replit set up.
I notice you're set to Python.
Is that the language you'd like to use?
MARIA ZLATKOVA: Yeah, that's the language I'd like to use,
if that sounds good with you.
TOMMY MACWILLIAMS: Perfect, that's good with me.
MARIA ZLATKOVA: Cool.
Just thinking through this question a little bit,
I guess a few clarifying questions.
TOMMY MACWILLIAMS: Yeah.
MARIA ZLATKOVA: So we just want to find the length, right?
We don't care about returning one or all of the sequences
that match that length?
TOMMY MACWILLIAMS: Yep, that's right.
MARIA ZLATKOVA: Awesome, cool.
And then when it comes to the input, I see
the example we have here are all lowercase characters.
Should we assume that we're going to get all lowercase characters as input,
or do we want to handle kind of like sanitizing that input?
TOMMY MACWILLIAMS: Yeah, that's a good question.
You can assume the input's all lowercase
MARIA ZLATKOVA: Awesome, cool.
And I guess, could the input be empty, like the empty script string?
TOMMY MACWILLIAMS: It could, in which case you return 0.
MARIA ZLATKOVA: Awesome, cool.
Great, I think that covered all of my questions.
So maybe then just give a few examples, so abc, abcdb,
the answer would be 3, the output that we want to give.
If we have all repeating characters the output would be just 1, I'm assuming?
TOMMY MACWILLIAMS: Yep, that's right.
MARIA ZLATKOVA: Awesome.
And conversely, if we have all different characters,
the output would be 6 in this case?
TOMMY MACWILLIAMS: Yep.
MARIA ZLATKOVA: And then, as we said, if we get the string,
the output would be 0.
Yeah, awesome, I think that makes a lot of sense.
When I'm looking at this initial string and problem,
I guess the first instinct that I have for the very naive solution
is that brute force.
We can just get all of the possible subsequences or substrings
and check whether there are any duplicate characters
within those substrings.
So in the abc, abcbb example, that would be first starting
with every substring starting with a would be a.
And checking if that has any repeating characters, then ab,
it doesn't have any duplicate characters.
Then abc, it also doesn't have any duplicate characters, then abca,
which has duplicate characters.
And then every single one-- abcab would also
have duplicate characters, given that the substring of that had them,
and also that b is repeating similar, with abcabc abcabcb and abcabcdb.
So it would be a very similar case if we started b and at c.
So it's kind of making me feel like the naive
solution would be doing a little bit of work that is not useful.
So if we could avoid that, that would be great.
Reasoning a little bit over that nice, ancient, brute force approach,
going through all possible subsequences would be quadratic time,
and then within that, checking whether there are duplicate characters
within each substring would be linear time.
So in total, that probably would be n to the third.
So that is not great.
So I'm going to try to optimize that, if we can.
And looking at this the way I like described
it, starting at different points of the string,
I'm starting to think maybe we can have a range within the string
that we track with a starting index and an ending index.
And maybe we can expand the start of string
and expand our ending index to the right.
And the moment we kind of encounter a duplicate character or repeating
character, we start to move our start index forward
to try to get to a subsequence that doesn't contain
that duplicate character anymore, and all the while, while we're doing that,
keep track of the longest encountered length.
And I guess I have another kind of assumption question is,
could we use an extra data structure in this question?
TOMMY MACWILLIAMS: Yeah, that's really fine.
I think that sort of sliding window you're describing,
that sounds like a pretty good approach to me.
MARIA ZLATKOVA: Awesome.
Yeah, I think for that sliding window I'd like to use HashSet,
so that we can have pretty constant time in looking up
how often certain characters are within the string already,
and we can do that look-up very quickly.
TOMMY MACWILLIAMS: Yeah, that sounds great.
MARIA ZLATKOVA: Awesome.
So if that sounds good, I'm going to go ahead and define our function.
I'm going to call it length of longest substring.
We take in just one parameter, I'm assuming, which is the string.
TOMMY MACWILLIAMS: Yep.
MARIA ZLATKOVA: Then we need to define the output, which is an integer.
So as I said, would love to use a HashSet.
So I'm just going to start by initializing it
and just initialize it all to zeros for now.
And we're going to count how many occurrences of each character
that we encounter happening within the sub string.
And I'm going to multiply that by 128, because I
know that we have 128 ASCII characters.
So just to start off, initialize it with that.
And then going to define the length, which
we're going to want to talk about longest substrings and define it 0.
I'm getting some-- oh, OK, variable assigned, but never used.
That's OK, because we haven't used it yet.
And then I'm going to use the start and end index approach that I
described with that sliding window.
So the start, maybe I'll just call it left for clarity.
I'm going to assign that 0.
And then what we want to do first is start going through the string.
You can do it in a few ways, while loop, but maybe I'll do a for loop to start.
So you can say for right, and right is referring
to my n index, which I described for right in range
of the length of the string.
Thankfully, I saw Connor's previous interview,
so I now know that we can work here.
But we have to do the length of the string.
And then the first thing I want to do in this case is to make sure that--
basically, what we want to do is increment
the count of the specific character that we're at by 1, so in the HashSet
that we have.
So the way we're going to do that is we're going to say,
chars at s at the next right, because S's are the string.
And we're going to increment that by 1.
And that's OK, because we've defined all the characters, all of them,
essentially, fields in our HashSet to be 0.
Cool.
So then the next thing I want to do is I want
to take care of that case, which I mentioned earlier, which
is, if we encounter a duplicate character moving the left or the char
index forward until we don't [INAUDIBLE] the character anymore.
And since we're using chars as our HashSet,
the way that we know that we've encountered more than one character
is if chars at index right is greater than 1.
And so I'm going to do a while loop here,
because we could have multiple repeating characters within the substring.
So I want to make sure that I get rid of all potential repeating characters.
Or the repeating character could actually
be at a later point in the substring, so I want to get to that point
and make sure I move the char index by enough characters forward.
So the way we're going to do this is first,
we want to update the count that we're keeping
track of in our HashSet for that specific character.
So the way we're going to do that is we're
going to stay chars at s at left--
I think we called it left--
[INAUDIBLE] minus equals 1.
And then what I'm going to do to move left forward
is I'm just going to increment left.
Cool, and then one thing which I haven't done yet
is I want to make sure I'm keeping track of the length, as we said earlier.
So the length at the first iteration will be--
we've initialized it to 0, and then we calculated
the length between two indexes in a string
typically would be the ending index that is the starting index plus 1,
because it [INAUDIBLE] 0 index.
So in our case, it's right minus left plus 1.
If I could spell correctly that would be great.
And then what I'm going to do, so that we always
keep track of the biggest the maximum possible link,
is I'm going to use the max function and say, I
want to take the max of the length that we're keeping track of,
or the current link based on the right and left integers.
And then I think the last thing we want to do
is return the link, because we want to retain that integer.
Cool, and I guess just a sanity check a little bit before I run this,
I'm just going to do it with abca, because it's a little bit shorter
than abcabcdb.
So abca should be 3, the output for that.
So what we're going to do is, when we start our for loop,
we're going to say that chars at a is equal to 1.
We're going to add 1 to that.
It's not greater than 1 in the first iteration.
So what we're going to do is just take the length and set it.
And because right and left are 0 at that first run through the for loop,
it's going to be 0 minus 0 plus 1, so length is going to be 1 at this stage.
And then when we get to b, chars at b is going to be granted to 1.
Chars b still is not greater than 1, so again,
we're just going to jump to length, and at this point
it's going to be 2, because 1 minus 0 plus 1 is 2.
Then we're at index 2, which is the third character, which is c.
So again, setting chars at c can be 1, and then it's not greater than 1,
so we just jump and then increment the length again, to 3 this time,
because 2 minus 0 plus 1 is 3.
Then in the final run-through of that for loop,
we're going to encounter a again.
And so chars at a is now equal to 2, which is greater than 1.
So what we're going to do is decrement that, so again, chars a becomes 1.
And we're going to move our left index forward, and what we get now
is that we want to take the max of either 3 or 0, 1, 2, 3, or 1, 2,
3, which, again, is going to give us a length 3.
And we've run through basically all of the elements here,
so what we're going to do is just return line 3.
So just by running through the simple example, I think this should work.
And I'm going to write out some test pieces.
So maybe I'll just print, input, and maybe just define our string
here first to be abcabcbb.
Our input is going to be string, and then we
want to say length is equal to calling the function on string,
and finally print.
Output to be length.
Cool, so it may have some errors.
I'm just going to run it through the first time and see what happens.
And I see here that on line 14, we have, list indices
must be integers or slices, not strings.
So looking at line 14--
oh, I think this is very interesting, because I referred to ASCII characters
in the beginning, but then I didn't really
take into account that we can't have a character itself as the index,
but I think we have to use a function called ord.
TOMMY MACWILLIAMS: Yeah, that's right.
MARIA ZLATKOVA: Awesome.
Yeah, I think that function returns an integer that
represents Unicode character.
So what I want to do is I want to wrap ord around every single time I'm
using an index within chars.
Those should be all the times.
And then input abcabcbb, output 3, that's great.
I'm just going to run through and add a few more test cases like the ones we
mentioned, so bbb , abcdef--
no-- and maybe just an empty string for good measure.
We'll see if that gets us the right result. Cool.
So we get input bbb output 1, which is great, and put abcdef output 6,
which is great.
pwekf-- I think this is right.
TOMMY MACWILLIAMS: Yep, that looks right.
MARIA ZLATKOVA: OK, and then input empty string, output 0.
Awesome.
I think this looks good to me.
Are there any other edge cases that you want us to take a look at?
MARIA ZLATKOVA: No, this looks great to me.
And I think you might have mentioned already,
but what's the runtime of this final solution?
MARIA ZLATKOVA: Yes, so space complexity is linear if you're using HashSet.
And then time complexity--
so we have one for loop, which is linear time,
and then searching within the HashSet itself should be constant time.
So I think it comes down to linear time.
At most, you have to go through each of the characters twice.
TOMMY MACWILLIAMS: Yeah, that sounds right to me.
Well, awesome.
This looks great.
Well, thanks so much for taking the time to chat with me today.
MARIA ZLATKOVA: Of course.
Thanks so much too.
It was a fun problem to work through.
TOMMY MACWILLIAMS: Awesome.
Have a good one.
All right, so those were the two mock interviews.
I'll just say a few closing words for after the interview.
And then I know we're going a little bit over time,
but I'll be around if anyone wants to ask questions.
And then maybe before that we can quickly
go through just some things that went well
in the mock interviews and some things that didn't, so people
could give their own feedback and thoughts.
But before that, I'll just have a few closing thoughts.
So one is, we didn't simulate this in the mock interview,
but after the interview is over is kind of your chance to ask questions.
So now you would ask questions of your interviewer,
and here are some good questions that I like to ask--
asking about their team's culture or what their typical day-to-day looks
like, things that they've worked on, things that they're proud of.
And this is a really good way just to get
a sense of what it's really like to work at that company
you're interviewing with.
I think bad questions are things that you could easily Google or find online,
and good questions are questions that are not easily answered
online and actually give you a picture of,
would you like to join this company, and what is it like to work there?
So last advice I'll say is, don't worry.
Interviews are really, really, really high variance.
There are great engineers who just do super poorly on some interviews,
and that's just unfortunately how it works.
So just because you didn't do well on some number of interviews
doesn't mean at all that you're not still
a great developer or data scientist or designer or whatever path it might be.
Everyone has bad interviews sometimes.
Interviews are not fun.
I don't think I know anyone who enjoys interviews, really
on either side of it.
But just view every interview you do as an opportunity to get better.
If you don't pass an interview or get rejected from a company,
just try to reflect on that and think about what
went well, what didn't go well.
Maybe it was the type of problem, maybe it was your communication.
Just take some time to learn and grow from each experience,
but everyone is going to go through a bad interview.
I've gone through plenty.
I'm sure everyone else on this call has, as well.
And so don't worry if that happens to you.
So last up, just some takeaways from the talk--
one, have the basics down.
Going into any interview, just know the basics
of the language you're going to be using.
Be really comfortable in that setting.
Build your toolbox.
Be aware of the concepts we talked about in those two mock interviews.
We looked at a string problem, we looked at a binary search problem.
So those sort of concepts, have them ready to go.
Do lots of practice problems.
The more you practice, the more things you're
going to be able to pattern match against, and the more comfortable
you're going to be in this really unnatural interview setting.
Before you write any code, just like Maria and Connor did,
communicate your solution, explain the code
you're going to write, and then write it out.
And then just like we saw in those mock interviews, always
verbally run through your code.
Look for issues and solve them proactively,
so the interviewer doesn't have to tell you all of your bugs.
And I'll say one last time, all of this is about the process, not about
the output.
Really focus on communicating well, thinking critically, and getting
to a solution, rather than writing absolutely perfect code
at the end of the day.
And so that's the end of the workshop.
Like I said, we'd love to dive into questions
you have for me, as well as some feedback on the mock interview.
And so I'll turn it over to David to moderate questions and feedback.
DAVID MALAN: Yeah, Tommy, the first question that came up was,
does Tommy have any feedback on Connor's and Maria's
interviews, positive and negative?
TOMMY MACWILLIAMS: Yeah, for sure.
So I'd say both of those interviews were positive.
I think, like I said, the most important part was that communication.
And in both cases, Connor and Maria started
by asking the sort of asking clarifying questions in advance.
They made sure they understood the problem.
In both cases, they made a list of inputs and outputs, which I mentioned
is a really good way of framing things.
Also thinking out loud was really, really important there.
I think in both cases, everybody was constantly narrating.
They're never sitting in silence.
I think something else that I like that Connor did specifically
was ask for a hint when he got stuck.
I think it would have been really bad if-- imagine Connor was
at some mental wall and just didn't see it and was sort of like stuck
and, like, I don't know.
Let me just sit there and think about it.
Just asking for a hint, and then we were able to get unstuck and and go right
down the right path.
So yeah, so I think those are the things I would focus on for the interview.
I think in all cases, just making sure--
so we didn't really have enough time, because it was intentionally short,
but just making sure the code is really readable and clean and taking the time
to maybe create helper functions or more readable
variable names-- we sort of omitted that on purpose, just so the interviews
would be short, but that would be the main thing
that I would do with more time.
DAVID MALAN: Another question that came up,
especially for folks who don't have the luxury of being
able to do mock interviews with people like this,
are there recommended websites that are good at preparing you for interview
questions for algorithms coding?
Is competitive programming helpful?
TOMMY MACWILLIAMS: Yeah.
I think there are lots of great websites.
So one that I like a lot is called LeetCode, so just leetcode.com.
They've got a bunch of problems there.
You'll probably find the ones that I posted somewhere on LeetCode, as well,
because they have so many.
They're also great-- you can write up your solution
and also see the solutions.
Another good one I like a lot is called Project Euler.
Same thing, just gives you practice problems.
You can go and implement them in any language you want.
So I'd start there.
If you have a competitive programming background, that's awesome.
I'm pretty bad at algorithms problems myself.
So I think competitive programming can be helpful.
I will say if you have done competitive programming
before, the difference between competitive programming
and interviewing is that in competitive programming,
your variable names do not matter.
You're just trying to go super fast, and oftentimes that
means being sloppy or allocating these huge arrays.
You don't have to calculate the links of things.
So definitely don't do that.
In a real interview, the readability of your code matters a whole lot more.
So other sites, more advanced sites, are things
like Top Coder, where there's other sort of problems, practice problems.
They'll be a little more advanced, but they're still a good practice.
DAVID MALAN: Another question, Tommy, that
came from Pamika was, I wonder if most interviewers would give
an interviewee a general problem like this for entry level,
or if they would likely give a more adaptive problem related
to the interviewee and the job in question?
CONNOR LEGGETT: Yeah, that's a good question,
and I think that's sort of what we were getting at before about
the different types of interviews.
So I'd say, this is a really common interview type.
What's nice is that it removes a lot of the background,
because you can use whatever language you want.
It doesn't require you to know some particular framework or library.
You can solve this in a whole bunch of ways.
That's the advantage of a problem like this.
You may also see, in addition to this, something
that's more specific to the role that you're working on.
So if you're applying to a web development role,
you might have a question like, make a website.
So we didn't do a mock interview for that,
but I'd say those are less common than these really general questions.
But you could still run into them as part of the whole interview process.
DAVID MALAN: And Tommy, for students who aren't at Harvard or Yale
and might not be considering FAANG companies like Facebook and Apple
and Amazon, Netflix, and Google, is the kind of prep
that we're offering today focused on those types of companies' interviews,
or tech more generally?
TOMMY MACWILLIAMS: Yeah, these are really just focused on tech more
generally.
I think every company will have its own process
and might do something different.
But the idea of being asked to write some code in some setting
where someone is watching you and having to think through your thought process
and think out loud, that's pretty universal at a lot of companies.
And like I said, every company might do something a little bit different
or have some more specific interviews, maybe some online challenge
or something written or something like that.
But holistically, you're thinking about all the same things,
and all the prep work you do is probably going to apply
to a really wide variety of interviews.
DAVID MALAN: And perhaps a question for Maria or Connor--
how do you stop getting nervous during your interviews?
CONNOR LEGGETT: So short answer is you don't.
I get nervous before every interview.
But one thing that I--
like Tommy said before, practicing really helps, and not just practicing
on your own or with friends, but also practicing
in the form of other interviews.
So I've applied to a lot of companies this year.
And so I have gotten to the point where I'm doing a few interviews a week.
So the first week I was doing interviews I was a lot more nervous than now,
where it seems like kind of a routine.
I know my introduction, I know how to ask clarifying questions,
I know what questions I'm going to ask interviewers
about their job, different things like that.
So I would say that, just like a lot of things,
the more you do it, the less nervous you'll be.
MARIA ZLATKOVA: I would say repetition.
I also think, if you can, practice with friends and kind of switch
up the interviewer-interviewee roles.
You can also involve some empathy on the other side, as well.
But really just put yourself in those situations and kind of simulate
the interview situation, even when you're
solving practice problems on your own.
And like Tommy alluded to earlier, don't just
be like, oh, I think I kind of know how to do this and then
look at that solution and be like, yeah, that's what I was going to do.
But actually time yourself and go through it
and repeat as often as possible.
DAVID MALAN: And Tommy, a technical question-- you
mentioned one or more times that people should factor out common logic.
What did you mean by that?
TOMMY MACWILLIAMS: Something I say-- it's not like I say it all the time.
But oftentimes when you're writing code, just generally, but also
in an interview, you might find that some of the code you have is repeated.
Either it's repeated-- literally the code is the same, like you're
doing the same thing to different variables, or just parts of the logic
are repeated.
Maybe you're doing a null check, or you're
doing some kind of string manipulation that's similar in multiple parts.
So if you notice those kind of similarities
or repeated logic in your code, try to create a separate helper function that
just does that logic, and then call that helper function from the main function
you've created for your interview.
So that process, I think it comes from algebra, factoring things.
You could sort of factor out the logic by saying,
here's these two things that are common.
Put it into some common function that you call in both cases.
DAVID MALAN: And Tommy, a few folks have asked whether they should
be commenting their code in interviews.
TOMMY MACWILLIAMS: Yeah, that's an interesting question.
I will say your interviewer preference might be different,
depending on the interviewer.
Me, personally, I wouldn't spend a lot of time
on that, because you don't have a lot of time in your interview.
You're already narrating really naturally what your code is doing.
And so if you're just typing out a comment that
matches exactly what you're saying, that's
just describing what the code is doing, it's probably not a great use of time.
Depending on your style and your interview style,
maybe adding a quick docstring to the function or just a comment
at the top of the function that explains what it's going to do can be helpful.
But in general, I wouldn't spend a lot of time commenting the code as you go,
given the setting.
DAVID MALAN: And we do have time for a few more questions.
In fact, if you'd like to raise your virtual hand in Zoom by clicking
the raised hand icon, happy to call on some folks
if you have your video and microphone on.
And Tommy, in the meantime, a couple of folks asked, among them Aisha,
if you face a problem while writing your code and can't think of the solution
even after a hint, what can you do?
TOMMY MACWILLIAMS: Yeah, I will say, it happens.
I've hit many a wall in an interview.
I think, even if the interviewer gives you a hint and you think about it,
I think it's super reasonable to say, OK, I see what you're saying,
but I'm not sure how that applies to the problem,
or I'm not sure I totally follow.
Can you give me some more information?
Basically, it's a conversation.
Your interviewer isn't there to be a robot
or try to put you in a situation that's tough.
They want you to succeed.
And so if they're trying to help you, and they haven't helped you yet,
just keep asking for more clarifying questions and more hints,
until eventually you get unstuck.
But sometimes I've been in interviews where I'm like, hey,
I just didn't get it.
The interviewer had to totally handhold me
through the problem, which is usually what will happen.
They'll just give you hints that are so obvious,
they're writing the code for you.
And then I got rejected, and that's--
it happens.
But the more you're making it a conversation and a dialogue,
the more opportunities you have to be helped.
DAVID MALAN: OK, and we have a hand up from Yashasvi,
if I'm saying that right.
Yashasvi, if you'd like to say hello and what your question is?
YASHASVI: I would like to ask Tommy, sir,
what was the best thing one can do to impress any interviewer, probably
in etiquette, or something like that?
TOMMY MACWILLIAMS: Sure.
So if I had one thing that would impress an interviewer the most, for me,
the most important part of the interview is communication.
So if I were to focus on one thing-- or the thing as an interviewer
that I come out of interview, I'm like, wow,
that was great-- that thing is probably because they communicated really,
really well.
Whether that was asking clarifying questions,
just explaining their approach or the way
they thought about the problem, that's usually way more important to me
than, oh, cool, they use this crazy Python built-in I didn't know existed.
Communication is way more important than that.
DAVID MALAN: And a question from Karthik, if you'd like to say hello,
where you're from, and what your question is.
KARTHIK: I just have a question.
For a beginner level or technical interview,
does clean code really matter?
The super most optimized code, really it matters, or an optimum level
code or an ordinary level code?
I just want to know that.
TOMMY MACWILLIAMS: Yeah, so I think the number one thing
that matters is the process.
So the way that you get to that code and the way
you're reasoning and communicating, that's
way more important than how perfectly optimized your code was.
And then the other thing I'll say is that the expectations the interviewer
has are going to vary, based on your experience level.
So let's say I'm asking a question of someone with 20 years of experience.
I'd expect their code to be better than if I'm interviewing
someone for their first internship.
So I think it's going to vary.
As you're practicing, I'd say, write the best code that you can.
Make sure that you're thinking about, is the code clean?
But like I said, the process and your thought process communication
is always going to be more important than the code you write.
DAVID MALAN: Michael, would you like to say hello and ask your question next?
MICHAEL: Yeah, hi, my name is Michael, Fairfield, Connecticut.
So this is kind of--
I had to think a little bit about this question,
because you guys covered so much, and I felt like any technical questions
I had were already answered.
So anyway, I'll just ask you.
I'm a pretty big dude--
I'm six-four, 260 pounds.
Sometimes I don't have the nicest face on, you know what I mean?
So what can I do when I get to the interview and I'm nervous,
and I just look mean?
What are some things that maybe I can do to make my interviewer feel
a little bit more comfortable and know that we're here
trying to accomplish the same goals?
TOMMY MACWILLIAMS: Yeah, it's a great question.
I think I'm also someone who--
I'm pretty bad at hiding my emotions, which you could probably
see as I'm talking about resumes and things I'm tired of seeing on them.
I think the biggest thing is just, the interviewer
can tell when you're really nervous.
Sometimes I'll go on an interview, and, I'm like, oh, man this person--
I can tell within 30 seconds they're super nervous.
Me, as an interviewer, I'll try to keep it light
and help calm you down or make you less nervous.
Not every interviewer can or wants to do that.
The number one thing is just the more practice you have,
I think is really important.
For some people, having a glass of water available to them
can be really helpful, so just bringing a couple of water bottles
if it's on site.
I have a water bottle here, just having that ready.
Taking a deep breath before you start talking
or before you turn on that Zoom call makes a huge, huge difference.
So I think little things like that--
everybody is a little bit different about how
to make them feel less nervous.
But I think how nervous you are on your first interview
and how nervous you are in, like, your 50th is like such a big gap
that you just have to pay that cost, go through a bunch.
And then for many people, eventually, it starts
becoming less and less nerve-racking.
DAVID MALAN: Sarah, would you like to say hello and ask your question next?
SARAH: Hello, and first of all, thank you very much for your information.
And I want to ask, how can we explain our job
gap before starting this field, IT career,
I had a different experience in different fields?
And then I gave a break, like, five years.
After that five years, I'm starting searching for a job in the IT field.
So how can I explain this gap in my job experience?
Thank you.
TOMMY MACWILLIAMS: Yeah, it's a great question.
And something I'll say is that the experience you just
described of coming from a different field
or taking a break in between roles for some number of years,
it's becoming more and more common.
So maybe 10 years ago this was something you really had to worry about.
People were only in engineering if they had a degree in engineering.
I think now, so many people are coming from other career paths
and going through boot camps or online courses
or switching careers into engineering that it almost
doesn't need to be explained as much today as it would many years ago.
But I would just be honest.
I'd say, here's my background.
It was in some other field, could be totally unrelated to software,
totally unrelated to engineering.
Talk about your experience there, the impact you had, what you learned.
And then just talk about why you want to switch to engineering
and what you've done so far and why you're excited about it,
why you're excited to learn more and help a company and have impact.
But I would say, my short answer is I wouldn't worry too much about it.
And then to explain it, just be honest about what you've done in the past
and why are you looking to switch.
DAVID MALAN: Misarg, if I'm saying that right,
would you like to say hello and ask your question.
MISARG: My name is Misarg [INAUDIBLE],, and I'm from India.
And greetings to Tommy sir and David sir and everyone else.
So my question, if you get stuck on a problem,
what is the optimum time to think over it
before stating that we are unable to solve it?
TOMMY MACWILLIAMS: Yeah, that's a good question.
So it's sort of like, at what point do you ask for the hint?
I'll say one thing to keep mind is the total duration of the interview,
so if you know you're in a 45-minute interview versus you're
in a two-hour interview.
My general heuristic is something like three to five minutes.
If you've made no progress in three to five minutes,
that's when I would try to ask for a hint.
Sometimes just as you're sort of thinking out loud,
you'll eventually run out of things to say,
because you've run out of things to think of.
And at that point, too, if you find yourself being silent or just
not making any progress, think for a minute or two and then say,
actually I'm not sure.
Can I have a hint?
So if you're thinking it's in the ballpark of like 20 to 30 minutes,
let's say way lower than that, but I also
would say much greater than like 30 seconds,
because you'll give yourself a few minutes
to actually process it and think.
DAVID MALAN: We have time for a few more questions.
Do feel free to raise a virtual hand and turn on your camera
if you'd like to ask on camera.
Or repaste your question in the chat if we might have missed it.
We're doing our best to field as many as we can.
Yuvraj, if I'm saying that right, would you like to ask your question?
YUVRAG: So hi, guys.
My name is Raj, and I would like to ask a question
from an entrepreneurial standpoint.
So a lot of companies in the recent times
have changed the whole paradigm of hiring people and all that.
So how do you expect that it might change furthermore?
Even as a student if I look at, things have
changed from going offline doing interviews and all that,
to going online, due to this pandemic and all that.
So do you think things could change further,
or this is the top or something like that?
TOMMY MACWILLIAMS: Yeah, it's a good question, how interviews have evolved
and where they're going.
Certainly these virtual interviews are way, way more common.
Many companies, even if you could come on site,
just so much more convenient to interview
someone remotely rather than traveling six hours on a plane,
being tired at 9:00 AM the next day for the interview, which is not fun.
So that's definitely a big one.
I think that's a trend that will stick.
I think many companies will still do on-sites.
But I think before, I remember the companies I've worked at and friends
have had a hard policy on, we have to meet you in person before we hire you,
just cannot join the team unless we meet you in person.
I don't know why, but that was a policy.
I don't think you'll see very many things like that anymore.
I think another thing that's been changing
is that many companies are asking more of these practical questions,
especially to folks with more experience.
And I think that's good and bad.
I think for many folks coming out of university or new grads,
asking them a practical question in many cases
is worse, just because they haven't ever written production code
or launched a production website.
And so asking somebody to do that, it actually
doesn't give you that much signal.
And asking an algorithms question to a student who's taken algorithms classes,
and they're really good at that, can actually be higher signal.
And so where I see this shift coming is that,
if you have the experience of building these systems,
we're going to ask you about it and maybe
ask you to build something similar.
And if you don't, then we're not.
Where I think a few years ago, there's this blanket everybody
has to do whiteboard questions, because whiteboard questions are
the be-all end-all.
And I'd say they have a purpose.
A lot of people are like, whiteboard questions are always bad,
they're useless.
I don't subscribe to that at all.
I've interviewed so many students who do better on these than they do on
build a website questions.
So they have their place, and I think they're
becoming more of a specialized thing than a blanket part of the process.
DAVID MALAN: And Tommy, a couple of questions
that have come up a few times now in the chat
relate to folks who either don't have much work experience, because they're
just coming out of college, or they're older and have
gaps in their resume for some reason.
What kinds of personal technical projects
should people in those situations take on?
And when it comes to languages, given that they
might have a choice of languages, which languages should they
be picking up for interviews?
TOMMY MACWILLIAMS: Yeah, that's a good question.
I'll start with the second one.
I would pick up languages that are more popular.
So I think that takes the form of Python or JavaScript, would probably be my top
two.
Those are languages you could use to build a little web application
or visualization or a command line application.
I wouldn't try to pick up as a first language something like Haskell or Rust
or some of these more sort of less mainstream
and have a higher barrier to entry.
So Python or JavaScript are good ones to start with.
And then for a personal project, I would say build
something that's interesting to you.
My best advice to people is that everyone in their day-to-day
has some problem that they're dealing with.
Maybe it's taking notes in class or organizing some files in their laptop.
Everyone sort of has these little problems that they deal with.
Just write a little app to solve them for yourself.
I remember one of the first things I built
was this little weather visualizer, because I
didn't like the weather.com things.
I'm like, oh, let me use their API and just build a little weather app.
And I just had that in my room where I could wake up and check
my little weather app.
There's thousands of weather apps out there, but who cares?
It was like a problem that I thought was kind of interesting,
and I went and solved it.
So everybody has those little things that are interesting to them.
So pick something that's interesting to you
and write a little command line application or web application
to solve it.
DAVID MALAN: A few final questions here--
Sarah, would you like to ask your question
and tell us where you are in the world?
SARAH: Hi, I'm Sarah from Algeria.
And I was wondering, do you think I could ask all the questions that
are in my mind about the work and the company to my interviewer,
even after I know that I failed with my code and writing the code
and solving the problem?
Do I have the right to ask them or not?
TOMMY MACWILLIAMS: Oh, at the end of the interview when they ask,
do you have any questions for me, even if you
know that the interview didn't go well?
SARAH: Yes.
TOMMY MACWILLIAMS: Yeah, I think so.
I think you should always-- they're still
interested in giving you a good experience with the company.
Even though you didn't pass this interview, who knows?
You might come back a year or two later, interview again, and then do fantastic.
And so if the interviewer can give you a good picture of the company now,
that might help you say, oh, I will go reapply again,
because I really like the person I talked to,
and I've learned a lot since that first interview.
So yeah, I definitely say when you have a bad interview experience,
it happens to everyone.
Try not to get too down on yourself.
When they ask, do you have any question for me,
I'd still ask the prepared questions you had
about their day-to-day or the things that they change about the company.
So I wouldn't change any of that.
And then who knows?
You could see that same interviewer again a few years later.
DAVID MALAN: And Tomas, would you like to say hello
and where you're from, along with your question?
TOMAS: What's up, guys?
I've enjoyed a lot, and I'd like to know,
sometimes when it comes to an interview, there
are companies that ask you about your salary.
By the way, I'm from Venezuela at the [INAUDIBLE]..
So when it comes to interviews, there are companies
that ask you about the salary.
So is there a way to know what would be the best?
Because I think this was not so covering in this.
TOMMY MACWILLIAMS: Yeah, so how to think about salary and negotiation generally?
TOMAS: A way to know what would be the best amount or--
because sometimes we could ask too much or too little.
And are we even supposed to answer that, or we can just avoid that question?
TOMMY MACWILLIAMS: Yeah, this one's a tough one,
because it's going to vary a lot by role and country and company.
So I can try to give some general advice that may or may not
be a little too US-specific, just because I'm not
super familiar with all the different international conventions.
But something that is certainly applicable
is before you go into a role, try to get a general sense for what
the market is paying for that role.
There's lots of sites online you can look at, whether they be Glassdoor--
there's another one that's in the US called
Levels FYI, where people just publish, here are the ranges of what
I'm making at this role.
The company might also publish it in advance.
There are some sites like Angel Lists that start-up used to recruit,
and it's sort of a required field, is how much are you
going to be offering for this role?
So yeah, just do a little bit of research in advance.
I'd say try to give a range too.
I think some people are like, I must make at least n-amount of dollars
or I'm not interested.
I think that's usually not the right approach,
but giving sort of a general range, also sort
of talking about what you're currently making in your role,
and what you'd ideally like to be making more than that, having
your current compensation can be kind of a baseline there.
So I think, yeah, my general advice is just
to try to be honest and try to do some research in advance.
And then that can help you avoid this outcome
where you're asking for something that's way too low or way too high.
But yeah, every company is going to be a little bit different
in how they handle this.
Some companies want you to disclose what you're looking for first.
Some companies say, here's the role and the level we're going to level you at.
Here's what people in that role and level make.
It's going to be a little bit different.
But the research part you can always do.
DAVID MALAN: I think we have time for a few more questions.
Hope folks will forgive if we don't get to everyone.
We also want to leave a moment at the end for Maria and Connor,
if you're amenable, to offer just some final thoughts of your own.
But first, Aisha, if I'm saying that right, would you like to say hello,
where you're from, and your question?
AISHA: I am from Pakistan, and it's Aisha.
DAVID MALAN: Aisha.
AISHA: Yeah.
And first of all, I have to say that this lesson has been great.
I did not know most of the things, and some things really surprised me.
So I absolutely enjoyed this lesson.
And my question is does it matter, the style of the interview?
Does that differ if you have a different level of experience
or your level of your education or something
like that or the level of what you are, like in CS, if I'm an absolute beginner
or I have done really less experience, one year or two years,
does it matter the style of the interviewer,
the interviewer itself, or the assignment?
TOMMY MACWILLIAMS: Yeah, it's a great question,
so how things vary based on experience.
So the general setting tends to be the same.
Even people with a lot of experience will still ask a question of the form,
write a function that takes this as input and takes that as output.
I think the expectations will vary a bit for someone who's really new to CS.
The problem we ask might be a little easier, a little more straightforward
to solve.
For somebody who has more experience, might ask
something a little bit harder.
And then I mentioned before, something that you'll
see as you have more experience is more questions that
are a little more practical, telling me about how you've architected
some large-scale system in the past or to build something from scratch that
would be production-ready, where for students, they're usually more asking
questions about the things that you've covered in your courses.
Many people take a data structures or an algorithms course,
and so we'll ask a question about data structures or algorithms.
I think in general, the ideal interview and what a lot of interviews
do-- and hopefully they're all doing-- is looking at your experience,
seeing what you've done in the past, and then asking questions based on that.
So if you've never built a large-scale backend system,
asking you to build a large-scale backend system
doesn't really make sense.
I'd rather ask questions that we're going to get a lot of signal out of
or I'm going to understand, are you a good fit for the role I'm hiring for.
And if I just ask you something where you have no idea,
then I'm actually not getting any information.
DAVID MALAN: Andrew, we saw your hand go up earlier.
Would you like to say hello and ask your question?
ANDREW: My question is, can I get the job after completing university only?
TOMMY MACWILLIAMS: Tommy, can one get a job after completing university?
TOMMY MACWILLIAMS: Yeah, definitely.
There's lots of job opportunities that are especially
designed for folks who are just coming out of university
and haven't had any jobs before.
Internships can also be a great way of getting a role if you haven't
had any experience yet, so definitely lots of great roles
you can get just out of college.
DAVID MALAN: Nice, and can we go next to Shalom, if you'd like to say hello
and where you're from with your question?
SHALOM: My name is Shalom, and I am from South Africa, currently in Beijing.
My question is, I studied chemical engineering and technology.
So this is really new to me.
I recently started my course on CS50.
My question is, what do I study after completing that course?
TOMMY MACWILLIAMS: Yeah, that's a great question,
after CS50, where do you go next?
I'm sure David has thoughts on this, as well.
But I would say in general, for interviewing specifically,
any course that has data structures or algorithms written in it,
those can be really, really helpful, so the courses
where you're going to learn what a binary tree is
and how to implement a hash table, some of which we cover in CS50,
but there's more advanced data structures and algorithms.
So I'd say those are the most useful courses you can take for interviewing.
And then maybe David wants to answer the more general question
of where to go next.
DAVID MALAN: Yeah, we often recommend that students
explore another type of programming, functional programming,
object-oriented programming, keywords like those,
as well as a good course on data structures and algorithms,
for instance.
I'm biased, too, because I work with a whole team here
that produces courses that can be taken both before and after CS50.
But Maria, can we perhaps ask you, having been in the real world
as an engineer for some time, what you found most helpful after an intro class
like CS50?
MARIA ZLATKOVA: Yeah, so I think really trying to get a breadth of classes
out there and exploring different interests would be good.
When I first took CS50, some of my next classes
that I took were systems, operating programming, data structures
and algorithms, data visualization.
And I found a lot of the more visual and design-oriented classes
super interesting, so definitely got a chance to focus in on that, as well.
But I definitely would say that exploring a breadth of things
so that you can really decide what you want to hone in on and what really
interests you is always a good idea.
DAVID MALAN: And I think Tommy's emphasis on personal projects
earlier is important, because we see among online students
a real tendency to take one course, then another course, then another course,
and it's never really clear when it ends.
And it doesn't need to end, but at some point,
you should really leave the nest, so to speak, and take
on some personal project, pursue some work project,
so that you feel like you're actually now applying the skills
that you've learned in classrooms.
Some final questions-- can we go next to Remington,
if you'd like to ask your question and say where you're from?
REMINGTON: My name is Remington.
I'm currently in the UK in quarantine.
It's lovely to join you guys today.
It was super helpful.
I don't mean to focus too much on the resumes,
but it's another resume question.
So if I'm a student, non-CS major, and I've
had some internships that are not really tech-related,
is it more valuable to add those to kind of fill out my resume,
or should I really try to do more personal projects
and then add those into my resume instead?
So which one would be more valuable, is my question.
TOMMY MACWILLIAMS: Yeah, I would say if I had to pick between those two,
I would say the latter.
So having personal projects that are related to the roles
that you are applying to are really helpful.
So for instance, if you're applying to a web development role,
showing some websites you've built is really helpful.
And I'd say even if you only have a few, that's totally fine.
Fill out the rest of your space with your prior experience.
But an interviewer will definitely love to see something
that's related to the role that you're applying to more
than the past experience you do have.
So I'd say projects first, then fill out the rest with prior experience
you do have.
And definitely include that, as well.
DAVID MALAN: And Shaurya, if I'm saying that right, would you like to say hello
and your question?
SHAURYA: My name is Shaurya.
I'm from India.
My question was, is keeping a smile on your face
while the interview is not going that much well,
so does that affect any impact on the interviewer?
TOMMY MACWILLIAMS: Yeah, I'd say whether--
everyone knows that interviews can be really stressful,
and so I don't think I've ever expected anyone to be like, totally happy
and not stress the whole time.
So I would say the best--
it all comes down to communication.
I think as long as you're communicating clearly,
and you're having a good dialogue with your interviewer,
and you're able to share your ideas and listen
to feedback from your interviewer and hear their hints,
I think that's the most important thing.
But everybody's really nervous, and I wouldn't
recommend anyone trying to fake how they're feeling
or pretend to be feeling a certain way, when the reality is that everybody
knows that it's nerve-racking.
And so interviewers don't expect you to be doing that anyway,
and it all just comes down to communication.
As long as the communication is effective,
that's the most important thing.
DAVID MALAN: Let's go lastly to Pawan Kumar, if I'm saying that right.
My apologies.
PAWAN KUMAR: So thank you so much for this opportunity.
So my question is more on the system design level.
So yeah, somehow we did so much hard work for some brilliant years,
and somehow we were able to break the coding interviews.
But then we have another piece called system design, where someone
with my experience--
I have 10 years experience, I live in the United States.
Though I have experience when it comes to their questions
on how to design a Facebook, how do you design a Twitter, yeah,
we design things in our site, but it doesn't
mean it's going to be that level.
So can you please give me some idea of how do I prepare for the system design
interviews?
TOMMY MACWILLIAMS: Yeah, for sure, I'll give some quick thoughts on systems
design interviews.
So generally speaking, what we're looking
for in a systems design interview is often something architectural.
So for example, you mentioned how you build the Facebook news
feed, for instance.
So we're not looking for precisely like, I
would use 0 mq with a fan-out architecture
and a multilayered [INAUDIBLE] tier for caching.
If you could say that, that's great, but we're
more concerned about architectural things, like here
is what the schema of the database would be,
here's how rows are written to the database,
here's where the caching layers are, what's being cached,
here's what's being read from those.
So it's almost like if the goal of a system design interview
is to have a diagram out on a whiteboard,
either verbally or literally, that explains
all of the major components of the system and how they interact.
And that's much more important than picking
the individual library or the sort of implementation details
within that diagram.
I think if you can speak to technologies you have used in the past
and say, in the past we use Kafka for message passing,
and here's some things I liked about it, but here
are some ways we're kind of broke down and things
like that, that experience is really valuable.
But for a systems design interview, we're
almost never looking for some really precise answer.
The other thing we're also not necessarily looking for
is exactly what part of the system you design.
In many cases, it's really intentionally ambiguous.
One that I've got in the past is, how would you make Google Maps?
End of question, turn it over to me.
And that could mean anything, right?
That could be the front end, that could be,
like, how do you implement all the scrolling.
It could be, how do you store all of the map?
There's tiles of different elevation levels and resolutions.
How do you store that?
It could be, how do you do--
Google Maps includes routes.
How do you do route planning and traffic?
And it was sort of intentionally ambiguous,
and the interviewer was like, oh, I don't know,
whatever you want to design, do it.
You've got an hour, let's just see what we can do.
And so I keep that in mind, as well, that sometimes it might feel like
the interviewer doesn't have anything in mind, and it's because we don't.
We just want to see where you gravitate to,
because you're naturally going to gravitate, hopefully,
towards the thing where you have the most experience
and where you can design the best thing.
So yeah, so really focus on that architecture.
Focus on what are the components of the system,
how do those components interact, what are the abstraction
barriers between those systems.
Then if you can talk about implementation details like frameworks
or libraries or patterns you've used in the past, then you can do so.
But we're really mostly interested in architectural decisions.
DAVID MALAN: And Tommy, [INAUDIBLE] question
was about what should you do when you get frustrated and stuck with coding?
TOMMY MACWILLIAMS: Yeah, I think in an interview, like I said,
it happens to everybody.
It'll happen to you, and it's happened to me.
I think just taking a deep breath and taking
just a step back, just 10 seconds, take a step back and think and calm yourself
down as best as you can.
Take a glass of water if they have one.
If they don't, bring one so you have one.
And then just ask for a hint.
I think a lot of interviewees, when they get frustrated,
they sort of get angry or sort of get mad.
And I think it certainly might happen.
Just try to, as best you can, try to take a step back
and ask for help in a way that's sort of keeping the conversation light
and not becoming overly angry.
But it certainly can happen and has happened to me and people
I've been interviewing in the past.
So yeah, I would say if you get frustrated, just ask for a hint,
take a deep breath, and remind yourself that everybody fails
these things, that it's not just you.
DAVID MALAN: I have folks who still have their hands up.
Well, forgive if we didn't get to all questions, but in our remaining minutes
here, just wanted to give Maria and Connor
and then Tommy the final word with some final advice.
Maria?
MARIA ZLATKOVA: Yeah, I really would just say, don't be worried
or scared when you mess up.
I have messed up so many interviews, and I sometimes still think back to them.
And I kind of find them funny now thinking back,
because I really just put so much pressure on myself that it even
prevented me from doing well and showing what I knew well
and actually thinking clearly in the moment.
And we said this a lot, but the best way to do
that is to really just practice and put yourself
in those high-stress situations to get yourself more used to them.
And we believe in all of you, especially in coming to this,
I think you're taking the best steps that you can.
So it really is just about taking this and these guidelines
that we shared today and just practicing and really mastering everything.
So thanks so much for spending the past few hours with us.
DAVID MALAN: Thank you, Maria.
And Connor?
CONNOR LEGGETT: Yeah, I definitely agree with that.
I would say the biggest thing is to--
even though it's very difficult, to try and be as relaxed as you can.
Try to have a good outlook on it.
One thing that I think I've found out over the last couple of years
that I had wished I had known going into it
is that a lot of the interview process is a bit random.
So you might get a question that you feel really confident about
or a question that you just have no idea what to do.
And there can also be interviews where you feel like you did really well,
and then you don't get into the next round, or interviews
that you feel like you bombed, and then you do get into the next round.
So I think that's kind of helpful to know,
because even if you struggle with the question for a while,
it's not a good idea to give up on that interview.
You want to keep trying, keep interacting with your interviewer,
and you never know what's going to happen.
DAVID MALAN: Well, thank you, as well.
And thank you to all of the team here behind the scenes
who've been making this possible and certainly Tommy,
who prepared so much of today's materials, along with Maria and Connor.
Tommy, final advice you'd like to leave folks with?
TOMMY MACWILLIAMS: Final advice, I'll say don't give up.
I'll never forget my first interview where I
was interviewing at a big tech company.
And we're in a building with an elevator,
and the two people from the interview, my interviewer and someone else
in the company were in the elevator.
And they were talking about how bad I did in the interview,
like, this kid was such a joke.
And I walked into the elevator and then took the elevator
down 10 floors with them as they just like stared at me,
and everybody knew what was happening.
So I'll never forget that.
It happens to everybody.
Definitely don't give up.
You can fail a ton of interviews before you eventually succeed,
and that's totally OK.
Everybody goes through that.
So yeah, you might feel like this is impossible.
Who can possibly do this?
You can.
Just don't give up, and you'll get there.
DAVID MALAN: Thank you so much, Tommy.
Thank you for joining us today.
We'll see you online for CS50 again soon.