This link has been bookmarked by 241 people . It was first bookmarked on 02 Jul 2006, by Russ.
-
23 Oct 15
-
01 Oct 14
-
28 Jun 14
-
good programmers have a habit of writing their { and then skipping down to the bottom of the page and writing their }s right away
-
short variable names for loop indices
-
putting the constant on the left hand side of the ==
-
-
13 Feb 14
-
08 Nov 13
-
They just don't understand anything any more. 90% of the class goes off and becomes PoliSci majors, then they tell their friends that there weren't enough good looking members of the appropriate sex in their CompSci classes, that's why they switched.
-
-
12 Oct 13
-
25 Jul 13
-
30 Apr 13
-
17 Jan 13
-
11 Jan 13
-
30 Nov 12
-
24 Nov 12
-
04 Nov 12
-
12 Oct 12
-
. Our goal is to hire people with aptitude, not a particular skill set. Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it's better to hire people that are going to be able to learn any new technology rather than people who happen to know SQL programming right this minute.
-
. Even if they are passionately negative, this can be just as good a sign
-
A good answer to this might be "I got together with the other members of the team and wrote a proposal..."
-
The important thing is that they leapt into the question enthusiastically.
-
You don't want to give them any problems that take more than about 5 lines of code; you won't have time for that.
-
his is an aptitude thing, not a skill thing – it requires a complex form of doubly-indirected thinking that some people just can't do.
-
According to Jabe, he's had candidates who would go up to the whiteboard and immediately draw a square. A square! These were immediate No Hires. In design questions, what are you looking for?
-
I will not hire someone who leaps into the design without asking more about who it's for.
-
If the conversation ever starts going around in circles, and the candidate says something like "well, we can talk about this all day, but we've got to do something, so let's go with decision X" that's a really good sign.
-
-
22 Aug 12
-
25 Jul 12
carlos puentesHiring the right people is extremely crucial to Fog Creek Software. In our field, there are three types of people. At one end of the scale, there are the unwashed masses, lacking even the most basic skills for this job. They are easy to ferret out and eliminate, often just by reviewing a resume and asking two or three quick questions. At the other extreme, are the brilliant superstars who write lisp compilers for fun, in a weekend, in Assembler for the Palm Pilot. And in the middle, you have a large number of "maybes" who seem like they might just be able to contribute something. The trick is telling the difference between the superstars and the maybes, because at Fog Creek Software we only hire the superstars. Here are some techniques for doing that.
interviewing interview programming Career hiring job management software
-
26 May 12
-
23 May 12
-
01 May 12
-
12 Apr 12
-
13 Mar 12
-
06 Mar 12
-
20 Feb 12
-
18 Dec 11
-
05 Dec 11
-
22 Oct 11
-
29 Sep 11
-
23 Sep 11
-
13 Sep 11
-
07 Sep 11
-
04 Sep 11
Naoj GiorReverse a string in place
Reverse a linked list
Count all the bits that are on in a byte
Binary search
Find the longest run in a string
atoi
itoa (great, because they have to use a stack or strrev)interviewing interview programming hiring Career management job software
-
01 Sep 11
-
24 Aug 11
-
07 Aug 11
-
13 Jun 11
-
26 May 11
-
19 Apr 11
-
18 Apr 11
-
14 Apr 11
-
11 Mar 11
Matt HoweThis was so creative it surprised me -- in dozens of interviews, I had never heard that answer. And it really took a major creative "leap" outside of the bounds of the problem. On the strength of that answe
-
03 Mar 11
-
31 Jan 11
-
28 Jan 11
-
15 Dec 10
-
28 Oct 10
-
30 Sep 10
-
14 Sep 10
-
13 Sep 10
-
29 Aug 10
-
21 Aug 10
-
18 Aug 10
-
07 Aug 10
-
05 Aug 10
-
First of all, the #1 cardinal criteria for getting hired at Fog Creek:
Smart, and
Gets Things Done. -
The most important rule about interviewing:
Make A Decision
At the conclusion of the interview, you have to be ready to make a sharp decision about the candidate. There are only two possible outcomes to this decision: Hire or No Hire.
-
Never say "Maybe, I can't tell." If you can't tell, that means No Hire. It's really easier than you'd think. Can't tell? Just say no! Similarly, if you are on the fence, that means No Hire. Never say, "Well, Hire, I guess, but I'm a little bit concerned about..." That's a No Hire as well.
-
An important thing to remember about interviewing is this: it is much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs. If you have any doubts whatsoever, No Hire.
-
- Introduction
- Question about recent project candidate worked on
- Impossible Question
- C Function
- Are you satisfied?
- Design Question
- The Challenge
- Do you have any questions?
-
The Introduction phase of the interview is intended to put the candidate at ease. I spend about 30 seconds telling the person who I am and how the interview will work. I always reassure the candidate that we are interested in how he goes about solving problems, not the actual answer. By the way, in doing the interview, you should make sure that you are not sitting across a desk from the candidate. This creates a formal barrier which will not place the candidate at ease. It is better to move the desk against a wall, or to go around and sit on the other side of the desk with the candidate; this does help put the candidate at ease. This results in a better interview because it is less distorted by nervousness.
-
Part 2 is a question about some recent project that the candidate worked on. For interviewing college kids, ask them about their senior thesis, if they had one, or about a course they took that involved a long project that they really enjoyed. For example, sometimes I will ask, "what class did you take last semester that you liked the most? It doesn't have to be computer-related."
-
In this question, I'm looking for one thing: passion. When you find a project that the person worked on recently, these are all good signs:
-
They get very excited talking about it; they tend to talk more quickly and get animated. This shows that when they are interesting in something, they will be passionate about it.
-
A really good sign that a candidate is passionate about something is that when they are talking about it, they will forget for a moment that they are in an interview
-
Remember, Smart and Gets Things Done. A good way to tell if somebody Gets Things Done is to see if historically they have tended to get things done in the past. In fact, you can even ask them directly to give you an example from their recent past when they took a leadership role and got something done -- overcame some institutional inertia, for example.
-
For some reason most people seem to be born without the part of the brain that understands pointers. This is an aptitude thing, not a skill thing – it requires a complex form of doubly-indirected thinking that some people just can't do.
-
- Always reassure them that you understand that it's hard to write code without an editor, and you will forgive them if their paper gets really messy. Also you understand that it's hard to write bug-free code without a compiler, and you will take that into account.
When you watch somebody write code, here are some techniques that may be helpful:
-
Some signs of a good programmer: good programmers have a habit of writing their { and then skipping down to the bottom of the page and writing their }s right away, then filling in the blank later. They also tend to have some kind of a variable naming convention, primitive though it may be...
-
if (0==strlen(x)), putting the constant on the left hand side of the == . This is a really good sign.
-
Finally, you should ask the candidate if they have any questions. Some people like to look to see if the candidate will ask intelligent questions, which is a standard technique in the interviewing books. Personally, I don't care what questions they ask; by this point I've already made my decision. The trouble is, candidates have to see about 5-6 people in one day, and it's hard for them to ask 5-6 people different, brilliant questions, so if they don't have any questions, fine.
-
I always, always leave about 5 minutes a the end of the interview to sell Fog Creek. This is very important even if you are not going to hire them. If you've been lucky enough to find a really good candidate, you want to do everything you can at this point to make sure that they want to come to Fog Creek. Even if they are a bad candidate, you want to get them excited about Fog Creek Software so that they go away with a positive impression of the company. Think of it this way: these people are not just potential hires; they are also customers. They are also salesmen for our recruiting effort: if they think that Fog Creek is a great place to work, they will encourage their friends to apply.
-
Interviewing is more of an art than a science, but if you remember the Smart/Gets Thing Done principle you will be in good shape. When you get a chance, ask some of your co-workers what their favorite questions are and what kinds of answers they look for. In the Building 16 cafeteria in Redmond this is a perennial favorite topic of lunchtime conversation.
-
-
26 Jul 10
-
These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts
-
In this question, I'm looking for one thing: passion
-
They get very excited talking about it
-
A really good sign that a candidate is passionate about something is that when they are talking about it, they will forget for a moment that they are in an interview
-
Good. I like passionate people who really care.
-
I have rejected candidates because when they talked about their previous project, they couldn't explain it in terms that a normal person could understand
-
If the project was a team project, look for signs that they took a leadership role. A candidate might say: "we were working on X, but the boss said Y and the client said Z." I'll ask, "so what did you do?" A good answer to this might be "I got together with the other members of the team and wrote a proposal..." A bad answer might be, "Well, there was nothing I could do. It was an impossible situation."
-
OK, the third thing on that list is the impossible question. This is fun.
-
The important thing is that they leapt into the question enthusiastically
-
Not-so-smart candidates will get flustered and upset
-
- Reverse a string in place
- Reverse a linked list
- Count all the bits that are on in a byte
- Binary search
- Find the longest run in a string
- atoi
- itoa (great, because they have to use a stack or strrev)
-
Is their function fast
-
Do they use pointer arithmetic? This is a good sign
-
ou can see how well they learned the bitwise operators in C
-
Brilliant candidates might even suggest a caching scheme
-
Really, really brilliant candidates will try to devise a way to compute the table using some kind of a shortcut taking advantage of the patterns that occu
-
Always reassure them that you understand that it's hard to write code without an editor, and you will forgive them if their paper gets really messy. Also you understand that it's hard to write bug-free code without a compiler, and you will take that into account.
-
good programmers have a habit of writing their { and then skipping down to the bottom of the page and writing their }s right away,
-
putting the constant on the left hand side of the == . This is a really good sign.
-
good candidates will always make a little drawing on the side and draw all the pointers and where they go.
-
Are you satisfied with that code? You may want to ask, "OK, so where's the bug?" The quintessential Open Ended Question From Hell.
-
When you say, "There's a bug in that code," they will review their code carefully, and then you get to see if they can be diplomatic yet firm in asserting that the code is perfect
-
According to Jabe, he's had candidates who would go up to the whiteboard and immediately draw a square. A square! These were immediate No Hires.
-
Good candidates will try to get more information out of you about the problem
-
Who is the house for? As a policy, I will not hire someone who leaps into the design without asking more about who it's for.
-
Smart candidates understand that design is a difficult series of trade-offs. A great design question: design a trash can for a city street corner
-
It has to be easy to empty, but impossible to steal; it has to be easy to put things into, but hard for things to fly out of on a windy day; it has to be solid, yet inexpensive; in some cities, it has to be specially designed so that terrorists can't hide a bomb in it.
-
Think of all the trade offs!
-
I had one candidate who decided that it would be better to put the spices in a drawer, because it is more comfortable to scan Braille with your fingertips horizontal than vertical
-
Sometimes candidates will drift back and forth, unable to make a decision, or they will try to avoid hard questions. Sometimes they will leave difficult decisions unanswered and try to move on. Not good. Good candidates have a tendency to try to naturally keep things moving forward, even when you try to hold them back
-
"well, we can talk about this all day, but we've got to do something, so let's go with decision X" that's a really good sign.
-
2 minutes playing devil's advocate. Argue with them when you are sure they are right.
-
- Weak candidates will give in. No Hire.
- Strong candidates will find a way to persuade you. They will have a whole laundry list of Dale Carnegie techniques to win you over. "Perhaps I'm misunderstanding you," they will say. But they will stand their ground. Hire.
-
UT, good candidates will tend to get fairly passionate about the argument, and they may momentarily forget that they are in an interview, and they will get very involved in trying to convince you. These are the people we want to hire.
-
-
22 Jul 10
-
01 Mar 10
-
19 Feb 10
-
24 Jan 10
-
20 Jan 10
-
18 Dec 09
-
11 Dec 09
-
02 Nov 09
-
01 Oct 09
-
I spend about 30 seconds telling the person who I am and how the interview will work. I always reassure the candidate that we are interested in how he goes about solving problems, not the actual answer.
-
For interviewing college kids, ask them about their senior thesis, if they had one, or about a course they took that involved a long project that they really enjoyed.
-
I'm looking for one thing: passion.
-
They are careful to explain things.
-
-
16 Sep 09
-
05 Aug 09
-
27 Jun 09
-
30 May 09
-
28 Apr 09
-
- Reverse a string in place
- Reverse a linked list
- Count all the bits that are on in a byte
- Binary search
- Find the longest run in a string
- atoi
- itoa (great, because they have to use a stack or strrev)
-
putting the constant on the left hand side of the == . This is a really good sign. It means that they were stung once too many times by confusing = and == and have forced themselves to learn a new habit to avoid that trap
-
null-terminate the new string
-
off-by-one
-
0 length
-
GPF if malloc fails
-
more information
-
Who is the house for
-
design is a difficult series of trade-offs
-
well, we can talk about this all day, but we've got to do something, so let's go with decision X
-
intelligent questions
-
-
02 Apr 09
-
01 Apr 09
-
17 Mar 09
-
18 Feb 09
-
10 Dec 08
-
27 Nov 08
-
19 Sep 08
-
11 Aug 08
-
19 Jun 08
-
26 May 08
-
12 May 08
-
22 Mar 08
-
28 Feb 08
-
15 Feb 08
-
04 Dec 07
-
24 Oct 07
-
26 Sep 07
-
10 Sep 07
-
06 Sep 07
-
26 Jun 07
-
05 Apr 07
-
17 Feb 07
-
31 Jan 07
-
29 Jan 07
-
28 Jan 07
-
04 Jan 07
-
30 Nov 06
-
13 Nov 06
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.