Has This Ever Happened To You?
You go into an interview - or even a code review with a client - and you're sitting opposite a "Senior So and So" who begins to ask you some interview questions. You've read Hanselman's list so you're fairly certain you'll know 50% of what's coming next...
The interviewer then looks at you and says "my background is with databases actually - but lately I've been handling all the development so they've asked me to give you a bit of a going-over. What do you know about integers?"
"They're non-decimal numbers that are represented by 3 core types, differentiated by upper and lower bounds and..."
"Right right - Int32 and Int64. I don't mean to veer off into a discussion of 64-bit processor architecture; our app is 64-bit so we use long - let's move on..."
A variation of that happened to a friend of mine - where the DBA flat out asked him how many "columns" an Int64 used. I'm not kidding. It turned into a lighthearted moment where he was chided for being a DBA ("just play with your sprocs dude") - but at those times don't you begin to wonder
just who should be asking whom the questions around here?
I suck at interviews. I never remember theory, and more than once I've flat out told the interviewer that I have more important things to hold in my brain than pi to 12 significant digits. It's not WHAT you know at the time - it's that you know how to find it out, and quickly.
That doesn't excuse someone from knowing their Gang of Four - for instance. There are a core set of patterns that you're likely to use a lot (Factory, Builder, AbstractFactory, Visitor if you're using LINQ Expressions, State if you like pain). These are the ones I use from time to time - and I suspect you have your favorite too.
I've also been accused of over-thinking and over-engineering when I've used these patterns (the State Pattern, for instance). Was it appropriate? Sure. Did I need it? Strictly-speaking, maybe not. Did it cause me to write more code? Yes.
Did the person who told me not to use it understand what I was doing and why I put it in there. Nope.
Was that person my boss? Yep.
This Code is Crap.
I went through a code review once a few years back and I was pretty proud of what I put together. It used some tricks (a Fluent Interface, which I tend to like a lot) and some other things to make using the codebase very simple.
The person reviewing the code was pretty old school and had a history of "Enterprise" development. They reviewed my code, declared it unusable and "junior level". I took the criticism and asked them if they could be a little more detailed with me - what was so bad about it?
"It's Crap. No one will be able to understand this at all"
I had written this code for a client (it was a rather large Fortune 50 company) and they had their Super Secret Senior Engineer review it for the typical stuff - security, quality and so on. The guy was a Java guy who (evidently) also did .NET. He was was looking for acorns, I gave him chocolate covered macadamias.
I asked him if he knew what a fluent interface was. Nope. I gave him the story about how a lot of developers like it (when it's not used for everything - but it's great for discovery etc.). He cut me off and told me it was crap. Again.
This guy had many years of experience. Was he dumb? Not at all. Did he have no clue that what he was seeing was a recently accepted style of coding that a lot of people quite like? Right again. The problem came in when he decided that he knew more than me, therefore what was trying to do was silly kid stuff.
Managers fall into this trap a lot. It's your job to figure out if you're dealing with one of them. It could be that what you're writing is Silly Kid Stuff - but the manager has the duty to discover this through Q&A. A good manager listens to his minions.
Know Your Interviewer
If you're a Senior Dev - read up on Hanselman's list. It's a great primer for what "bookish" managers will expect you to know. By "bookish" I mean managers that need to quantify what you know vs. other devs. This can work for you, or it can work against you.
I would offer that the person asking you the questions will know the answers to those questions because they just Googled them before coming into the room. You can know this by asking them questions too - remember an interview goes both ways.
Some questions to ask your interviewer might be:*What's the training process like around here?
*How often do you evaluate whether innovations in the tech industry apply to what you're doing here?
*How can I bring an idea to your attention when I have one?
*What would you do if I created a prototype, on my own time, to show the validity of that idea?
*Are GUIDs truly, universally unique? And if not - how many iterations will it take to find a matching set?
*Tell me the result of 0.05f - 0.04f - 0.01f.
*Tell me the result of 0.05D - 0.04D - 0.01D.
*Tell me the result of 0.05M - 0.04M - 0.01M.
*What's the difference between a Decimal and Double?
*Are Stored Procedures more performant because they're compiled, or because their query-plan is known ahead of time?
*Is it a good idea to lock a file when it's checked out of source control?
*Are vars dynamic?
*What's the difference between a Class and a Type?
*When and why should you change accessibility on a class (sealed, internal, etc)?
*When and why would use an interface?
*What's in your Zune playlist right now?##It's Your Career
It's highly likely that you're not going to know all the things an interviewer throws at you. What they're usually more interested in is seeing how you struggle through it. Not in a sadistic way - usually it's more along the lines of gauging your reaction. Are you an imposter? Pretty easy to tell. Are you confident enough to get yourself to a solution? Yes? Show them that.
This works both ways, as I mention. The person hiring you has to be able to change with the Technology Tide - we're in a fast-moving industry and you either Innovate or Die. Part of this process is to keep your eyes and mind open, your team nimble. You don't want to work there if you're just going to get locked up in a Veal Fattening Pen - so ask some questions!
The questions above are focused on what you, as a developer, usually face in "the real-world", and should show YOU what your manager/interviewer knows about your job and what it is you'll be doing. Chances are pretty good that their skills will NOT be on par with yours -
they're managers after all and have likely not had to deal with code on a daily basis for a while.
Oh - The "GUIDs" truly unique thing is something that has popped up
believe it or not. Not because they aren't quite capable of being unique - but because of how they were issued. Oops. Oh,
Just because they ask the question - doesn't mean they know the answer. Same goes for you - what's more important is between the lines.