My Answers To Common Interview Questions
I'd like to play a little game with myself and enumerate each common interview question that I've received over the past few years. By writing these questions and answers down, it affords me two things: (1) to have the time to think about an answer instead of quickly blurting out something half-baked while having interviewers stare at me, and (2) to say the things in a manner that is not always available in the interview setting.
That last point requires a bit more detail. I've interviewed (for consulting or full-time employment) with all manner of companies, large and small, old and new, and also in diverse industries (not just Technology). Most of the questions being asked are the same, but I always have to tailor my answers on the interviewer because I don't feel free to speak openly, or because I get the sense that they don't have the greatest sense of humour. In other words, the answers here show my true personality.
Where do you see yourself in 3-5 years?
I annoyingly answer this question with another question. This being 2014, what was the world like 5 years ago? iOS had just started supporting apps (July 10, 2008 to be exact) and before that there was little to no mobile app space. And now there is an entire industry surrounding the App ecosystem. People now call themselves Senior iOS Engineer and shift their entire career path towards it. Thus, it is next to impossible (and horribly myopic) to ask someone in the Tech industry where they see themselves in 5 years.
So with this thought, my answer will never include a time scale. However, I do provide a career trajectory that I like. The end goal of which is to be a CTO, preferably of a small to medium sized business. All of the knowledge and work experience that I have attained over the years has been to support this type of role. I am knowledgeable about software development, systems, databases, and security (and everything in between). A CTO should understand all of these technologies, how they play a role in different types of companies, and be able to make informed decisions that matches the company's overall strategy and vision.
So with my end goal being CTO, I can see myself rising through the ranks of being a technical director, then VP of Engineering, and then ultimately CTO. Or maybe I'll just skyrocket to the top aboard a lucky unicorn given the right chance. Either way, this is my trajectory.
With these high-faluting aspirations, I would still be the hands-on type of person that I have always been. I like to dig in and code, or properly configure a server, or automate a horribly manual process. I am ambitious enough to want to take on all of these duties while still keeping my technical knives sharp.
How do you deal with conflict?
This simplest answer is: by not getting into it. This sounds like a flippant response, but the best way to deal with conflict is to prevent it in the first place. Proper communication and comraderie can mitigate so many conflicts in the workplace, because people will realize that you are not attacking them personally, but instead attacking the issue at hand that is causing the stress (this is called "treating the cause, not the illness").
When dealing with your co-workers or customers, it is best to remember that their opinions seem just as valid to them as your opinions do to you. It is best to try and see how they could have formed their opinions, and then realize that it is that formation that you should disagree with, rather than disagree with the person.
What does a good work day look like?
At the beginning of every day I set out what I'd like to accomplish that day. External forces being what they are, I am aware that many things that knock one off course throughout the day. A good day for me is when I can accomplish at least 60% of what I set out to do.
From my beginnings as a software developer, I also like to have something tangible to show at the end of the day (a piece of working code, a webpage, etc) but taking on managerial roles means I have to adjust what "tangible" means to me. I'm still working on that.
Do you know the X programming framework?
For all values of X, I may or may not know it. But that doesn't actually matter. Do I know how to develop software? Yes. I can even do it in multiple languages (Java, Python, Ruby, PHP for example). Once anyone knows how to write software, and do it in more than one language, learning either a new framework or a new programming language is trivial.
So why is writing software difficult? Because it is easy to get wrong. Writing software has a lot to do with breaking down large problems into smaller, more manageable ones, seeing patterns where most people don't, understanding the logic behind how computers and its processes work, and – this is most important – understanding the implications of every line of code being written.
The last point is what separates an average programmer from a good programmer. Anyone can type some symbols into an editor and throw it into a production environment, but a good programmer understands how that code can fail and in what severity. Case in point, a good programmer looks at a marketing website that is read-only 99% of the time and says "that site should be static html", knowing full-well where the costs are being saved and what errors are being prevented. An average programmer would want to use a CMS or some other way to dynamically present the content in Production without thinking about the implications related to traffic spikes, database outages, etc..
What would you say about yourself that needs the most improvement?
My ambition. It gets me in trouble. I always reach for the higher rung on the ladder and am unlikely to be content with anything else. Now, this answer seems like a cop out, like saying "I'm too hard-working", but it is the truth and I stick to it. Not every employer/client likes an overly ambitious person, nor can they always retain someone like that.