|
I've been seeing and reading posts on interview questions. I'm getting a lot out of them from both sides of the table. Jeff's post brought to my attention an article that gives a pretty good outline on what to cover and discuss in an interview to get to know the person and their skillset.
- Explore an area of expertise
- Have them critique something
- Ask them to solve a problem (but not a puzzle)
- Look at their code
- Find out what books they read
- Ask about a people problem
- Bring them on for a trial basis
For me, knowing the person or determining if they'll adjust to the team is just as important as their knowledge. Not saying that they shouldn't have a good base as a developer or that everyone has to have the potential of being my friend, but they will have to find where they fit in on the team and if they don't then they don't. They could be able to reprogram the Windows OS but if nobody wants to work with them, what good is that from a team prospective?
I'm currently on a team where the chemistry is great and it's probably the best in our company. We all get along, challenge each other, and our techno-genius is a great guy who is more intersted in helping than demonstrating his prowess. To give you an idea of the type team I work on....We have weekly status meetings on Friday mornings like a lot of teams. Ours is a little different because after the work discussion is done we play a few hands of Dilbert Corporat Shuffle. Who ever loses brings breakfast the following week. Is it a stupid game? Maybe but it is fun and it gives us a chance to just talk and get to know each other better as people (sometimes work too). It's now known as "the card game" around the office and people tend to show up in our cube area after our meetings for leftovers. |