I’ve been interviewing lately for sysadmin positions. There was one that made an impression on me from yesterday. It was for a small, local, video search site. First thing was that they already had a couple of people in the loop so to speak, so I wasn’t really very in the running. For another, I get there and a lot of the questions were about ruby on rails development. I’ve played with it, used and marvelled at how easy and simple a lot of things are, but also read quite a few blog entries about it. (Just look around sometime. Their evangelism is amazing.)<\/p>\n
As part of it they had me do a quick DB schema for a tag cloud<\/a>;. Extensible too, if you don’t mind. As an occassional coder, it wasn’t too bad a request, and it was interesting. Better than “what’s the worst thing you’ve been asked to do on the job and how did you handle it” for sure. Eventually I got down to (if I can remember correctly) three tables, plus whatever it was tagging for. If it was for a bookstore, it could start with books and later add on authors or whatever.<\/p>\n Talking to a friend of mine today, I asked about that schema. He mentioned that to preserve referential integrity you need the foreign keys on the tablespace and not on a row in a “mapping table” as I was calling it. I countered with a couple of thoughts:<\/p>\n 1- Adding three tables for each new data type you want seems excessive – mine added one. and<\/p>\n 2- This isn’t in Java, so the assumption isn’t that everyone is a moron.<\/p>\n Then we got to discussing whether one large table would be faster than several small tables i.e. if it would be more expensive to do a select on a single table with x rows or y tables totalling x rows then combining them…Neither of us knew, but again it seemed a tradeoff of hackiness\/correctness on one side and elegance\/incorrectness on the other.<\/p>\n Which brings me to this interview. All interviews should have a debriefing a day or two later. I think that just having friends with whom I can discuss things like that is an asset for a company. Also, having learned a bit more about them during the interview I would be more able to make commentary on things and ask better questions. For example:<\/p>\n 1- What are your thoughts on the discussion above?<\/p>\n 2- If this is a single-city location-based advertising company, why do I have to add the city and state to the search for it to work correctly?<\/p>\n 3- If the search is location based, would a map be a good idea, was it discussed and dismissed for various reasons?<\/p>\n As another example. I did a quick phone interview for a company and neither of us hit it off with the other. I mentioned I had been playing with the prototype<\/a> javascript library. He asked why and I simply (and honestly) said that it was easy to use and did everything I needed it to do while hiding the irritating things from me. He Immediately noted that it violated a fundamental law and added things to the arrays it was presenting. I didn’t know this and hadn’t run into it. I find out later that it does, but if you iterate over it in the recommended ways you wouldn’t run into the problem. It would be nice to be able to ask if he had run into it, and talk a little more informally.<\/p>\n