September 12th, 2007

classic cylon

(no subject)

I found another blog post giving advice on how to pass a Silicon Valley interview. There is some good advice, some debatable advice, and some things to think about.

The sorting question was interesting for a number of reasons. One, it approaches the problem solving issue from another direction: how to translate a problem description into an effective algorithm (one that solves the problem well) but may seem like some other problem. I had commented on this some time ago, with regards to the Monty Hall problem, which even mathematicians answered incorrectly because of how it was phrased. I suspect that most people would get the "Mom's version" correct because the context within which is being asked is clear – a specific answer is expected. Whereas the "Engineer's version" may be misread by some (especially if they're nervous) to be a question about what is the best comparison sorting algorithm. So one needs to be careful not to answer the question too quickly.

"Mom's version" captures our "intuitive" notion of sorting objects into groups. The algorithm is similar to pigeonhole sort. My guess is the last time I thought about this was in 1989, when I took the algorithms class at Stanford that uses Cormen's text. But there may be people who are more likely to think about these things based on how often they do them (and whether they are worthy of consideration). This type of issue never came up at work, and I didn't really think much about this as a possible interview question until a few days ago, when I was thinking about the first time I ever encountered topics that are part of computer science. I "knew" what binary search was when I was a child, from a science fair exhibit at the site of the old 1964 World's Fair that guessed one's weight. This "stuck" in a way that enables it to come to the forefront when asked about it. However, sorting of clothing, socks, etc. that I do all the time does not "stick" in quite the same way, possibly because it's only efficient for very small numbers of items and categories. I was thinking that I never had to give consideration to a shortest-path algorithm until I got to MIT because I never had to solve anything like "find the shortest number of miles it takes to fly from one city to another, given a map of flight distances," even though I had flown before going to MIT and seen plenty of air route maps. I don't know much about high school curricula, especially for those people who are not planning to do computer science or software engineering, but if these issues are presented in classes such as AP computer science, those who don't take them (but decide to switch to CS or SE later) are at a disadvantage in the sense that certain problems are not "at the forefront" of what they usually think about, so they may not recognize all instances of these problems.

One of the responses to the post – that one may have a job that requires that APIs be glued together, so it is not necessary to implement a particular sorting algorithm, made a lot of sense to me. In fact, I find the notion that someone would be required to implement particular algorithms (without references) odd. Most of the standard algorithms are available in language libraries, so one can be productive, without needing to reinvent the wheel. The respondent goes on to question whether Google is attempting to identify candidates with proficiency in the areas covered (e.g. knowledge of algorithms), or those who (need to) study those areas to get to a level of proficiency. As I've noted, from a practical standpoint, most people don't spend a lot of time implementing all of the standard algorithms, either right before an interview or over the course of their careers and education. It's not productive. Also, this isn't the only thing a candidate would be expected to know.
  • Current Mood
    curious curious
  • Tags
classic cylon

(no subject)

Here's a link to the best tips for a Google interview I've seen so far. One point raised was that it's necessary to practice writing code using paper and pencil. The reason is because you'll be asked to do that (or use a whiteboard). Most programmers nowadays code using IDEs, which contain tools such as editors and debuggers to aid in the development process. It makes people more productive; why write something out in longhand that you have to enter into the computer anyway? There was a time when people did not have IDEs, so they used flowcharts, desk checking, and the like before entering their programs on punched cards or tape. IDEs were developed to simplify the programming process. But it seems now that we have reason to doubt the productivity of IDEs, because people might be relying on them as crutches. (Sort of like using calculators instead of doing arithmetic using pen and paper.) Ironic, isn't it? We are regressing because we do not know how to ascertain whether someone knows how to do something.

I was reminded of when I was at Stuy, I could focus much more on doing well in school because I didn't have a lot of conflicting priorities. I did have some things I needed to do, such as chores, but for the most part, I could spend a lot of time on schoolwork without worrying that I needed to do something else. Also, I didn't have conflicting priorities with regards to what was assigned – it wasn't as if I had to prepare for the possibility of tests from teachers I didn't know or topics I wasn't very familiar with (that were not covered in class).

I think that the culture of Google is sort of like high school in that regard – because so many other things are taken care of (meals, laundry, etc.), it gives the engineers more time to dwell on these matters that most people can't afford to spend time on. When I was at AV, if I'd spent time thinking of all the different types of algorithms I might use to solve a given problem, my management would have been upset with me because I was not solving their problems. I had to pick solutions that were likely to work over a broad class of situations, particularly because there often wasn't time to rewrite something. I had to move on to the next thing.

I think that in the AV engineering groups, there was more opportunity to do that type of brainstorming. I remember during the brief time I was part of the index build team, I attended some meetings, at which design issues were discussed. It was very refreshing from the sorts of things that used to come up at my group's meetings, like debates over whether cookies should be used to determine the number of unique users, and so on. I missed having that type of interaction, which I think is important to the continued professional development of a computer scientist or software engineer. But as time went on, even the AV engineering groups were forced to just implement something and move on to the next thing, because so many people had been laid off and there was no time to ponder what might be a better way of doing something.

I'm not saying that Google should change its hiring criteria, but they should be very honest and upfront about what types of people they're looking for, and why it's difficult to find them. The US Congress is trying to address the issues of a (presumed) lack of CS or SE expertise, not a lack of geeks. Google (and all the other companies complaining about a lack of qualified applicants) should just be honest about what they're looking for, so there can be a meaningful discussion in the US Congress about rectifying this situation. Put it to the voters – should the US Congress go to great pains to accommodate the specific staffing needs of companies?