I recently was talking with a company about technical depth. And it got me to thinking about resumes, interviews and general understanding about expertise.
The quality of any software is directly related to the abilities of the people involved in producing that software. So, when you're choosing your staff, you must find a way to understand if they belong on the team. Johanna Rothman addresses this in a series of blog entries called "Hiring Technical People."
Also, here is a rather lengthy discussion about technical skills for an IT Architect. What I like about it is how they use the term (do a quick search to find it in the article).
Technical depth is verifiable deep knowledge on a specific subject. A person should claim or not, technical depth on a particular subject. The specific subject should be required for the job, and noted as such.
What I would like to see remedied is a vague approach to an undefined 'technical depth' that wastes people's time and potentially impacts the quality of software. It takes two forms.
1. It is common to have 5 or 6 interviewers all with technical agendas which may or may not be clear to the interviewee.
2. An interviewee may imply technical depth on a resume that an interviewer may pursue to determine interviewee integrity, but which they may or may not be able to verify and which may or may not be relevant to the job.
Again, I would define Technical Depth as verifiable deep knowledge on a specific subject. A person should claim - or not - technical depth on a particular subject. A company should request technical depth on a specific subject required for the job.
