Log in

No account? Create an account

Previous Entry | Next Entry

Jun. 26th, 2007

Some thoughts, on the eve of my (rescheduled) G phone screen:

I've been going over some questions that I either didn't answer correctly or didn't give the best answer. There was a question put to me in a past G screen that I couldn't remember fully, although I remembered it had something to do with testing bits. So I thought it might be a parity-related question. (On a past Cisco interview, the hiring manager almost asked me to give an algorithm for checking parity, but when he saw the expression on my face (omg I don't remember!) he changed his mind and asked me to do something else which I did almost fully correct; just one missed brace, which wouldn't have happened if I hadn't been nervous, or had been sitting down in front of a keyboard.) So I visited the Wikipedia page for parity, which led me to another page on bit twiddling hacks, which had several interview-type Q&A, including the one I was trying to remember.

Just looking through these questions, I get the feeling people who do computer architecture or digital design are likely to get them, because they spend a lot of time doing that sort of thing. But what about everyone else? For the people who try to "solve" these problems, is it better to answer correctly, or incorrectly, but reveal how you arrived at your conclusion? On a past Y! interview, the hiring manager asked me to implement something in Perl that was very similar to code I'd written to process web server logs, so I was able to do it quickly. I was feeling good, until he said "I see you answered that one pretty easily, so I have to ask you another one." The next one was much more involved, and took me more time (mostly to think about what I was doing). In the process of explaining (and writing on the whiteboard), I realized that there was a more optimal way to represent the data, which I wish I'd been able to take more time thinking about rather than writing. (FWIW, I didn't get the job.)

In these interviews, when I think of the answer quickly, I want to say or write it quickly before I lose my train of thought due to nervousness. OTOH, there are times when I have to stop to think about something or try to remember something, and I would like to think quietly so I don't make a mistake or overlook something important. I think these interviews paint me in a bad light; I do much better in a conversation or perhaps a presentation where I've had time to think about what I'm going to say and how to field potential questions. (Since this sort of thing is very important to companies like G and M$, perhaps this is a sign that they're not a good match. But what am I supposed to do? They're the only ones who'll interview me ...)

I wish I knew why I can work out the "design an XOR circuit using NAND gates" problem but can't remember what the tcpdump commands are for printing out certain types of packets. I actually reviewed the tcpdump man page but I don't remember the details. There are lots of different combinations for protocol type, source/destination address, field values, etc. Whereas the only thing I have to "remember" for the XOR circuit problem is that NAND gates can be used to build any of the boolean logic operators (AND, OR, NOT). Plus I got lots of opportunity to build circuits this way in 6.111, the digital lab class, even though I took it almost 25 years ago. (Actually, it just occurred to me that if I'm nervous, the way I might answer the XOR question might change because I'll try to do something that allows me to explain things more simply, such as write out an ordinary circuit diagram first, then replace the components with their NAND equivalents.)


( 1 comment — Leave a comment )
Jun. 27th, 2007 01:43 pm (UTC)
Because there's almost no circumstance (outside of a test for a class, or during an interview) wherein you would need to utilize the tcpdump commands where you couldn't also do a quick review of the man page to be sure you have the correct one for your situation.

Tests and most interviews are completely non-representative of how a person would work on a daily basis. It rather boggles my mind that we spend 4+ years as students learning to regurgitate data when that's not how knowledge is used in almost any other context.

It's frustrating, but outside of redesigning how we educate and evaluate, I don't know how it could be fixed.
( 1 comment — Leave a comment )

Latest Month

December 2017

Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow