If you are honest in your representation (resume, answers to questions) then I have a lot more trust in you, and have greater confidence that when you do join our team you will let me know when things are bad, good, or otherwise, and together we can help make it better. I also have greater trust that when you say you can do something, that you will be able to, and that I can confidently guide work in your direction without micro managing you (I'm not interested in doing that at all).
If you put a skill on your resume either in the summary, or the last 4 or 5 years of experience, I expect you to be able to talk about it. I want to be able to get answers about:
- How was it used?
- What problem did it solve?
- Would you use it again? If so, in what kind of context?
What I don't want to hear is:
- "It was created by <insert author>"
- A regurgitated version of the github/codeplex project summary
- "Ahh, I didn't really have much to do with it, my code was just called by it"
- The exception here is if the tech you listed is a description of the overall architecture and not something that you claim to know about.
- Any made up answer that attempts to cover up your knowledge
I can guarantee that no matter how many "required skills" I put on the job advertisement, you will have to learn a new skill at some point after joining us. Therefore, I want to know that you know how to learn, and that you care about learning. I want to get to know the kinds of things you choose to learn about and how you decide which ones are worth an investment of your time.
Once you join our team, we will continue to invest in your learning, but I still expect some learning to happen outside work hours in addition to the time that we allocate you.
This is a given in most roles today. I want to know that you can communicate effectively, and approach people in a constructive manner.
I want to know that when you know your stuff, you will ensure others get to know as well. I will probably pose questions that I know are incorrect in order to see whether you will agree with me because I am your boss, or whether you have the confidence to call me out when I am wrong. Just because I am your manager does not make me right all the time, and I need to know when I am wrong so that I can learn too.
Time and again I see people hiring for the exact skillset that they need today. While it is quite handy if you can get that, this is nowhere near as important as all the previous items listed. I want to know that you know how to program, that you have taken the time to learn a little about the tech you are using (not just blindly implemented something inside the framework), and that your skills will be transferrable and useful to our team. In fact, having skills that are not related to any project we are currently working on, and that no one else in the current team has, is a big plus, as it brings new experience and perspective to the team.
What I don't look for
Generally speaking, I don't care about how senior/junior you are. I look for great people, and it doesn't matter if they happen to be 18 months out of uni, or have 20 years of programming experience. Great people will help the team and myself continue to grow and excel, and that is exactly what I want.