This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The Dreyfus model lists five stages of skill: novice, advanced beginner, competent, proficient, expert. I'd like to discuss how we could use this to address different levels when interviewing.
Novice - I don't think/hope we have these in a profession. A novice is going to want to get the job done rather than learn more. (per Andy Hunt Pragmatic Thinking & Learning)
Advanced Beginner - I see most intern and entry level candidates here. The big trick is that they usually don't have an awareness of what they don't know. (unfortunately this is true for some more experienced people as well). I would focus this interview both on ability to learn and already having a solid foundation.
Competent - I suspect most developers are here despite a desire to view ourselves farther along. I would focus the interview on existing knowledge and problem solving.
Proficient - I think this interview would be a combination of competent and expert.
Expert - These should be our managers and architects. Interviews can focus on tradeoffs, thinking an "interesting discussions". Unfortunately due to title inflation an architect or "expert" often isn't.
This is oversimplified of course because you don't know where someone lies along the scale until after you've interviewed them. Thoughts?
I also think some of the troubles with interviewing is people getting stuck at Advanced Beginner. Like the 1 year of experience repeated 10 times these people aren't progressing in acquiring more skills over time.
One way to go about this is to develop a clear understanding of what a junior, mid-level, or senior person looks like in your organization. It is helpful to write formal or informal job descriptions of each. A fairly accurate set of requirements and nice-to-haves that describe each level and include technical and non-technical skills and responsibilities. You may already have formal job descriptions that fit the bill, so study them and understand how they differentiate the levels. If they don't capture what you need, consider morphing them into something your organization can use for evaluation purposes.
That's a great start, but just a start. If you are familiar with sizing user stories, you know that it takes a team some practice before they can consistently estimate the relative size of user stories. It's a feedback learning process that converges on goodness over time. Figuring out what junior, mid, or senior means in your environment, is a similar process of refinement. The nature of the problem excludes perfection so you have to build in the ability to make corrections when you discover you've made a mistake. Depending on how you hire, this may include things like shifting the candidate from one hiring queue to another, changing the makeup of the interview team, adjusting your offer, or making adjustments after a trial period after the candidate is hired.
author & internet detective
It seems to me that we can use the model for at least two purposes:
* adapting our hiring process to the skill level of the applicant, and
* filtering applicants based on skill level for a certain position. Can we afford to have an Advanced Beginner in a certain position, or are we specifically looking for an expert? How do we find out who is?
It also occurs to me that the model doesn't really apply to a person as such, but to a *skill* of a person. So, someone could well be, say, an expert in debugging EJB applications, but a novice in OOD.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
author & internet detective
I agree. I was thinking of Java development as one skill. But even core Java isn't because there are so many partwhich brings up something from Agile Hiring: if someone is an expert in one thing (even if not your thing), it shows the person knows how to become an expert.
Jeanne Boyarsky wrote:I agree. I was thinking of Java development as one skill. But even core Java isn't because there are so many partwhich brings up something from Agile Hiring: if someone is an expert in one thing (even if not your thing), it shows the person knows how to become an expert.
I really like your statement related to expertise. Never really thought about it.