Just wondering what you guys think are important questions to ask when on an interview, and likewise what things you should pay attention to. Here's my list off the top of my head:

To ask:
- What source control do they use?
- Do they write unit tests?
- Do they do formal code reviews?
- How many projects do they work on at a time?
- How long does the typical project last?
- What IDE do they use?
- % of an avg work day spent programming?
- Schedule flexibility? Work from home option?

To pay attention to:
- What is everyone wearing?
- Free drinks/snacks provided? (Good way to find out is if they ask if you're thirsty, just say a water would be great and then see if they have you follow them so you can check out the kitchen).
- Look at their computers/monitors if you can. New hardware?
- What type of chairs are they sitting in? Very important, often over looked.
- Soul sucking cube farm, nicer cubes, open layout, or offices for everyone?

Have been interviewing people for about 3 years now, and these are probably the best questions I've been asked. I'm also going to start hunting for a new job soon, so I'm interested to hear what you guys think.

Ratio of 'managers' to developers (but asked nicely - ask about how work is structured or similar, and push for numbers doing each task, be in PM, account manager, business analyst, developer, designer etc).

The higher this is, the more pressure there is on the developer.

Weirdly, it doesn't correlate to how good the work is in my experience.


Also, what technologies are they using (which version of which database, which version of .Net, what browsers do they need to comply to etc)

I think these should be asked in a more open-ended way. Something like what's your testing strategy? Make them give you details. Almost everybody writes "some unit tests" but you really want to know how ingrained it is in the culture.

When I was doing interviews I was often asked about past projects I had worked on. I think its a really good question to ask since it gives concrete details about some of those questions listed above.

Agree, though I'd go slightly broader than that. Unit tests in isolation, without a complete development strategy that works well with them, aren't very useful.

Are these really a big deal for a lot of people? Seems like the type of thing (like coding standards) that you get adjusted to pretty quickly no matter what it is.

Underrated question, spending a lot of time in meetings blows.

I'd want to know about the lunch situation - anywhere to get lunch in-house? What's nearby? Lunch is serious business.

It's kind of an interesting proxy for the speed at which they adopt new technology. If you hear they're using CVS - that should be a bit of a red flag.

Edit: And for IDE, I agree its not great. Better might be asking if you have flexibility in choosing your OS/IDE setup and what people generally use.

+1 to the lunch situation, good lunch spots are key.

And as mentioned, I'm only asking about the source control to see if they're using something terrible, don't really care what they're using as long as it's not sub-par.

As for IDE, I do .Net, so I was thinking if someone only works in VS2008 and not VS2010, that's another clue to how up-to-date they stay. Again, not really looking to judge them on their IDE if it's something different, but it's more to see if you can gain clues about how quickly they adopt the latest software.

Check for wrong code on the blackboard in the room.
Politely ask them if that code is used by the company and point out the error.

Before asking anything about revision control and whatnot, I'd ask if there are any operating system recommendations/requirements for the devlopers and then move on to language and architecture stuff. Also make sure to check their products, code and if you find any info phrase it like "I saw application X is written in language Y, can I assume that you use this language for all/most of your projects"
You can also ask them why they made certain technology choices, kind of feel dependant but you can usually get into some very good discussions that way.

Sounds pretty strange, I would be mildly worried if someone I interviewed for a job assumed we may not do this. Rather go with questions about devlopment methodology and ask the tests question in a way that implies you expect tests to be there i.e. "What are your quality control standards"

Yeah I like that a lot actually, seems like if they don't do unit tests then they look bad (which is a sign they are), but if they do do unit tests then you want to make it seem like that's what you expected to begin with. You really have nothing to lose if you phrase it like this.

Good tip.

its fine to ask if they test. it should be one of the first questions you ask.

Maybe this is a personal thing, but this would just annoy me as an interviewer.

It's the great debate of job interviews, should you point it out or not

I always viewed it as a positive if they found it and pointed it out. Means they have an eye for detail, value quality code enough and most importantly aren't scared to speak up.

I think I mentioned it in another thread but I did roughly 70% of the actual job interview during the lunch break from the interview. I'd talk about recent industry stuff, programming languages and pretty random stuff all mixed into a nice and unintrusive package. May sound somewhat strange but I'm pretty confident I gained very valuable insights that way.
Since we were an open source shop it was pretty easy to get a discussion started without seeming too obvious. I always asked people to bring their own laptop to the job interview (assuming they had one) and a good opener would always be "I see you run Ubuntu on that box, do you prefer apt over rpm" or something like that. Combination of that+their laptop setup was a pretty good indicator of how much they are commited to open source for example.

Assuming I get out of ****-code mode and "master" javascript:

What would I say to a prospective employer as a self-taught web programmer with no prior experience and no college education?

I would think that first thing is get a website opened with a bunch of demo pages and stuff like that, check the company's source codes, so at least there's something to discuss. Of course, if the code is unreadable and full of code that never executes (way more common than one would think); and they have a programming team still working in house, I probably wouldn't want to get to into it.

I guess starting up at <DOCTYPE html> would be a good start? I can see that going downhill really fast since that could show that I am attempting to insult their current practices, but with a careful hand, I could compare/contrast the advantages/disadvantages of the current crop of web standards. But this begins and ends at the question of whether they are looking for someone to bring them into the present or just maintain and add to what they have.

Do not insult/correct errors in their current codebase in an interview. Jesus, what an awful idea. Asking them how they do things is good, correcting them is so stupid.

Develop a portfolio of work. This generally requires working for free for awhile. So be it.

It's probably a bad idea to worry too much about their faults, unless you're interviewing for a position where you will have the authority to fix them.

Don't put yourself in a position where you're trying to change things, don't have the power to make them stick, but will look bad if they don't work.

The problem is, it almost always comes off as arrogant and ignores the greater context.

The code is on a whiteboard, so it could be:
* Another candidate's code
* A brainstorming session where syntax obviously isn't that important
* Old code they want to refactor
* And so on...

Even worse is pointing out flaws in the code base because again it ignores things like:
* It's legacy code that is too expensive to fix
* It's code that had to be shipped in a hurry
* It's code still undergoing QA

I have no desire to work with someone that points out every little thing wrong in a project. It just isn't productive in the big picture.

I'm also slightly biased because I worked with a guy once who would point out every little flaw in our code and write long emails pointing out problems and giving suggested refactorings - while I was working 70-80 hour weeks and the team was working 50-60 hour weeks just to meet a major contractual obligation.

Guess what, perfect test coverage and well designed code is going to slip a bit when business needs say that it has to. And while its some of the ugliest code I've ever written - it's also the project that I'm most proud of.

I'd say if you see a whiteboard with code on it in the interview room it is there on purpose roughly 70% of the time.

ITT people way overanalyzing things.

Totally agree. Let them tell you if the code is there for you to critique.

For the record:
I've only held IT job interviews, never had any. Last job I basically emailed them if they offer any internships got an answer "sure come over" and got offered a full time job after the first day of internship.

If you're any good it's just a formal joking around anyways because people will find you. At least that's how it works in open source land

Question. About to start interviewing soon, and just thought of something today. I pretty much never shave with a razor, I just use hair clippers without a guard. Shaving irritates my skin and I don't like having a smooth face, so I just don't do it. Poor form if I don't shave before going on interviews?

Depends heavily on the company and its culture.

Yeah, it obviously does. Part of me thinks I should shave just to appear more professional and get as many offers as possible, but part of me kinda doesn't want to work at a place that wouldn't hire me just because I didn't shave, or at least would even take into account the fact that I didn't shave. Wrong way to think about it?

I dunno. I think mostly the same way, but I have the option of picking from offers due to my ability and location I live in. So it depends a lot on what you care about.