Questions to ask in an interview

I've worked with a lot of people in my time.
I've worked with lots of really smart people, and lots of really, really dumb, lazy, unqualified people.

I prefer the former. It's become so very clear to me how important it is to keep bad people out. I'm better off having an un-filled position that have it filled with the wrong person. (It's probably the same with romantic relationships - but I digress).

OK - so there are lots of Java interview questions all over the iternets, but here are some questions I like to ask when interviewing a candidate for a Java developer position (and sometimes beyond)

1. Have you read Effective Java? This is a good litmus test. This is a fundamental book - and if you haven't bothered to read it I probably don't want you on my team. It's not an absolute rule - but it's a decent starting point. 
2. What books have you read? Aside from Effective Java I like to hear Java Patterns - then maybe some technology -specific books on whatever technology's listed in your resume, especially from your last job. Maybe it's Springs or Hibernates or XMLs or PHPs or whatever. Point is, there's only so much you can get out of a quick intro read on a website and form your own exposure - if you really want to know it  then learn from an expert.
3. What did you read most recently or what are you reading now? What I am trying to find out here is, what's the candidate's approach and attitude towards continuous learning? The very last thing I want is someone who learned to write Java code in a class in college a few years back, or read the intro on the Oracle site. It's a continuously evolving field - if ever there was a field which requires a lifelong learning, this is it. My most recent read is Java concurrency in practice - which I highly recommend.
4. Why do you want to work here? This always seemed to me like a really stupid and annoying question when people ask me that at interviews. It's as legitimate as an interviewee asking 'Why do you want to hire me'. As an applicant I think (to myself) 'I didn't say I wanted to work here - it's an interview. It's a two-way evaluation'. Maybe a better question is, 'What motivates you to come to work'? The truth is there are multiple reasons why somebody would want to come to work, and they are all important. Yes, I want to be paid for my work - if everything else was perfect about a job but it had no pay, I'd definitely have to pass. I want to work with smart, motivated people that I like. I would prefer being the least knowledgeable and dumbest person in the room - but the reality is I typically find myself coaching others. I like to be challenged with new ideas, technologies and tools. 
5. How do you manage your email inbox? This is also a no-single-right-answer type question, but it gives me a good idea of your organizational skills. That's probably a good topic for another post.
6. I am always curious about the candidate's outside-of-work work - like open source projects, StackOverflow posts, SIG memberships etc - but that's not at all a requirement. I understand perfectly well that people have a life outside of work - homes, families, hobbies, twins to feed and change and put to bed, dinner to cook and clean up from - so if I get into bed and manage to watch a half hour YouTube on building JIRA workflows, it's sometimes still a good night. 

It occurs to me there are also questions I like to ask of an interviewer when I'm sitting on the other side of the table... 

1. Describe your development process. This is also a good litmus test question. If I don't hear something about 'code reviews' - well then there's a really good chance people at the helm don't know what they are doing. It's such a fundamental part of a good software development process that if it's not there - well that means I'm probably walking into a mess of someone else's crappy old code. 
2. Describe your testing methodology. This is also a sort of a litmus test - but it's not a yes or no situation, there is more of a spectrum here. Automated unit tests like jUnit are a great way to start - I don't want to hear that 'developers test their own code'. If there's a UI testing framework set up then so much the better. I ask about what kind of load testing and performance testing you do (if at all). 
3. More open ended questions - say, what do you do to help your employees succeed? It's a flip side of the 'why do you want to work here' question. 

I'll probably think of others...

Lessons learned: working with an outsourcing partner

A few random thoughts have occurred to me, having worked with several offshore / near-shore outsourcing partner companies.

1. Don't think of - or treat them - like slave labor. Just because they are cheap (by comparison) doesn't mean the individual coworker's motivations are any different from your own. People want to work and do a good job, and to be recognized for it. Nobody likes to be mistreated. I've seen this attitude from some people - and it just doesn't work.
2. Don't ever let an outsourcing company 'give you people'. You wouldn't hire a local resource without interviewing them, reading their resume, and making sure they are qualified. Why should it be any different when working with an offsite person? It's doubly important that they be qualified for the job. If you get a resource who isn't - you will waste far more of your time training them then you ever get productivity out of them. So get a resume and conduct an interview (that's subject for another post). Depending on what you want their role to be, their language skills may or may not be at all important. One of the best UI people I have offshore speaks very poor English, but her work is top notch and I don't expect her to interact with the business clients.
3. Don't assume the company, no matter how big it is, has its act together. I've seen companies as small as 100 people (E5 consulting) and as large as 60,000 people (Cognizant) produce some terrible, terrible work. The responsibility falls on you to set up a quality software development process - whether it be code reviews, testing, documentation - anything.
4. Recognize and acknowledge good work, initiative and good thinking. People appreciate that - and it makes them want to do more. Just as importantly, recognize bad / slow work and under-performance. Here I don't have any patience - I will give direct feedback, but you don't get many chances.
5. Don't assume you can just email work request in the evening and expect that work will be completed by morning. It's often a collaborative process - so expect to talk constantly, even daily, about work specifics. Find a way to make your schedules overlap. I can shift my day and come in at 7:30 and I expect my team to shift their day too - to still be there and be able to work with me for at least several hours. 
6. Pick an outsource partner in a timezone that's conducive to collaboration, if you have the luxury to do that. If your team is in India or China and you're on Eastern time, you have a 12 or 13 hour time difference - that makes it extra hard. 
7. If you found a company you trust, hold on to them. Don't let senior IT management get rid of them because 'it's easier to deal with just one big company' - or corporate compliance raise a stink because they 'don't have a privacy statement on their website' - or corporate security to block their access un-necessarily - defend your working relationship. Switching providers is really, really disruptive. Learn and expect to deal with incompetence of middle or senior management - if you don't have that in your organization then consider yourself very fortunate and enjoy the experience. That's probably subject for another post.
8. Expect that senior developers cost more than junior developers. It the same way here - so why would it be any different offshore? Good people are worth the extra money, so resist the temptation to compare providers on the basis of costs.

I'm sure there's more to it that will come to me...