One of my more popular historical posts is the one where I put up my interview questions. I’m guessing both hiring managers and candidates like to look at them. Recently I was contacted by someone attempting to answer the questions asking me what the answers were.
I tried to explain (probably not very well), that the answers to the questions were not as important to me compared to how the candidate went about the process of answering the question. As a matter of fact, I generally only gave a “B” grade to people who just provided the answer without any commentary or explanation. Grades of “A” were given based on HOW the question was answered. My measure of skill wasn’t solely confined to the correct answers, but included my opinion of the process used by the person to solve the problem — while keeping the problem within the knowledge domain.
One reason I’m skeptical of many certification exams is that they don’t provide for essay responses, but simply ask for the “correct” answer as determined by the test construction. I heard a myth once that sometimes the “correct” answer isn’t based on objective fact, but on a sampling of responses from tests taken by “acknowledged” experts. Even if two choices were objectively correct, only the one chosen by a majority of the acknowledged experts would be graded as a correct response. I don’t think that’s a good way to assess someone.
Anyway, I like a list of interview questions so that you can ask all of the candidates the same questions and compare their responses against each other — that way you can choose the candidate who best fits your open position.
I realized that I never answered my quiz about Excel and the large numbers.
There was a hint in the post’s title — precise — which referred to the fact that Excel (Excel 2003 SP3) has a maximum precision of 15 digits. And it’s behavior when confronted with larger numbers is to throw away the extra digits, so that 123456789123456789 (18 digits) becomes 123456789123456000 (15 digits of precision). I ended up changing the column formatting to Text from Number, since we aren’t going to be doing calculations on it anyway.
Which brings me to the last part of the quiz, which asked why I would care about this during database design. Sometimes I find it useful to question my own assumptions when chugging along and one of them I often look at is whether or not to declare a field as a number or a character. Numbers are good when you want to do math, they provide a kind of allowable values verification (only numbers are allowed) and they provide ordering. You can’t really do math on a character field, they are entirely free-form, and they have odd ordering based on character sets. So if I don’t need the math, and I don’t need the ordering, and I might want non-numeric characters at some point (common if this an “account number” or other kind of identifier), maybe it should be a character field. So, I often ask myself — does this REALLY need to be a NUMBER, or does it REALLY need to be a VARCHAR? What happens if it’s the opposite of what I’d normally do?