Interviewing
Posted ; Updated
Just what the world has been waiting for, another article on interviewing. There's a twist to this article though, it's all about me, yay. Well, more that it is motivated by my experiences and focused on interviewing for software development roles. I'm writing this as I'm preparing to interview for technical lead / hands on management roles.
Most Important: Be Concise!!
I start with this point because I suspect it is where I have failed the most. The ability to clearly and quickly articulate the important points of a story can be paramount to success in your interview. Don't ramble. Unless specifically asked, details of the data structures you used in your last project, for example, are not necessary information. And once you realize you are rambling, wrap it up ASAP. This is why practice is so important.
There is a balancing act though.
Know the difference between clear and concise and too brief.
For example, if asked to describe a time you faced conflict and how it was resolved, an answer of,
another developer and I disagreed on which database to use. I explained why my choice was better and we went with that.
is almost certainly insufficient.
The STAR Method
If you've done any reading on interviewing, you've likely read about the STAR method (pdf). Note: the two STAR method links are to different sources. I liked each description, it wouldn't hurt to read both. I'm not going to describe the STAR method (see the links above), but let's look at how one might frame the example above using the method.
- S: Situation - My colleague and I were developing a new feature on our existing platform. I was the more senior developer thus responsible for the overall success of the feature implementation. The feature would generate new data on the platform while also depending on existing data. My colleague and I disagreed, somewhat strongly, on how to manage the new data. Having many more years of platform development, I think I had a deeper appreciation for the long term impact of changes, especially adding new components to a system.
- T: Task - We needed to resolve this issue and move quickly to development. I needed to balance the goals of developing a long term sustainable solution with the desire to mentor and encourage my colleague.
- A: Action - I arranged for us to have a design session where we could enumerate the pros and cons of each solution and consider alternatives. I suggested we prepare by listing pros and cons of both our preferred solution and the other's proposal. The goal was for both of us to consider the other's perspective.
- R: Resolution - The meeting went well though the technical debate was sometimes intense. We landed on a solution with elements of each of our solutions. We were also able to have an honest discussion of how hard it is to not be personally attached to one's own solution, and how that might cloud one's judgement. I like to think we both came away from that experience with deeper trust and appreciation for each other. I can go into details of the proposed and combined solutions if you'd like.
This is a contrived example though has elements of past experiences. My goal was to showcase honesty, maturity, empathy, and leadership skills. And, of course, brevity yet completeness. STAR stories are not the place to showcase technical prowess, the interviewer will ask technical questions if/when it's appropriate.
In the past, I would have been tempted to explain more of the proposed solutions or the combined solution.
For example, the new data was a good fit for a document model thus my colleague wanted to use MongoDB.
Each document though would need the customer ID which was already stored in PostgreSQL.
We would have to deploy and manage Mongo, a non trivial task especially considering we'd have to do it as a geographically distributed replica set.
Plus we would have to manually address data integrity situations like deleting all the documents in mongo if the customer was deleted in postgres ....
I cringe as I type this recalling past interviews where I did almost exactly what I'm describing. It's hard when you want to geek out on something even knowing it's not the right time or place. Notice the last line in the Resolution part. Offer to give more details and let the interviewer decide how much to geek out.
Questions I'd Ask the Interviewer
Now it's your turn to ask questions.
Of course you've done your homework and read through the company's website and LinkedIn posts. And you've read through the job description and a few other similar sounding jobs. And if the company has a service with a trial or free tier, you've signed up and tried it. With all that research, you must have found something you'd like to understand better about the company.
The point is to be interested in the company and the job. Maybe don't pour it on so thick it sounds disingenuous. And if you are disingenuous, maybe that's not the right place for you. Though maybe there aren't a lot of options and you need the work, there's nothing wrong with that. More digressions, I'm going to go review my notes about the STAR process and stop this rambling.
To the point. Here's a list of questions loosely grouped.
- Questions regarding the company -
Unless you know people in the company, you're going to want to get a sense of how the company operates.
This is helpful to you and also conveys the idea you consider topics like corporate culture important.
If you're interviewing at a very large company with many divisions, these questions would apply to the division.
Different divisions within the same company can have very different structures/culture.
- Would you describe the company culture as collaborative? Is executive leadership intentional about setting corporate culture?
- What is the process for deciding what to build and how to build it? Which organizations are involved in that process?
- Are people encouraged to try new ideas to learn and supported in failure?
- How are teams within development structured? For example, is there a separate quality engineering team?
- Do all teams in engineering follow the same processes or are teams encouraged to set their own?
- Questions for the hiring manager -
The questions above regarding the company can be asked to anyone, though more appropriate for more senior people.
If you get a chance to talk to multiple people at different levels of seniority, it's good to ask similar questions and gauge the consistency of their replies.
The following questions are probably best for the hiring manager, or maybe the hiring manager's manager.
- From the list of requirements for this role, which two or three are the most important?
- How do you describe your management style?
Wrap It up
I think I've hit the high points, and I want to go work on other stuff. Probably the overall theme of interviewing well is be curious, be authentic, and be concise. Just as important, be ready to learn from your own mistakes but don't be too hard on yourself. I've finished interviews thinking, ugh, that was a disaster. I've also finished thinking, hmm, that went well. Then I hear back they're not going to continue the process. Every interview is a learning opportunity. The better you can honestly reflect, internalize, and learn, the better you will interview going forward.
Good luck and don't burn out. It's okay to do something entirely different for a while after reading that email about it not being a great fit, blah blah blah. Don't let that break be too long though. Something else always comes up. Be patient, and be ready.