Thoughts on Interviews
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.
Waking up after a long sleep
So, I came home last year after PDC and was just too wiped out to blog much. Then work got crazy, then we had a huge snow event, Christmas, the new year, and then, oh, about 8 months and 12 days of absolute insanity.
Things aren't any less insane... but I am tired of not blogging about it.
I'm not doing the Virtual Earth work much any more, but I'll find some interesting technical topics to dig into here. The wine stuff is still going strong, I'm making a go at some internet radio, and I'm trying to do more reading... I'll come up with something interesting to talk about.
Recovering from PDC
PDC 2008 was a heck of a show. Every day, I was on the floor with members of the Virtual Earth product & marketing teams, extolling the virtues of the fine product. Met with hundreds of people, answered dozens of questions. Long days and sore feet.
I'm still recovering from the show, and getting ready for a crazy week at work. And to recover I'm playing Fallout 3. So I'll get back to posting real soon, but I just wanted to say that I hadn't forgotten about the blog. ![]()
Prepping for PDC
Next weekend, I'll be heading off to this year's PDC (Professional Developer's Conference) where I'll be manning the booth for Virtual Earth, plus just taking in some of the general awesomeness.
If you're going to be in Los Angeles for PDC, you should definitely drop by -- Virtual Earth has some of the best demos...and last year we had plush frogs...mmm, swag. Also make sure you sign up for Mark Brown's session "Deep Dive on Virtual Earth", 10/30 @ 1:45 pm in 408A; Mark'll be going into depth on all the new features in Virtual Earth 6.2 & the Virtual Earth Web Services v1.0.
See you at PDC!
Best video game ending song ever.
Recently I found myself watching the Zero Punctuation review of the Orange Box, and specifically for Portal. I don't really need to add my accolades to the pile that was heaped on to this game. Game of the year, most innovative game, blackest humor of the year, etc.
Anyway, watching the review, I was encouraged to go play it again. it's just a short game, taking only 3 1/2 hours or so, especially the second time through. And, after a really fantastic boss battle at the end, up came the song. That wonderful song. It stuck in my head for weeks after playing the first time. And now it's wedged back in there tight as ever.
So, I present to you, "Still Alive":
08/13/09 01:03:47 am,