Surviving a Technical Interview

Over my career as a software something, I have had a bunch of technical interviews.  Some I have done well in and some I have not.

The first part of this journey was understand something for myself. For the interviews I performed poorly in, about 50% of them I actually knew the answer, but could not get it out. Why was this?

The second part was as I led teams, I wanted to find an accurate way of assessment where a person was in their journey, whether they would stick with it, and whether they are a good fit for the rest of the team.

Here is the presentation I did to a lunch and learn group at CodeCore:

I feel many Technical Interviews fail to do their job properly.  Whether the process is not well enough thought out, the people involved are not trained, whether interviewers are evaluated higher for their technical skills but not their people skills, or they really just trying to get extra “clones” of themselves. But without a doubt the worst is, there is a lack of reflection and accountability for the actual success of their chosen candidates.

Still too many questions are on topics or specifics that the interviewee will never do in their actual day to day work.

So many people conducting technical interviews fail to imagine that this is a two way process.  That the “employer” is actually showing the future “employee” how they work with people.

All of that said, some are getting right and it is not from the traditional “hazing” approach, but a more collaborative approach, where the potential “employee” show a project they have worked on, where the interviews feel like a great passionate conversation..