Tag: Code

Last week, I had my first ever real-life technical interview. While I have been working as a software engineer for 10+ years, I came up through the ranks as a freelancer and then took on my first corporate role from within Automattic’s ranks. Automattic’s process was more trial-by-project rather than a one-hour technical interview.

I won’t know the results of the interview for a bit yet, but I wanted to reflect on areas I should be more mindful of in the future:

1. Environment
   The invitation to the interview said I should set up a boilerplate web application environment using the tools and languages I was most comfortable in. I decided to install MAMP and spin up a vanilla WordPress install. Then I created a child theme and boiler plate plugin to be able to inject custom code for working through the exercise.
   
   There were pros and cons to this setup. For example, having the WordPress install meant that creating a new database table was as simple as coding a $wpdb query. Same with fetching or inserting new rows. However, some of the do-it-the-WP-way nuances also made the process more cumbersome. In the case of the database tables, actually building the new table required that I also had to write a function which would run the CREATE SQL command when the plugin was activated…and then call that function in the activation hook…and then go into plugin settings to deactivate/reactive the plugin to make it work (this could have been slicker if I had WP-CLI installed).
   
   I think there are definitely roles where having a WordPress install via MAMP would be a good solution, but I will also be testing out different boilerplates to get comfortable with a more streamlined version.
   
2. Stay calm and think out loud(er)
   All week, leading up to the interview, I kept reminding myself to stop, read through the problem which the interviewer presented, write out an outline, explain my approach, and then dive into the code. I even had a Google Doc set up for that express purpose.
   
   So what did I do day of? Got nervous and jumped directly into the code 🙈. Luckily, the interviewer pulled me back and said, “Hey, maybe we should chat about this?”
   
   Throughout the pairing session, I also should have been more vocal about the choices I was making and the code I was creating. While I did bring up key decisions and pivots, it was easy to slip into silence because we were screen sharing. This gave a false sense that the interviewer could understand my more nuanced intentions and thought processes because they could read my code. However, as many of us already know, explicit is better than implicit. I should be saying what I am thinking in order to make sure the interviewer is following along with my process.
   
3. Think deeper about greenfield solution design
   I don’t have much experience in building greenfield, blank-cursor apps. My work has generally always been built on legacy systems, existing APIs, or within the parameters of a pre-built ecosystem. I’ve been doing remodels and this interview was a new construction build.
   
   In this interview, I was too quickly focused on the how to make the application work right now. I skipped over thinking about how to make the application function throughout the long-term lifecycle of the product.
   
   The experience made me realize that I need to be more thinking through the architectural constraints of a project sooner. For example, if you need a unique ID to be created in a project, how many unique IDs will you need over the lifespan of the application? How long should the ID be in order to assure you never run out of unique combinations? The benefit of using WordPress is that it has build in functions, like wp_unique_id() which handle creating unique IDs. However, I think it would have benefitted the process to talk through the reasoning in a more in depth way.
   
4. Be more curious
   At the end of the pairing session, the interviewer asked if there was anything I would have been concerned about when rolling out an application like we working on. My answers were performance and use case. Both of these are topics which would have been beneficial if they came out earlier in the conversation. the whole process would have been better if I had held onto my curiosity about why the company needed this feature and how they intended to use it. This could have informed the design phase and made implementation more robust.
   
5. Practice makes perfect(ish)
   Guess who now has a Leetcode account? Yep, this lady. Exposing myself to the types of challenges and questions that technical interviews are likely to use will be how I translate my real-life skills into a successful interview.

Have any pro-tips or suggestions for future interviews? I would love to hear them in the comments.