If you want a job in software development - do software development. There is no substitute for coding. I interviewed with Google a little while ago and the first thing they asked me was "How many hours do you code a day?". That set the tone for the rest of the interview. CLRS has some very useful information and by all means, every developer should know it, but using that theory in practice is what makes the knowledge stick. You find out more idiosyncrasies and sticking points when you actually build something. If you don't know where to start, fork a project from github and contribute to it.
Amen. If you want a job playing basketball, you ought to watch a lot of video of great players. You ought to read a lot of books about training, techniques, and strategy. You ought to hang out with other basketball players and exchange tips. You ought to cross-train by lifting weights and running.
But all of that is secondary to playing a lot of basketball.
Most of the questions and answers seem aimed at college seniors planning for Google-style Big O cross examination.
For experienced developers it's a bit simpler: build a portfolio, craft a cashflow-oriented elevator pitch, build a network, and plan ahead for a bit of buzzword compliance in your desired niche as needed.
This seems... really simple. Basic algorithms, data structures, and theory that I learned in second-year comp sci.
Knowledge on these subjects is easy to pick up, taking you a few days of study at the most. Knowing this stuff doesn't mean you can program for shit (see: academic coding horror). Best to build a portfolio as dpritchett said, with a few "lessons I learned from experience when working on this project" anecdotes ready to go.
That's just personal experience though, and I competed in the ICPC during my university career so I never worry about the problem solving questions.
I recently interviewed a master's student for a job at our company. I asked him a very traditional question, and then was going to follow up on it with increasingly more difficult questions to see how deep his knowledge was. I wasn't out to "get" him at all, I hate interviewers that ask super-hard questions, I'm more interested in having a good conversation with the person to try to get a feel for what they really know, not just what they've memorized.
My question was easy: how would you iterate through a binary search tree.
He immediately asked me "should I do it recursively, or iteratively? Can I use a stack if I do it iteratively?" It was obvious he had studied for this question, and he banged out a solution in 2 mins. Iterating through a binary tree is a bit tricky if you've never done it before, and I wasn't even going to ask him this, but since he brought it up, I knew he knew the answer. The fact he could come to an answer immediately only indicated to me that he had memorized the answer and was essentially gaming the system.
So I asked him an even simpler question: Given a binary search tree, write code to find a particular value. If you can't find the value, then return me the next smallest value. For example, if the tree contains 1, 2, 3, and 5, and I ask for 4, then return 3.
He couldn't answer this, even though it's easier than the previous question. He had no clue how to solve it, and even worse, he couldn't recognize the simple bugs in the code, and the fact that he was dereferencing NULL pointers, etc. So I passed on him.
Personally, I think the best way to advertise for a job is to have a portfolio of code, as dpritchett says. I'm tired of testing people on whiteboards, and seeing if they can memorize solutions to every single program on glassdoor.com. I'd rather just have them point to a github repository, so that I can see their coding style, and see if they can produce quality code. Having an indepth conversation about their project, and quizzing them on their code, to me, is a more real-world determination of whether or not they're a good programmer.
Then, the onsite interview would be limited to determining if their personality is a good fit for the team, instead of trying to come up with 10 different variations on "iterate through a binary tree".
So I asked him an even simpler question: Given a binary search tree, write code to find a particular value. If you can't find the value, then return me the next smallest value. For example, if the tree contains 1, 2, 3, and 5, and I ask for 4, then return 3.
Out of curiosity, what is the solution?
I would imagine something like keeping a variable of the highest found value under 4 and if you don't find 4 then you use this variable.
"
At the end of a whiteboarding interview whenever the interviewer asks "do you have any questions for me?" I'm always tempted to hand them the marker and say "Imagine you are given a binary tree with elements containing linked lists ..."
"
Have any of you guys ever done this? How did it play out?
Comments here seem to be about the importance of demonstrating competence.
While this is of course important, I feel that it's equally important to make sure you actually want to work in an organization. This means fitting in, tolerating corp BS/insanity well, being expected to tone down the cowboy ethos, and appearing productive at all times. In other words, being the oft-mentioned "team player".
I'm surprised to see information missing on source control, automated testing and automated deployment.
You'd be surprised how many blank stares you get back from candidates when you ask questions about the very fundamentals of writing maintainable code in a team.
[+] [-] akg|14 years ago|reply
[+] [-] raganwald|14 years ago|reply
But all of that is secondary to playing a lot of basketball.
[+] [-] dpritchett|14 years ago|reply
For experienced developers it's a bit simpler: build a portfolio, craft a cashflow-oriented elevator pitch, build a network, and plan ahead for a bit of buzzword compliance in your desired niche as needed.
[+] [-] throwaway122011|14 years ago|reply
[+] [-] tycho77|14 years ago|reply
Knowledge on these subjects is easy to pick up, taking you a few days of study at the most. Knowing this stuff doesn't mean you can program for shit (see: academic coding horror). Best to build a portfolio as dpritchett said, with a few "lessons I learned from experience when working on this project" anecdotes ready to go.
That's just personal experience though, and I competed in the ICPC during my university career so I never worry about the problem solving questions.
[+] [-] microarchitect|14 years ago|reply
I doubt you can pick up a solid understanding of just the first 15 or so chapters of CLRS in a few months, let alone days.
[+] [-] mahyarm|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] steve8918|14 years ago|reply
My question was easy: how would you iterate through a binary search tree.
He immediately asked me "should I do it recursively, or iteratively? Can I use a stack if I do it iteratively?" It was obvious he had studied for this question, and he banged out a solution in 2 mins. Iterating through a binary tree is a bit tricky if you've never done it before, and I wasn't even going to ask him this, but since he brought it up, I knew he knew the answer. The fact he could come to an answer immediately only indicated to me that he had memorized the answer and was essentially gaming the system.
So I asked him an even simpler question: Given a binary search tree, write code to find a particular value. If you can't find the value, then return me the next smallest value. For example, if the tree contains 1, 2, 3, and 5, and I ask for 4, then return 3.
He couldn't answer this, even though it's easier than the previous question. He had no clue how to solve it, and even worse, he couldn't recognize the simple bugs in the code, and the fact that he was dereferencing NULL pointers, etc. So I passed on him.
Personally, I think the best way to advertise for a job is to have a portfolio of code, as dpritchett says. I'm tired of testing people on whiteboards, and seeing if they can memorize solutions to every single program on glassdoor.com. I'd rather just have them point to a github repository, so that I can see their coding style, and see if they can produce quality code. Having an indepth conversation about their project, and quizzing them on their code, to me, is a more real-world determination of whether or not they're a good programmer.
Then, the onsite interview would be limited to determining if their personality is a good fit for the team, instead of trying to come up with 10 different variations on "iterate through a binary tree".
[+] [-] itmag|14 years ago|reply
Out of curiosity, what is the solution?
I would imagine something like keeping a variable of the highest found value under 4 and if you don't find 4 then you use this variable.
[+] [-] pilgrim689|14 years ago|reply
" At the end of a whiteboarding interview whenever the interviewer asks "do you have any questions for me?" I'm always tempted to hand them the marker and say "Imagine you are given a binary tree with elements containing linked lists ..." "
Have any of you guys ever done this? How did it play out?
[+] [-] mahyarm|14 years ago|reply
[+] [-] itmag|14 years ago|reply
While this is of course important, I feel that it's equally important to make sure you actually want to work in an organization. This means fitting in, tolerating corp BS/insanity well, being expected to tone down the cowboy ethos, and appearing productive at all times. In other words, being the oft-mentioned "team player".
[+] [-] rhizome|14 years ago|reply
[+] [-] xer0|14 years ago|reply
[+] [-] djb_hackernews|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] kondro|14 years ago|reply
You'd be surprised how many blank stares you get back from candidates when you ask questions about the very fundamentals of writing maintainable code in a team.
[+] [-] known|14 years ago|reply