Skip to main content

Interview processes are a failure

After thinking through our interviewing process, previous company process and interviews I have gone on in the last few years, I see interviewing as a complete failure at most companies.

Obviously the interview process depends on the role but there is really no way you can spend 30 minutes on the phone, an hour team interview and a 30 minute executive interview with someone and decide if they are a good or bad candidate.   Honestly the more senior the role, the more time you should spend with them.



I want to give a few tips to interviewees and interviewers.

Interviewees - You are interviewing them

  • Dress up no matter the role.  Don't ware jeans unless the company has specifically told you to do that.  If it is a manager or higher role, wear a suit.  
  • Make sure you interview the people you talk to.  Find out if you want to work with them and their role compared to yours.  
  • Understand the day to day responsibilities and long term expectations of the role.  You need to make sure you want the job.
  • Evaluate their questions to see if they even know you can do the job.  Be careful if you leave the job and feel like they don't know you.

Interviewer - Do they fit your team?
  • Don't just ask questions but interact with them.  Make jokes or talk about an issue at work or something cool going on to see their reaction and so they get to know you.  Try to spend enough time with them so that they relax and act as if they are at work.
  • Usually a technical role can be evaluated by asking very specific technical questions or short test.  Then, you just need to make sure their personality is a good fit for the team.  
  • Spend lots of time deciding your questions and try to ask the same ones to each candidate.
  • Don't bring a candidate in for a team interview unless they are a real candidate.   The phone screen should find out if they are capable and a potentially good fit.  It is better to turn a candidate away than waste their time.

Comments

Popular posts from this blog

2020 State of DevSecOps by Accurics

 This is an excellent report for all IT Pros and Engineers.   Highlights: Storage is most impacted solution Open security groups or network configuration Secrets are not so secret Unused resources are not secure. Take a look at these.  Look again.  These are not highly skilled problems.  They just need guidelines and proactive management.  The article uses policy as code as a solution for many of the problems.  I will drill into each of these more in the future.  I wanted to get the awareness out first and then, come back to solutions.  

Manage IT by Johanna Rothman

I just completed this book. I think it is a really good book which covers a whole lot of software development. This book could possibly be the best book for first time project managers. I believe many of the PMs understand PMM but do not understand software development. This book gives a view of each project role. The only one that it does not cover is Business Analyst or requirements documentation. It does cover QC, development and of course PMs. It gives a PM a view into development processes like TDD, CI and estimation. Many PMs that are new to SD can read this book and get a great start to manager an SD project. If you are a PM or know some, read this book. http://www.jrothman.com/

Matrix Organizations are bad for Software Dev

Development teams need to be teams first and company people second. What happens when your team wants to start using user stories and index cards, but your analyst team manager thinks Use Cases are the best way to document requirements? How about when your QA process is not mature and you keep releasing with defects but the QA manager does not do anything about it? How about your project manager never buys into the team and only cares about being on time and on budget because their review is based on it. Maybe the tech lead wants requirements that never change and never lets the client change their mind. The technical manager taught your tech lead and agrees with everything the tech lead says. Agile or what I like to call "Successful Teams" are teams. They do what it takes to do what the customer wants, deliver features. I am not saying only agile teams are successful but successful teams are agile. If your organization is matrix, get your leadership buy in to override...