I recently interviewed for a new job, which led me to review some notes I made for myself after some interviews a couple years ago. I thought I would share them in case someone else might find something useful here. The point of preparing is not to pretend to be anything you aren't or to know anything you don't, the point is just to have everything you do know on the tip of your tongue. You only have probably an hour per panel, so you need to be on point.
Make a list of professional things that are important to you. Out of those, pick the most important and write a few sentences. Those are kind of your mission statement. I put those sentences right at the top of my resume. Here is my list:
- Working with smart, motivated people
- Agile
- Mentoring
- Being Mentored
- DevOps
- Physical fitness
- Feeling like I'm contributing to company's success
- Company mission
- Competence of other departments
- Trust in leadership
- Trust from leadership
- Advanced software architecture
- Advanced technology
- Work/Life balance
Make a list of what areas you want to learn more/grow more in. These should be things that really excite you. It can be stuff you already do in your current job or not. Its helpful if you've shown some initiative and done some learning on your own outside of work.
Make a list of recent videos watched, books read, conferences attended, and one or two sentences about each. Try to tie the things you learned in these back to the items in the other lists. You want to show that you are passionate about your craft and always learning and improving.
Learn about the prospective company, their products, their market, their competition. Make a list of questions you have about the prospective company. Some of these should tie back to what you are passionate about. For me it was a lot of questions about how they do agile. What the dev teams look like. How they interact with other departments like product and sys ops. Questions show you are interested, passionate, and evens out the power structure of the interview a bit, which makes everybody feel more comfortable. Yes, they are interviewing you, but you are also interviewing them.
For design problems, stay calm and focus on fundamentals. Treat the interviewer as a subject matter expert/product owner. Don’t be afraid to ask questions! Your job is to:
- Capture the ubiquitous language of the domain. Make sure you understand what the pieces are and what they do.
- Capture the functional requirements of the application. I like to focus on user stories/use cases. Just solve one at a time, and evolve the design to handle additional ones.
- Nouns you hear are good candidates for objects/resources. Verbs are good candidates for methods.
- Keep it lean. Start simple and try to deliver a minimal top to bottom slice that does something. Then move on to more complicated scenarios iteratively.
