A few days ago I had the opportunity to participate in a mock technical interview thorough SkilledInc.com. It’s one of the many benefits Flatiron offers it’s new grads to help them prepare for the job search.
After the interview was complete the interviewer took 10 minutes to critique my responses and give me overall feedback.
Here are some of the take aways from this expereince:
1. Be prepared to answer everything about the language you’re interviewing in.
2. If you mention anything in you interview be prepared to discuss it thoroughly.
When the interviewer asked me about the projects that I had worked on I mentioned that I had just built a project in React. This allowed him to move the interview from a discussion of JS to a discussion of React. He then began asking me several deeply technical questions about React to gauge my understanding of it. His feedback to me was that whatever technical topic is mentioned in the interview is fair game. Be prepared to discuss in technical detail everything that you have worked on. Also, if you bring up any topic during the interview be prepared to cover it.
3. I am now a software engineer and no longer a student so answer all questions as if I am an experienced engineer.
I was asked why I chose to create my final project in React. My answer was that I used React because it was a requirement for the school’s final project. The feedback was that no matter what, I must take ownership for my technical decisions. If I want to be taken seriously as a software engineer I must be prepared to defend my decisions with well thought out reasons. For example, I could have said that I chose React for the performance benefits (with respect to the virtual DOM), the composability of components (which helps make code maintainable), and unidirectional data flow (as well as single source of truth with Redux). Any technical decisions I make at this point are my own and I must own them.
4. When it comes to algorithms, take your time and discuss your approach and thought process. Don’t write a line of code until you have buy in from the interviewer about the direction of your solution.
I was given a problem to solve that involved 2 arrays. I was told to write a solution that would check to see if all items from the first array were included in the second array. I was excited because I had worked on similar problems before so I immediately jumped into writing the solution before discussing anything with the interviewer.
I was told that in the future I need to slow down and discuss the problem with the interviewer. Ask questions about possible edge cases (what if one of the arrays is empty? What if one of the arrays has ‘nil’ as one of its values?). Find out about the space and time complexity. Ask question about the input and putput formats. Ask about everything that could affect the problem. The purpose of the algorithm questions is for the interviewer to get a sense of how you think. If you don’t discuss the problems at length they will never know how you approach problem solving and can’t fully evaluate you. Take your time and let the interview in on your thoughts.
Overall, having this mock technical interview was extremely beneficial. I have an idea of what to expect in future interviews and I know how to prepare for and approach them. I also realized that I need to get cracking and start building more projects. I can’t rightfully call myself a software engineer if I’m not constantly learning, building and adding to my portfolio. I’m no longer a student - I’m a contributing member of the engineering community.