Image from here Seven crucial lessons I learned during my latest job search I recently started a new job. I did quite a few interviews to find this job: 15 technical screens and 8 onsites resulting in 5 offers. I’ve learned a few lessons along the journey. I want to share them here so that hopefully, you will find them helpful in your current or future endeavor. 1. Know your stack, inside-out I’ve had at least 3 onsites that delved deep into my understanding of the tech stack I use at work. The questions I’ve been asked included, but not limited to: “When would you use higher order component in React?” “How does _takeEvery_ v. _take_ work in the redux-saga library?” “What’s the difference between a PureComponent and a normal Component in React?” “What is this or that Rails’ ActiveRecord method doing in the background?” (i.e. know your basic SQL). “How does indexing work in relational database work?” (Know the basics of B-tree). “How does session work?” “What are some security checks in a HTTP request-response cycle?” “How does _fetch_ differ from _XMLHttpRequest_ .” As developers, it’s so easy to fall into the trap of writing code that works and leave it at that. On a day to day basis, that’s enough. I’m productive. I can get things done fast. However, my interviews have taught me the important lesson to not forgo what’s beneath the code itself. TLDR, read and understand what’s going on under the hood. 2. Be ready to talk about the following things I. A challenging or complex project you worked on Every interviewer asked about a project I worked on. Pick a project you are proud of, and be ready to talk about What you did. With whom did you collaborate. Every technical detail about the implementation, no matter how minute. What sort of feedback you received. Also, have a project that didn’t go so well and be ready to talk about why it didn’t go well and what you learned from the experience. II. Product/Engineering process How much are you involved with (or would like to be involved with) product planning and conceptualization? Do you prefer fast iteration and fast release cycle or the other way around? Are you a pixel-perfect perfectionist or do you have the mentality that done/good is greater than spending more hours to be perfect? III. Cultural fit What are the important qualities you are looking for in your next job? (These could be mission related, growth related, impact related, work-life balance related, mentorship related, collaboration related). Why are you looking for a new job? (Again, these could be mission related, growth related, impact related, work-life balance related, mentorship related, collaboration related) 3. Have a list of questions to ask The goal of these questions is to also help you determine whether you would be happy at the company. An interview is a two-way street. The company is evaluating you, but you are evaluating them too. Cultural fit is important to happiness at work. The questions I like to ask are: What’s something the company values that other companies might not and vice versa? Did anyone from the team I would be joining leave in the last year? If so, why? What’s something you think could be improved in the company? What’s the last thing that was added to the product roadmap and why? What’s something that’s de-prioritized recently and why? Was there a (company/engineering/product) decision made recently you disagreed with? Why? 4. Prime your interviewers before reference checks This is a piece of advice I received from someone who has interviewed tons of people. Anything can come up in a reference check, and everyone has weaknesses. Before the reference calls, you want to bring up what could be considered a weakness and spin it in your favor. If you’re someone who gets into work later than the average person, or someone who leaves earlier, you want to prime your interviewers for that. As mentioned, the question of or “w_hat are you looking for in your next job?”_ WILL come up. During the onsite, when these questions come up, that’s also an opportunity to prime your interviewers for reference checks. “why are you looking for a new job?” For the aforementioned getting in and leaving scenario, you could say something like “I’m someone who values flexible work hours as opposed to the rigidity of a 9am to 6pm schedule. I go to the office around 10, but I also do work at home.” If the topic of you coming to work later comes up, well, that’s not as much of an issue anymore is it? Especially if the new company also values flexible work schedule. 5. Study algorithm basics I know that goes without saying, but here are the things I think everyone should master. Know how and when to use: Recursion Queue Pointers (in array/string linear scan) These are extremely common patterns in interview questions I’ve come across. 6. Know an interview is just a snapshot Sometimes, a bad picture of you gets taken. You could be the most attractive person in the world, but if you’re sneezing, or snoring, or eating with your mouth open, chances are your pictures at those instants won’t be super pretty. It’s the same with interviews. Each interview is just a snapshot. I’ve had interviews where I did horribly. One of my onsite interviews was simply using jQuery to build a simple UI. It was so easy and I could have done it no problem any other day. Maybe it was the pressure, maybe it was the nerve, I did not do so well. However, I’ve encountered way more challenging questions that I aced without a problem. I know it sucks. I can’t help but feel bad after a rejection. However, you can’t let a rejection and a failure get to you. It’s not a representation of who you are. I wasn’t able to answer some front-end related questions (like what distinguishes a PureComponent) during my interview. But that doesn’t take away from my drive, intelligence, or value. Like a bad picture, you were simply caught in the wrong angle at the wrong moment. Use it as a learning experience to work the camera better the next time. 7. With that said, ask for feedback I didn’t know it was a thing until a couple of the companies who rejected me after the onsite reached out to ask if I wanted feedback. I actually learned a lot about how I could improve my interview skills during the feedback session. If I hadn’t taken up the offer to receive feedback, I wouldn’t have been able to write some of the stuff in this article. If you like this story, give me some claps! :)

Super

Too Long; Didn't Read

Questions about cloud security? Get answers here.

How to nail your software engineering job search

Too Long; Didn't Read

Company Mentioned

Lily Chen

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

How to nail your software engineering job search

Too Long; Didn't Read

Company Mentioned

Lily Chen

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES