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 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.
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".
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.
- If the node value matches, return it
- If the node value is too low:
- If possible, step right and repeat
- Otherwise, return this node value
- If the node value is too high:
- If possible, step left and repeat
- Otherwise, return the value of this node's predecessor:
- Walk up until you traverse a right link
- Return the node's value
- If you hit the root, the requested value is less than any value in the treeand the solution written out in words below, also in python (I like this one better)
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.
Some people don't know what github is and won't care, others really like live sites even if they're modest, and still others really just want to see resume bullet points about dollars saved / created. Eventually you can put all of that together, but naturally it'll help when your prospective hiring manager has the same ideals you're demonstrating with your portfolio.
Portfolios are secondary to name recognition and social proof. Let me reemphasize that sharing your goodwill, your skills, and your successes with your professional network is probably more valuable than anything else you can do - develop a local or national reputation as a top gun and work will come to you as long as you keep your connections warm.
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".
But all of that is secondary to playing a lot of basketball.
" 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?
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.