"I figured getting a job at Stack Exchange is at least as difficult at getting a job at Google (to which I did not apply, because I thought I wasn't smart enough)"
As a Google engineer who has spent lots of time interviewing and recruiting, this is an attitude that potential candidates need to get over. Google's a software company that will ask you software questions during the interview. There's no magic aptitude test. There are no riddles. Just read Steve Yegge's great blog post on interview preparation and apply! (http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...). If you can code and solve problems, you might get hired.
As someone who can code well but has never taken a formal data structures/algorithms course, I have so far assumed that I wouldn't be able to pass a Google interview which, from what I've heard, tend to be pretty algorithm-focused. (Once I get around to taking an algorithms course, this will change, of course.) Do you think I'm wrong in that assumption?
Note that I do not work for Google and have never even applied. I have no knowledge of their interviewing process and can only speak to my own experiences and prejudices.
I can't say that you wouldn't pass a Google interview, but right now, you likely wouldn't pass an interview I gave without knowledge of data structures. Algorithms are problem-specific, but data structures (arrays/lists, trees, hashtables, graphs) are universal. If you get your data structured properly, in many cases it's of trivial importance which algorithm you use to operate on that data. I don't care about big-O performance beyond a back-of-the-envelope calculation. I don't care about someone knowing the ins-and-outs of A* search, but I do care if they've never heard of a graph. I care very much if I'm going to have to explain to you the difference between a hashtable and a list (as I did on Friday to one of our front-end engineers who thought he'd do some work on our API...).It's not a difficult gap in knowledge to fill, but it's an important one.
OK, definitely agreed. I honestly could not tell you about the different kinds of tree structures, but of course I know the difference between a list, linked list, tree, graph, (hash)map, and so on.
I find it hard to believe that someone could even competently do front-end work without some level of understanding of this. Last week I came across an issue where performance for $(".foo") selectors was problematic in IE<=8, which don't have a native document.getElementsByClassName() so jquery had to search the whole DOM. Solution was to select as $("div.foo"). Without knowing about the algorithmic complexity in searching a tree and the corresponding algorithmic simplicity in searching an indexed hashtable (such as {"div": [list of divs]} which I'm sure the browser keeps internally) this solution would have been non-intuitive.
I interviewed at Google 5 years ago, and they asked me tons of puzzles and math questions (game theory and theorem proving!!). I was being interviewed for a programming job. Looks like the process has changed.
As a Google engineer who has spent lots of time interviewing and recruiting, this is an attitude that potential candidates need to get over. Google's a software company that will ask you software questions during the interview. There's no magic aptitude test. There are no riddles. Just read Steve Yegge's great blog post on interview preparation and apply! (http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...). If you can code and solve problems, you might get hired.