Well, it's hiring season. So, while I ponder how to fit my work in around all these interviews, here are some random thoughts that have occured to me mid-interview. These were all written a couple years ago, and these days I live in the consulting world, so I probably have something to say about the ability to be in front of a customer, but I'll talk about that another time.

I don't care how you dress.

Yeah, yeah, yeah, I know...pretty much contrary to every other similar article out there. what can I tell you? I just don't.

I mean, wear clothes -- and cover the parts of you that should be covered -- and I'm pretty happy. A suit is fine, khakis & a dress shirt is fine, jeans and a tshirt will do if they're at least mostly clean. Your clothes won't be writing any code for me.

Team fit is part of the equation, of course. but most work places are pretty diverse these days; anything from suit to tshirt is likely to fit in, with the people who have to interact with the business groups skewing business casual (especially as the company grows larger). Generally speaking, I would rather you feel comfortable during the interview than fiddling with the collar of a shirt you never wear.

Don't sweat the syntax.

My whiteboard doesn't have a compiler, don't worry about it. I'd rather get to an additional question than watch you erase and re-write your code. If I can figure it out, I'm good to go.

That stuff you learned in comp. sci. actually matters.

"Programming" covers a lot of area. You could spend years slinging PHP or building Windows Forms and never confront a problem that involves a directed graph or a finite state machine -- but those problems are out there, and more common than you might imagine.

I have seen a lot of broken software projects; among the common causes is a failure to really understand the problem they were trying to solve, and the implications of the various design options open to them. I prefer to catch those problems early in the project lifetime, so my interviews tend to emphasize 'design' problems. Identifying the right data structures, displaying the ability to develop your own algorithms... those are going to go a long way.

It's not a deal-breaker -- I just recently hired a fellow who stared at me blankly when I asked about the complexity of a search -- but if you can't apply the basics, it is going to limit the sort of projects I put you on.

How much you can learn is as important as how much you already know.

Everyone has to start somewhere. Microsoft consumes entire graduating classes to feed it's SDE-mill, but those of us not recruited straight out of school are faced with the problem of convincing someone to take a chance on us.

I've done a lot of hiring, and especially in college towns, where I was faced with several inexperienced candidates to choose between, inevitably the choice came down to one question: "What are you working on for yourself?"

If you're not intrigued by computing -- if you don't feel the urge to try to solve a problem, draw a picture, automate a task, play some music, or in some way bend the computer to your will -- why should I hire you? For one, how else are you going to practice programming? Second, almost every programming job involves some amount of learning, and I like to see evidence that you are willing to work on your own to learn something.

Similarly, as a person's career starts to move them into the 'senior (blank)' category, I expect that they are spending at least some time in evolving their own skills, in terms of specific technologies, general techniques, or specific domain knowledge. 'Senior' doesn't refer to how long you've been in the business, it's about the sort of problems you can tackle; and the ability to rapidly get up to speed in the environment, the language, and the problem space is a big part of that.

Given the opportunity to brag, do so; but be realistic.

Nothing makes me disinterested faster than someone who refuses to give me a reason to hire them. Tell me what you're good at, admit what you're bad at, and we'll be fine.

Often I'll get resumes from online sources and they'll include a skills inventory; where the applicant can list various skills or technologies, the level of skill, and years of experience. There's some great humor tucked away in there... Folks with 8 skills listed at 'Expert' with 2 years experience, only 1 years out of school. Oh, my aching sides. That'll get you cut even before the interview.

But if you do get to the interview, make sure that if you say you're an expert, that you mean it. You aren't an expert in .NET if you can't tell me even a little about memory management. And please, you're not even 'intermediate' with object oriented programming if you've never used polymorphism; and if you have to look it up, you're not even a 'novice'.

Bring in some source code.

Why yes, I would like to see an example of your work -- design documents are good too, if you can do it without violating someone's trade secrets -- but make it something cool. Please? I don't want to see a basic winforms app. I want to see a class heirarchy, I want to see an algorithm, I want to see you solve a problem in code that doesn't involve loading and reading member variables.

And document it. This should be as good an indication of what your finished product will look like -- or at least what you think I want it to look like. Don't leave the Visual Studio auto-generated comments in there, don't have error messages that use profanity, etc. I've seen some pretty crappy code, don't make yours the subject of my next blog entry.

And that's about enough...back to reading resumes.