Make Better Software: The Training Series – Module 1: Recruiting

[Calm piano music] Joel:
The truth is, the only reason
I started Fog Creek Software is ’cause I kept trying
to look for a great place to work in New York that treated
software developers well. And I just couldn’t
find one to work at. So, in desperation,
I finally made one. I mean, I would go to parties
and I’d meet somebody and I’d be like,
hey, what do you do? I’m a programmer.
Oh, me too. And they’d say, “Do you know
any good companies to work for
in New York?” And I’d say, “No!”
[chuckles] Everywhere I looked,
I saw companies that were having trouble
recruiting programmers, and not treating
programmers well, and they didn’t put
these two things together. They didn’t realize that if
they treated programmers well, it would be easy for them
to recruit programmers. And so, I decided that that was an opportunity that I had to fill, and I just needed
a place to work that I liked. So I started Fog Creek. I started writing a website
called Joel on Software in an attempt to
kind of put down on paper some of the things
that I had learned over the course of my career in how to develop software successfully. And, part
of my mission in life and part of the goal of
Fog Creek Software as a company is to teach you
how to be awesome, and to let you learn how to
develop software successfully using some
of these same methods. And some of these basics steps
that make sense– they’re logical,
they’re easy to follow, and when you do them, you’re gonna be more successful
in software development. Think about what
a programmer is doing. Every single line of code
that a programmer writes involves
several decisions. You have to decide
what line of code to write and then
you have to decide, you know,
if you’re calling a function, what are gonna be
the arguments to all those parameters. If it’s an “if” statement,
that’s a decision. And every single
one of these decisions is sometimes a judgment call,
and the smarter you are, the better the judgment call
is gonna be and the more likely
that code is to work. [opera singing] There’s an aria in Mozart’s,
“The Magic Flute” called
“The Queen of the Night” and it’s sung
by a soprano who has to, I think, twice hit
this high note called a F6. [opera singing] The average soprano
cannot sing this song, cannot do the “The Queen
of the Night” at all, ever. And I think the same thing
happens in software. You want to hire programmers
that can reach the high notes, that can do the really
excellent achievements and that come up
with sort of great ideas that come up
with great designs that maybe
the average programmers would never come up with
in a million years. Okay.
So, we’re about to start our campus recruiting season
for the fall with the goal of hiring another
six interns for next summer. And another couple of
co-ops, at least. We could probably have
as many as four for, when’s the co-op term,
June? January.
January, right? male voice:
January to the end of April. You want to have
as aggressive an internship
program as you possibly can. One of the things
that we noticed very early on is that when you’re
recruiting for internships, for summer internships, the audience
you’re recruiting from is all college juniors
majoring in computer science, and they’re all applying
for summer internships. Whereas when you are recruiting
for a fulltime job, the audience
you’re recruiting from are people
who hate their job, and people who got fired
from their job. So the college,
when we look at the resumes from college juniors
applying for internships, honestly, they’re
much, much higher quality than the average resume
from somebody fulltime applying for a job. There are a couple of
reasons for this. But the bottom line is that the really,
really smart candidates don’t apply for a lot of jobs
in their life. I mean, some of the best
programmers that I know have applied for,
you know, maybe seven jobs
in their entire life, including the ones they took
and the ones they didn’t take. When you get a resume,
the easiest thing to do is take a piece of scrap paper,
write P-B-E-C-S-J, as it’s column headings,
and then go through the resume looking for those six things,
the resume and the cover letter, looking for those six things, and if you find them,
check them off. So I’ll go over what they are,
roughly what the categories are. “P” is passion
and that’s like, passion for software developments tasks, like, people
that love programming, people
who love computers, or people that just like
gadgets or stuff like that. Brains, we just have these
like, little numbers for that. But brains is, you all know
what a brainiac is, right? These are the people
we make fun of in school. Here’s some examples. [laughing]
They have high GPAs. “E”, we do actually want them
to be able to communicate well, so the quality
of their writing, both in their cover letter
and their resume, in English writing,
is pretty important to us. Okay. So “C”
is creativity and flare. What we’re looking for is, were you being creative with
your application, in some way? And almost all of you were. And it’s either,
I sat down, it’s either,
this is a custom cover letter for Fog Creek. It says something
about Fog Creek, or Joel on Software,
or even New York City, even if it’s like,
you know, when I heard there was
a software company in New York, I was really excited. This is probably worth
more of our time to pursue the people
that think that Fog Creek
is special in some way, and are likely
to come work for us. So that’s creativity. And flair is like,
literally, I think, probably,
three-quarters of you, when you applied to work
at Fog Creek, did something
on your cover letter that was like either
funny, or witty, or unique,
or individualistic, or just like
not your standard cover letter. “S.”
“S” is for screening. And so what you’re gonna do
is look through the resume for institutions
that you know are selective and that have
screened people and that don’t take everybody
that applies to them, whatever
the institution may be. The easiest thing is– so, obviously schools
that they go to and that means selective schools
will get you this point because we know
that somebody somewhere has evaluated you
in some fashion. Cool? Over the years,
the last couple years, we’ve been kind of lax
about this “J” thing, junior in college. Basically, our ideal intern
is a junior,
for several reasons. One is,
you can make them an offer at the end of the summer and they’re not gonna have
any other internships that are gonna
get in the way, and make them want to
go work somewhere else. The people that get
internships as juniors are much more likely to turn out
as fulltime developers, so that’s why we give them
sort of substantial preference. Cool.
That’s it. Thanks. ♪♪ Cheerful Music Ben:
The resume review
is the first section of our difficult process
of getting hired and we try to make it
as democratic as possible. This person
went to Stanford. That’s an immediate
selective plus. This candidate says
that they’re sick of working for the “giant Borgs”,
larger companies, and they’d like to come work
for a place like Fog Creek. This indicates that they know
who our company is. They’ve read a little bit
on our website and I will give them
a creative for that. This cover letter
is also well written so they score an “E.” So that’s three letters
right off the bat that this candidate got. So here, this person
has competed in an HP programming competition. This is a good sign. You know, this is somebody
who is going out of their way to practice
their own computer science, compete against others, and the GPA
is 3.8 at Stanford which qualifies
for brains. So this is a great example
of a candidate, that this person
just got all six letters and they’ll certainly be phone screened. Joel:
We don’t get
a lot of information out of the cover letters
and the resumes. The format is not ideal for
applying for programming jobs, doesn’t really show,
there’s nothing on a resume that shows that you know
how to program or not. And so, the best we can do
really is try to guess whether it’s worth going further
with this person or not based on the information
on the resume. Ben:
This is a much shorter
cover letter which doesn’t
really indicate that they know anything
about the company. And it’s a very standard
cover letter which could’ve really been sent
to any company, and doesn’t convey
that Fog Creek means
anything different than any other company
to this person. So I cannot
give them a creative. It is well written. So, so far, this person
gets an “E” for English. Now, this is
an example of somebody who did not originally
give us their GPA and our automated bot,
e-mailed them and said, please give us the GPA, and they came back and said
their GPA is 2.86, so that’s not indication
of a “B” in this case. This college is also not
on our selective list. This person is a junior. And this person also has some additional typos
in their resume that describes
their personal– their goals
and their research history. This is usually
a very bad sign. If somebody has typos
in their resume, they haven’t gone through
and checked some of the most basic things. This person also
already has three Xs, so that’s gonna be
a ding from me. Typically, you know,
we need programmers who are going to be
communicating with customers. We need them to be able
to communicate their ideas, to spec their ideas, and having typos
in your own resume is a very bad sign. If you have
five or six letters, you’re likely to get
to the next stage which is
the phone interview. The phone interview consists of
a developer calling you up; we’ll schedule a time,
usually after work, and asking you
some programming problems that are conducive to
telephone conversations. So, not quite as much detail,
a little bit more like, maybe a conversation
about algorithms, conversation about
data structures, just sort of like, how would
you build this thing in code, and the developer
will tend to, the person
conducting the interview will tend to drill down a lot
in certain areas just to see
if the person, if the candidate
is really highly technical. Hi, this is Benjamin
at Fog Creek Software. I kind of want to do this
in three parts. First, I want to
give you a chance to kind of talk about some
recent stuff you’ve done that’s really exciting, and then work through a bit of
a design question together, and then give you a chance to ask me any questions
you’ve got about Fog Creek. The fellow I interviewed today
was a senior developer. He’s been out of college
for 10 years and had experience working
at Microsoft and Tablet PC, and on Live Search, and also
had a fair amount of experience actually working at NASA. candidate:
I was, with the code,
the stuff that I worked on was for the ovens
that were supposed to heat up the soil samples that the robotic arm
dug out of the dirt, and analyze them for
presence of various chemicals. Uh-huh. candidate:
But, unfortunately,
the guidance system on the spacecraft didn’t function well enough
to get it to that stage where you’d ever deploy
the robotic arm and start digging,
so that didn’t work. But, somewhere on Mars, there’s
been some like code, like– I mean,
that’s pretty impressive. I have my name
on a satellite, if I recall correctly. But that’s about it. candidate:
Oh, cool.
Cool. We had talked about
Tablet PC, about Newtons,
about Palm, about Live Search, about converting
web applications
from C++ to, about whether Cocoa
was really the next big thing, or whether it’s just
really overhyped. The best way
to do a phone screen is to pick a very, very
technical topic to talk about, a very programming related
topic that doesn’t require
writing code. It doesn’t require a lot of
specific knowledge. Like, you don’t
want to ask people to remember the orders
of the arguments to a function
in the function library. You really just
want to say something like, you know, what would be
good data structure to use
for a spreadsheet? What would be
a good data structure to use
for a word processor? How would you
write a program that generated Sudoku puzzles? That kind of thing. You want to have a conversation
which involves, which can be done strictly in English
conversation, just to get an idea. Well, are you okay moving on
to the design question? candidate:
Sure. Sure. Okay.
All right. So I kind of just
want to talk through this, but basically, I mean,
so you’re a programmer. One of the things
that we basically live in is our text editors.
Right? So it’s really important that all the operations
that we do are really fast. But when you start
to really think about what you do,
you start realizing, you’re manipulating
a large amount of data and you expect it all
to be really responsive. So what I kind of
want to explore is how to design
the in memory data structure to handle all the text
in the text editor. candidate:
Okay. Okay. Okay.
Well, let’s see. So, you,
well, you can have, I mean,
to the point of absurdity, you can have
like just a string keeping track of
all your text, but of course,
that’s gonna, you said, you know,
needs to be responsive. Right.
So you have a potentially
very long document then that could be quite–
especially if you’re, you know, you’re inserting a character
or something and you have to copy
all the other characters. Right. candidate:
That you have to like shift
the rest of the buffer. That would be bad. So I think you’d want to have some sort of
division, some sort of a–
I don’t know, partitioning
of the whole string. One way to do it,
I guess, would be– Joel:
You’re trying to judge
if the person is smart. That’s your goal is to judge
if the person is smart. And the interview questions
that you provide are not to see
if they know the answer, and it’s not to see
if they get the right answer, or get the same answer
as you would have gotten, or to see if they’re brilliant,
and they get an answer that’s even smarter than
the answer you would’ve gotten. None of that.
The whole point of
the interview question is it’s an excuse to have
a conversation on a highly technical topic about code which is gonna give you
the most opportunity to judge if you’re
having a conversation with a smart person
or not. candidate:
If it’s a text editor
for programming or whatever, then typically you don’t have
lines that are very big so you could use just a string for each line, I
guess. Okay. candidate:
And, then you need to be able
to address those lines and– Benjamin:
I think he was a very strong
hire decision. He basically gave me
the correct solution in about four minutes
instead of say, 20. That makes it a lot more
enjoyable for me. ‘Cause especially, you know,
for consistency’s sake, we stick to the same
phone screen question
a lot of the time. We have got a couple
we alternate between. We keep them
pretty constant, and so, even with
a really good candidate, it’s really hard to stay
interested in the question. But when you get someone who
just blows through it like that, it actually is
pretty easy to do that. So cool. So I want
to give you a chance to ask me any questions
that you have about Fog Creek. candidate:
Well, let’s see. So I looked at the website, and actually, there’s
a fair amount of transparency. You’ve even got like pictures
of the office and everything. Yeah. candidate:
That kind of removes
a whole class of questions which I’m sure
saves you a lot of trouble. But I’m curious,
what’s your team make-up in the sense of like,
for a typical project? How many testers
and developers and PMs or whatever do you have
working together? Benjamin:
They’re gonna be small simply because we don’t have
many people and the benefit is
that it’s very easy to like, we’ve got really
friendly relationships with our QA team, which I know is a little bit unusual in some
places. But I’m very happy
to have it, and there’s really no administrative overhead. candidate:
Yeah. Good. Good.
Cool. Okay, well, next steps, then,
will you–? Yes. And next step,
you’ll be hearing from us in probably
today or tomorrow. In general,
it’s gonna be at least kind of
a remote coding interview, so it’s great that you
already got to work with
Co-Pilot a little bit. You’re gonna have a chance
to work with it a lot more. candidate:
And then,
if everything goes well, we’d be having you in the office
for in-person interviews. candidate:
Okay. Great. Well, yeah.
Well, thanks. Thanks a lot.
And it was a lot of fun. Yeah. candidate:
So I’ll look forward
to it. All right.
Thank you very much. candidate:
Have a great day.
Bye. Yeah, you too.
Bye bye. ♪♪ We know we’re gonna have
some false negatives. We’re gonna ding people when in fact,
they may have been great. But we error on the side of
that versus being too easy and possibly hiring people who are not gonna be
good enough. And that’s far worse
than losing a good candidate because if you do
hire somebody that is not going to be
good enough, it’s, you know,
hard to fire them later on. It is, you know,
you have to go up, and go and clean up after them
in the code base or whatever responsibilities
they’re given, they’re gonna go and start
to not to do a good enough job and you’re gonna have to spend
someone else’s time trying to fix these things and sort of,
they become a liability, which is bad. We’ll sometimes do
a phone Co-Pilot interview. We’ll use Co-Pilot, which lets us see
the interviewee’s computer. They run a little program.
We run a little program. We’re watching everything
that they’re doing, and we’ll ask them to write
a piece of code while telling us
what they’re thinking of. We’ll ask them to write
a simple function to do something
fairly simple just to see if they
really are a programmer, if they get it right, if they make, kind of
off by one errors that give you an idea
that this is something, somebody who’s really new,
a novice, or to see if they’re
really expert programmers. All right. So what we’re gonna be coding up today is a basic
spam classifier. candidate:
A spam classifier.
All right. David:
The function that we’re
gonna be implementing is called strcspn, and this is actually
a C string library function. If you’re, I don’t know
how familiar you are with C. candidate:
I’m semi familiar with it. When I, you know,
when I’m working it, I can, you know,
go and find stuff. But you’ll have to
explain it to me. Sure. Yeah. Tyler:
So, we’re not gonna worry about like statistical
methods, bayesian inference,
anything like that. candidate:
Right. Tyler:
All we’re gonna do
is write a function that takes in
the body of the email and checks to see
if any of a list of phrases that we pass it
occur there at all. The idea of this function
is that it returns, it takes two strings. The first one is the string
that it’s gonna search in, and the second one
is a list of delimiters, and what it does is it counts the number
of characters in the, it gives you the count
of the number of characters
in the string until one of those delimiters
is reached. Tyler:
Okay. So that’s basically what it’s gonna look
like there. We’re gonna pass in
a string of text. candidate:
Yeah. Tyler:
A list of phrases,
or an array of phrases, and the number of phrases
that we’re passing in. candidate:
All right. Let me think about this
for a second. Sure. candidate:
Okay. So I guess the first thing I should really
do is determine how many delimiters
are in the delimiter string and, you know, ’cause that’s
kind of important, I suppose. Joel:
Whenever you ask
somebody in an interview, whether it’s in person,
or over the computer, or over Co-Pilot, whenever you ask somebody
to write code, there’s a few things
you have to watch for. Number one,
they’re in an interview. They’re gonna be nervous. So you kind of have to
give them a free pass on being nervous
that has no correlation to whether or not
they’re a good developer. And, they’re gonna make simple,
kind of stupid mistakes. Sometimes, like, they’re
gonna make a simple mistake like they forget a semi colon
at the end of a statement, and you kind of
have to forgive that just ’cause
they’re nervous. It’s the interview
process. They’re not actually
typing into a compiler. The compiler would have
caught it for them. Sometimes, though, it appears
that they don’t know that their programming
language, which they claim to be their
favorite programming language, requires a semi colon
at the end of every statement, and then, there’s obviously
a problem there and you’re not gonna
want to hire them. So there’s certain things
you can give people
a free pass on, very, very simple syntax
almost like typos, like, oops, I forgot to type
the semi colon, which is very different than
I appear not to have full control over this
programming language. We tend to fluctuate
between just asking people to do the code interviews
in C, which we consider
a lingua franca that all programmers should
have learned at some point. And the truth is, C isn’t used
that often anymore, and so, if a programmer has
been working in Java and C#, or in some other programming
language a lot lately, it may be easier for them to do the interview
in that language and we’ll expect to see a certain amount of fluency
with that language ’cause that’s what
they’re presumably programming
in every single day. candidate:
Order n times m, and– David:
The second part
of the interview is the technical question
which you do using Fog Creek Co-Pilot, where we ask them
a programming question. This is where the candidate
did not do very well. The question is actually
is supposed to have two parts. He only got through
the first part. And basically, the problem
wasn’t his coding skills. It was his developing
the actual algorithm. He really struggled on that, and I had to give him
a lot of prompting to get to
an optimal algorithm. candidate:
Am I missing something
obvious? I feel like I’m missing
something obvious. No.
It’s okay. Okay, so we feel like we definitely need
to look at each character. So we have to have
at least order end. Right now,
for each character in s, we’re looking at every character
in the delimiter list. Is there anything we could do
to that delimiter list to make it so that we didn’t
have to look at every single character
in it? [candidate sighs] My recommendation for him
will be no hire because of his inability
to get to that algorithm without any prompting. So, he’ll get a nice email
from us saying, “Thank you for applying, but we can’t offer you
anything at this time.” candidate:
Instead of having a list here
as the value in a hash table, we could actually have the value
be some sort of search tree. So, for example,
for b– Tyler:
I did like his code. He was very clean and meticulous
about the way he coded things. And even though he didn’t
fully remember C Syntax and, you know,
certain function names, things like that, he made sure that everything
was nice and readable, and that he used
coding conventions that made it clear what
he was trying to accomplish so his code wouldn’t
really need comments. So it would just be obvious
what the code was doing just by reading it. So he did well with that. And he did a good job of talking through
what he was thinking even if he went down
the wrong path
every now and then. ♪♪ [Electronic Music] Joe:
I’ve always been
interested in computers. When I was probably
five or six years old, we first got a computer
in our house. I thought
it was really cool. In college,
I guess I turned to it because I just
couldn’t stand anymore of the miscellaneous
social sciences, and I realized
I just needed something that I could work towards
as a very concrete goal. And computer science
really offered that. I had a really crappy
programming job working for one of
the university departments whose job is mostly
to perpetuate itself. And supposedly,
I was doing research into, like,
academic computing. I mean, I don’t really
even know what that is. I don’t think
anybody does. But I was just bored
and surfing the web one day and I found And that was that. And not long after, that was
probably in April or May, and not long after that,
I was pretty sure that I was gonna apply
for that internship, so I did. I had two phone interviews, each one of which
I thought I bombed, but then they had me
come out to New York for a day. And I basically just talked until I was blue in
the face, from like 10 AM
until about 6:30 PM. Joel:
I would recommend doing
at least five interviews before you actually
hire somebody, and leave the last interview
for a very, very senior manager who can make the final call, or basically,
sell the candidate if everybody else
is already sold on them. Hey, Joseph? Joseph:
Yes, nice to meet you. Come on in.
Have a seat.
Thank you. Sorry that we’ve been
going really long today. It’s just a crazy day,
I guess, I don’t know, our interviews
tend to go on for a while. Well, I mean,
I’m here in New York
for no other reason, so I guess it’s okay. How’s it going so far? It’s been fine. Some things better
than others, I think. I mean, I’ve done
as well as I can. What can I say? Okay. What’s your favorite programming language? My favorite
programming language? Yeah. That’s not a good question, but why not? What’s the programming language,
that if I told you right now, here, let’s do a test– I really believe in using
the right tool. Okay. So yeah,
give me a scenario. Here’s the problem.
Okay. The problem is
that I’ve got this function. Tell me if you’ve
ever heard this one, and stop me if you have, because I don’t want you
getting bored.
Sure. But I’ve got this,
I need to simulate
a seven-sided die. Okay.
You can throw it. It can give you
a number from, I’m gonna make everything
really easy for you, a number between
zero and six. Okay.
Which is easier than
if I said one to seven. And it’s got to be
an integer. So, I need you to give me whatever programming language
you’d choose. I’m gonna call it
rand seven, and it can return zero to six
with equal probability. Okay? Okay.
And, you have a random
number generator and it’s really,
really good. And it’s called rand 5, and it returns the number between zero and four with equal probability,
20 percent chance of each one. Okay.
And you need to
use this function to implement your function,
rand 7. Okay.
Does that make sense? Yeah, sure.
So, spend a little time,
think about your strategy first before you start,
because you want to make sure that you have an algorithm
that’s gonna do the right thing before you even start
implementing it. Right. Okay.
Well, my initial reaction is, we multiply rand 5
by some number and then we take
that and mod 7. Okay.
But we want it
to be a number that has some relative
primeness going on to ensure
an even distribution or to rather,
to ensure the same distribution that we get from rand 5,
which is totally random. Right. It’s very hard
for an interviewer
to try to decide whether or not
the person they’re interviewing is smart or not. The needle barely moves
in the course of that hour. It’s really,
really hard to tell. It’s very, very important, there’s all kinds of things
I tell people when you’re doing
interviews. Number one, don’t ask
the interviewee a question that you know the answer to. Or, don’t ask them
to solve a problem that you just solved
the day before, because
in both of those cases, you’re gonna have an incredible
bias towards the interviewee, the candidate who gives
the same answer as you gave, or the candidate
who gives the same answer
as you came up with, or the candidate
who gives the answer
you were looking for. And that’s not really
what you’re looking for. You’re looking for
smart candidates, not identical candidates
to you. And so,
you may be brilliant, but they may be brilliant
in a different way. So, it’s better to come up
with questions that are not something that
you’ve ever worked on before. So we need to add it in order to even begin to
gain more possibilities. That’s just one way
we can begin to gain more possibilities
from rand 5. Or, you can add to it but that doesn’t have
anything you have to–
No. But I mean,
we can add to– can we only add
to rand 5 once? Oh, no. Oh, right.
Okay. So we can add two results
of rand 5 together. Okay.
And then we get
some random number between
zero and eight. Cool.
With what distribution? With an even distri– [laughs]
Feel free to– Can I write
on something? Yeah.
That’s what this is for. Go ahead.
Write on the board. What are
the possibilities? Okay. So 0 plus 4, 0 plus 4–
So– Let me ask you
a quick question. Sure.
If you have two dice,
one six. How many different ways
can you roll them and get two? How many ways?
One. There’s only one way
to get two.
But no, I– How many ways in all
are there to get seven? That’s the, like,
one sixth of your rolls
will get seven– Well, more, right,
’cause you could roll
a one and a six. You could roll
a two and a five. You could roll
a three and a four. You could roll
a four and a three. You could roll– Which is exactly
one sixth of your rolls. Yeah. So there are more different ways to get
Yes. So it goes like this. Yes. So the minute
you start just adding– [indistinct] That’s almost
the definition of normal. Yeah. So, normal
is what happens when you have a bunch
of [indistinct]. But we want rand 7
to be evenly distributed, so that’s a good start,
but not exactly. Okay. Hmm. It’s also good to keep asking
the same question to all the candidates
that come by, and pretty soon, you’ll be able
to calibrate that question. If you’ve got a question
that you ask everybody, after about the third
or fourth person that you’ve asked
this question, you start to know
what to look for, and you start to get
a real good feel for whether they’re answering
quickly or slowly, and whether they’re doing
a good job or not with that particular
question. Also, one more time, remember that the goal
in interviewing somebody is to decide
if they’re smart, and if
they get things done. And, to do so, you may
happen to give them a problem and they may or may not
solve that problem, but the problem
is just an excuse to have
the conservation. It’s sort of the pretext for
a conversation about programming that will let you decide
if that person is smart, and likely
to get things done. I call rand 5,
if it’s equal to 4,
call it again. Okay. Okay.
Or while it’s
equal to four. Yeah.
It might be
four several times. Yes, exactly, ’cause
it’s gonna be in a loop. And now we’ve reduced it to
a number between zero and three with equal probability. Yes.
Cool. And now we have two bits of randomness.
Right? Right. Which we can reduce to
one bit of randomness. Oh, I can reduce it
to one bit of randomness
even easier if the number
is not zero or one. Roll again. If you get
a zero or one. Yeah, we should do that,
but then we’ll have more loops. Okay.
So, I mean, assuming we want to sort of reduce the
calls. Yeah, you’re right.
You’re right, you’re right. Tell me the algorithms
so far. Okay.
So, um– –call rand 5 while it is
equal to four. Right. Call rand 5
while it is equal to four. Okay.
So we do that twice. We do that twice. Yeah.
Store the values. Yeah. Drop the most
significant bit, like– Of one of them. Of one of them? Yeah.
Either one of them. Okay. Yeah, I was gonna
put them together and then drop
the most significant bit. Okay.
You can do–
But it doesn’t matter. How do you put them
together? What’s the operation
for that? You take one of them,
shift it over to– Yeah, cool, exactly.
Right. Okay. Yeah.
Okay, cool. So let’s write this code.
You can do it in C. You can do it
in any language you want. Okay.
If you want,
I’ll boot up Excel here and you can run it on Excel. We’ll do C.
We’ll do C. Okay.
Okay. Joel:
The only possible answers
after the interview are hire,
no hire. There’s no such thing
as strong hire. Everybody’s strong
that we want to hire. If they’re a weak hire, let’s just not just hire them, okay? If they’re a weak, no hire,
strong, no hire, doesn’t even matter. We’re not gonna hire them. So, the only two possible
answers are hire, no hire. Sometimes you get people
who want to say maybe, or I don’t know,
and we don’t allow that. If you’re about to say maybe, just say no hire,
because, why bother? The basic rule is
it’s much, much easier to interview 10 people
and find somebody good, than to hire 10 people
and have to fire nine of them. In other words,
the cost of interviewing is much lower than the cost
of trying to get rid of somebody that you hired by mistake. Are there any bugs there? Yes. Okay. Now I’ve got a computer
set up for you. I believe
it’s on the Internet. What I want you to do is, using all the resources
at your disposal–
Yeah. –do a little bit of testing
and prove to me that this code actually
does evenly distribute. We have to reject
a lot of good candidates just because we
weren’t absolutely certain
that they were good. But that’s
a small price to pay rather than the price of
having a whole bunch of people messing up your code. It’s just not worth it. I think the reason I really
wanted to work at Fog Creek was just that they have
a reputation of being such a great place
to work for. You know, I felt like I couldn’t
really go that far wrong. And that it would be
a great experience. I would get to work
on a lot of things,
and shipping products. In the end, they said,
“Well, do you want to work
for us, you know?” And then I said,
“Yeah, that’d be great.” ♪♪ [Calm Music] Nahir:
I go to the University of Waterloo in Waterloo,
Canada, and we’re known to have
the largest co-op program
in the world. And what happens is
every four months, you switch between
being in school to being on a paid internship
or a co-op. I was just searching
through the jobs as we have, always looking to see
which company will hire, and I saw Fog Creek. I didn’t even read
the whole description stuff. I’d already known,
I’d done a bit of research
for my first term and I was like,
I want to work there, instantly. Braden:
There was a group session. Or, there was
a phone call originally. It was
a one-hour phone call. It’s a preliminary screen,
then a group session for everyone who had made it
through the phone call, and that same day, there were
two one-hour interviews with two of the developers
from Fog Creek, and then, a week
or 10 days later, Joel came to interview
the last few candidates. So that was a total of
five hours of interview time. That was the most
I had from anybody. Normally, a company
will only do one interview, maybe it’s 15, 20 minutes,
something like that. Fog Creek did two interviews
that day, one after another. Each one was an hour long,
and they were real interviews. They weren’t asking any of
the really annoying questions, which we all know
what they are. So, like, what do you say
your best strengths are? What are your weaknesses,
those type of questions, like, these aren’t
actual real questions. You can’t test
someone’s ability on that. So I was really,
that was one thing
which I loved, where the interview itself was actually enjoyable,
which was nice. I was given
a real problem, and they sat there
and helped me through it if I had any questions
or anything, but the whole thing
about the interview was to see how I went through
problem solving, and I felt that was much more
engaging and, honestly, if you’re still asking
those other type of questions, like, you’re not finding out
anything about your interviewees and you really should be asking those type of
questions. David:
When I came to interview, I actually remember
being surprised by how not nerdy the people
I interviewed with actually acted and looked. And I think
that that struck me not just because I want to work
with cool people who, you know,
are good looking, but because the people
that work here are not sort of the socially
inept nerd stereotype. But they’re actually people who can interact
with other people, and that’s important
at a software company because they need to be able
to work together on a team, and not just be sort of
the stereotypical solo hacker who goes off and locks themselves in an office for months on end, and then comes out
with some piece of code that nobody can ever understand,
but, instead, at Fog Creek, I found that
the software developers
were very social and able to discuss ideas
with one another, able to have
intelligent conversations, and really function together
as a team. I came in
and started answering questions about recursion and hypothetical
programming languages at 7 AM West Coast time. And, you know,
I’m not exactly a morning guy, so that was a challenge,
but I did it. Also it really helped that,
you know, the people are so nice here, and they just have
the interview process down pat. Like I met Ben
in the morning, and he was very welcoming
and very relaxed, and it kind of made
the process of, you know, answering hard theoretical
programming language questions, you know, kind of
painless and fun. My first interview
was with Brett who has a, Brett’s a great interviewer,
but he’s just stone-faced. You start to get
a little bit stuck and he just, boom,
there’s just nothing. And so, he asked me
for an example about, I think he asked me
about an interface that I would change
in some software. And for some reason,
I just was just like, phew, gone,
everything was gone. And I’m sitting there,
and I’m starting to sweat, and I’m sort of,
kind of hoping that he’s gonna throw me
this lifeline. It’s not happening. Not happening,
and I’m sitting there going, “Oh, my God. I look like such a complete
moron right now.” And I finally had to
sort of rescue myself and came up with some example,
and it worked out just fine. But in the midst
of that interview, I’m sitting there going,
“That’s it. I mean, this was a nice trip
to New York. I might as well just
pack my stuff and head home ’cause that’s gonna be
the end of it. I mean, I just got dinged
right there.” And as it turned out,
I did all right, in spite of my feeling
like I was sucking down
gallons of water in the middle
of that interview. So that was sort of
interesting. I mean, I thought
I was just absolutely done. There was a professor
at Yale University, Stanley Eisenstat, who teaches a course called Systems Programming, and it’s considered sort of
the weed-out sophomore course in Computer Science. He gives his students a lot
of programming assignments. I think,
just about every week, there’s a pretty major
programming assignment
to be done. And the programming assignments,
just to give you an idea, are things like, write
a command line shell for Unix, write a Macro Expander, write a compressor using
Ziv-Lempel-Welch Compression. And each of these assignments,
he gives them every year, and he gets a whole new batch
of CS students that come in and have to work
on these problems. They’re all done in C. And the students started
complaining after a while that this course was just
taking way too much time, and a lot of students went to
the University Administration and said, “You know,
for Eisenstat’s class, I have to spend like
40 hours a week just on the homework
assignments, and that’s way, you know,
it’s disproportional to
any other class.” And Professor Eisenstat
said to the administration, “Well, this is true
for some students, but other students seem to be
able to do these problems in a lot less time.” And the administration
said to him, “Well, prove it.” And so, he started asking
the students to keep a log of how much time they spent
on each assignment. And so, the students,
when they do the assignments, are also required
to tell him how many hours they spent
on that assignment, on that particular
programming assignment. And the data set
that he got is extremely interesting
’cause what he has here is a bunch of students, roughly, they’re all
Yale University students, so they’re all
very smart. Right? And they’re already
sort of preselected, and they’re all doing the same
programming assignments. There’s like, literally,
there may be 30 of them one year all writing the same
Ziv-Lempel-Welch Compression algorithm. And, some of them do it
in four hours, and some of them do it
in 40 hours. And I took a look at his data;
I did some analysis of it. And one of the interesting
things that I found is that there is
no correlation between the amount of time
they spend on a project and the grade
that they get. The grade on the project
is also completely objective. It’s done by a computer program
that runs and tries a bunch of different inputs,
and checks the outputs, and gives you a completely
objective grade. So there’s no human intervention
in what grade you get. And yet, there is no correlation
between the quality of the code and how long you spent
working on it. And when you think about it, that says something
really interesting. It says that even among
smart programmers who are able to complete
a given amount of work, the amount of time
it takes them to do it can vary
by an order of 10. And that’s pretty extreme. The programmers
that I want to hire are the ones that take
maybe a tenth of the time rather than the ones that take
10 times as much time. ♪♪ [Opera Music] Think of the iPod. The iPod
has a little touch wheel that you turn
to change the volume. And when you turn
the touch wheel, you hear a little
clicking sound which gives you
the confidence. It sort of gives you
some feedback that that clicking
is actually, that you’re actually
turning the wheel. Apple went, kind of went
the extra distance that they provided
that clicking, and instead of just playing it
through the earphones, which you have plugged in,
’cause it’s an iPod, they’ve actually put an extra
speaker in that little iPod that does the clicking sound
for you. And they’ve gone through
this huge extent because they want
that smooth feel to feel clicky. They want that wheel,
that when you’re touching
that smooth wheel, they want it
to feel clicky. And they’ve gone to these
kind of great lengths, these great extremes,
that make the iPod, like, truly a great
design product. You want to hire programmers
that can reach the high notes, that can do the really
excellent achievements, and that come up with
sort of great ideas, that come up
with great designs, that maybe
the average programmers would never come up with
in a million years. Joe:
I finished school
a couple days ago and I’ve been driving for about
16 hours out of Chicago. It should have taken me
like 10 or 11, but I hit a terrible,
terrible storm all the way through Pennsylvania
and New Jersey. So it’s taken me a little longer
than I expected. But anyway,
now I’m here, and soon enough, I guess,
I’ll be in Brooklyn, and I’ll be able to
unload my car full of stuff
for the summer. I’m really looking forward
to building just real good usable software
that fills a niche and that normal people
actually use, and it’s a really high quality polished product. And I’m also really
looking forward to a place where all my distractions
are taken care of, you know, I mean, apparently
they have a kitchen, lunch, whatever food you need,
you know. I’ll just be like
a happy little monkey with as many bananas
as he could possibly eat. It’ll be fantastic. [Energetic Music]

, ,

Post navigation

3 thoughts on “Make Better Software: The Training Series – Module 1: Recruiting

Leave a Reply

Your email address will not be published. Required fields are marked *