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.
The goal is to regularly provide proof to both your professional network and to selected potential employers that you are highly competent and will be a decided advantage to their organization.
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.
As a small company owner I want to completely endorse this comment. These "proofs" of a developers skills and technical interest are the hard requirements I have before conducting any interview. Naturally the "social proof" is also important but less common and more difficult to attain.
Even tiny personal projects demonstrating ones interest in keeping up with newer hot technologies like node, redis, backbone, etc mean a lot.
tl;dr Having a set of quality personal projects (github, live, whatever) is absolutely critical.
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.
Coming from a pure math background, I find CLRS to be very easy to read. YMMV based on prior experience, but it's not at all unreasonable to learn the basics in a week or two if you're studying it full-time.
I'm not talking about "picking up the basics". I doubt that level of knowledge will get you a job offer from Google.
I'm extremely skeptical about your claim. Just reading through the chapters will take the better part of a day. Working through the exercises and thinking about what each of these algorithms will take much longer.
For reference, MIT has two undergrad courses - 6.006 and 6.046 - which use CLRS, covering about half the book each. An undergrad course at MIT is expected to take up about 140 hours, including lectures, reading, and assignments. So, working for 10 hours per day, one could theoretically complete each course in two weeks.
There are a few other things to consider. One is that it's probably not necessary to go through all of the material to be able to manage interview-type questions. (It would obviously be best to undertand CLRS from cover to cover for the purpose of becoming a better engineer, but that's not what's under discussion.)
Second, it's really questionable whether someone can effectively work for 10 hours per day on this sort of material. My guess is that people fall into two categories - those who are not used to algorithmic thinking, and those who are. People from the first category would not be able to absorb that much new information that quickly, so for them, what I said is inaccurate. However, people in the second category would not only be able to process CLRS in large batches, but would need much less than 140 hours to work through half the book; someone familiar with the underlying concepts (basic programming, probability, etc.) and with a background in proofwriting could very well get through enough information to answer interview questions twice as fast or faster, so in about a week or less.
I don't doubt your claims about the amount of the work the two courses at MIT require. However, you're forgetting that for some of those 140 hours you're being lectured by the top professors in the area. You're unlikely to have a question that they can't answer. Other parts of those 140 hours are spent talking with some of the smartest students on the planet. Some more of those 140 hours are spent solving problems carefully designed to maximize understanding. If you can't figure something out, you have fellow students, TAs and professors to harass. Somebody studying alone at home doesn't have this environment.
And then you need to take into account the fact that if you're undergrad at MIT you're already smarter than 95% or so of the population. Basically, the takeaway here is that your 70/140 hour number applies to something like 0.1% of the population under the assumption that they're studying CLRS at home.
You need to see this in context. This is advice for CS undergrads looking for jobs. This advice is being given out on reddit. Anybody who needs this advice (and CS undergrads from MIT certainly don't) will not be able to work through CLRS in a week.
You could learn it well enough to answer interview questions on it. I have my copy of CLRS here and none of the first 15 chapters are exceptionally dense.
Sure. If the questions are stuff like define O(n) notation, you can. I suspect any company worth working for will ask you a bit more than that, though.
Placing a particularly high value on undergraduate-level CS theory as a pre-employment hurdle provides a market advantage to people with fresh undergraduate training.
This coincidentally depresses the marketability (for a certain class of job) of older workers and demographics less likely to achieve a degree from a top N computer science program.
Certainly you could read between the lines and say that observably favoring e.g. Stanford 2012 CS majors effectively disadvantages some protected minorities (age, gender, race). By placing the emphasis on a particular credential rather than on demographics a hiring company gets a level of plausible deniability from such claims.
Disclaimer: I have an MSci in CS and I'm only 30, so I'm not too worried about the things implied above. Yet.
Another explanation is that is it very difficult to gauge someone's programming ability from a technical interview. Asking theory questions is a useful (albeit imperfect) proxy.
This coincidentally depresses the marketability (for a certain class of job) of older workers and demographics less likely to achieve a degree from a top N computer science program.
If those older workers and others are equally or more skilled than the younger ones implied by your question, smart companies will realize the discrepancy and hire them.
In addition, if older workers know that firms place a "high value on undergraduate-level CS theory," they should probably spend some time learning. . . undergraduate-level CS theory.
If those older workers and others are equally or more skilled than the younger ones implied by your question, smart companies will realize the discrepancy and hire them.
The invisible hand of self-interest only works if smarter contenders actually appear in the marketplace. If there is some invisible hand of stupidity (and groupthink) that affects all companies above a certain size, then we are hosed.
Why is it that all big organizations are almost universally dilbertesque? There must be some anti-nootropic effect that occurs above a certain threshold of organizational complexity.
My guess is that he subscribes to the theory that companies use questions that would normally be taught in college to filter out older applicants. Ie, some assume that time since college isa major factor in people knowing these answers.
Personally, I find it terribly unlikely that any such filtering is intentional on any level.
There are several operational benefits to fresh graduates from the perspective of the hiring organization:
- What little experience they have is effectively all relevant to the job and hence easier to justify paying for. If a neophyte can do 80% of a veteran's work for 50% of the pay, it's a tempting tradeoff. A software veteran's second decade of experience may not be worth the increased sticker price if you're asking them to perform low- and mid-level tasks.
- They are less likely to have personal entanglements (kids, family, medical).
- They are an easily appraised and substituted commodity: standard salary scales apply.
- They are less likely to know their market value and hence less likely to negotiate for increased compensation or time off.
That is simply... depressing, not to mention unwise.
The neophyte may be able to do 80% of the veteran's job, but that's the easily-replaceable 80%. If I'm hiring for a position that requires experience, I know that the last 20% is worth paying for. Someone is going to have to do that 20% and if it's not the new hire, then why are we hiring him?
Personal entanglements? I have never had any idea about the family status of anyone I've hired unless they were wearing a wedding ring. I don't need to know and I'm certainly not going to open the firm up to a lawsuit by asking. HR is the only one who will know, and HR does not get to veto what the software dev. interviewers say unless the candidate wants more $$ than the position offers. And even then, they'll come back to us and ask if we think he's worth it.
Compensation? Again, the interviewers don't care or know. And really does any company with half a brain care? If you're being hired, it's because we expect that you will make the company orders of magnitude more than we pay you. In that light, trying to push for the maximum salary in the pay band is really not a big deal. It's in the budget after all.
> If I'm hiring for a position that requires experience, I know that the last 20% is worth paying for. Someone is going to have to do that 20% and if it's not the new hire, then why are we hiring him?
Sadly, not everyone shares your view. Many seem to forget about that last 20% and just focus on the 50% savings. I've seen it happen to more than one senior dev...
You're right, of course. I was merely attempting to provide a devil's advocate's view. Perhaps I should have said "rationalizations" rather than "benefits".
My understanding is that according to US labor law, computer programming is not one of the limited group of employment positions for which a degree is (or can be) required. That is, coders can't be required to have a degree, so HR designs questions that are most likely to only be answerable with university-style training.
Do you have a citation for this? I can't imagine that it could ever be the case. The employer can set whatever job requirements they want as long as they do not discriminate against protected classes. Non-degree holders are not a protected class.
I'm far from an expert, but I have had to take classes in Employment Law and interviewing practices. This is not the kind of thing they would forget to mention!
I think he might be suggesting that with hiring coders-in-general, it's not necessary that the employer must only hire degree-holders. This is in contrast to hiring an elementary school teacher, where by law the applicant must possess credentials x/y/z even if the school thinks the applicant is fine without those.
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.
- 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 tree
"
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.
