Below is an article originally written by Nina Yang, Software Engineer at PowerToFly Partner Yelp, and published on September 9, 2019. Go to Yelp's page on PowerToFly to see their open positions and learn more.
Finding that first job in the tech industry can be a daunting task. You might not get a response to your application, or maybe you'll move forward with the interview, but it doesn't pan out in the end. You might wonder, "How are other people successful at getting offers? What do others do differently? What's the secret to getting through this arduous process?"
The answer is pretty simple: lots of practice. While there's never a guarantee of getting an offer, following these recommendations can increase your chances of successfully going through the interview process and potentially landing your dream job!
Know the Basic Flow
When you start interviewing, expect to follow this basic structure. Below is Yelp's interview process, but many companies have something similar:
- Online coding challenge
- Technical video interview
- Onsite interview
Review CS Fundamentals
Before you begin the interview process, you'll need to have a good grasp of fundamental CS knowledge. If it's been a while, review data structures and algorithms. I highly recommend Introduction to Algorithms as a good resource. If textbooks aren't for you, you can find an abundant amount of public resources online. Keep in mind that when a company decides to not proceed at any stage of the interview process, they will likely have you wait 6 months or more before you can reapply. It's important to be prepared before you apply so you can get the most out of your experience.
For coding exercises, most companies will allow you to choose your programming language. Even if your preferred language is different from the company's primary coding language, use it! This is your opportunity to demonstrate your coding knowledge and show your best work to the interviewer. Pro tip! The interview process is not the time to attempt a new language. Stick to your strengths.
If you don't have a strong preference, consider the trade-offs of different programming languages. For example, one of the biggest constraints for any interview is time, so using a scripted language like Python over a compiled language like Java could be an advantage. Statically typed languages like Java and C++ are considered very verbose, which can take some time to transfer from your head onto a screen or whiteboard. In addition to being less verbose, scripting languages like Python have more flexibility with data structures such as slice notation.
Now that you have the fundamentals down, it's time to practice! Out of all the options available online, many engineers favor LeetCode. Leetcode categorizes problems by difficulty, which is helpful when you're preparing for an interview. The first technical interview typically covers easy to medium level questions, and onsite interviews medium to hard, so it's important to practice all levels. From personal experience and online suggestions, you should do 100-200 Leetcode questions to be prepared.
Practicing coding will help you at every stage in the interview process. However, you'll want to make sure you also prepare for the online coding challenge, which is typically the first step. Take advantage of any practice tests made available to you on the website that the company uses (for Yelp, it's currently HackerRank). Practice will allow you to familiarize yourself with the UI and the environment, so those won't be barriers when taking the timed version. When you're ready to take the test, be sure you're are in a quiet place without interruptions and that you have a reliable internet connection. You don't want technical difficulties affecting your performance.
Prepare for the First Interview
Once you're done with independent study, it's time to mimic a real life interview! There are many online resources, such as Pramp, to help you get comfortable with interview situations. Doing mock interviews will let you practice coding while explaining your thought process. It's important to know that during an interview, you are evaluated on your technical thought process, and not just your code. This is often what distinguishes an outstanding candidate from an average candidate. There is no substitute for practicing saying your thoughts out loud— you don't want your actual interview to be the first time you try.
During your first interview, there are at least three times when you should speak up:
- At the beginning, always reiterate the problem back to the interviewer to make sure your understanding is aligned. This is your chance to ask follow-up and/or clarifying questions. It is important that you ask clarifying questions instead of making assumptions, as some interviewers will purposely omit criteria to test that candidate will ask the proper questions.
- When it comes time for a solution, it's best to offer two or three options and discuss the pros/cons of each with your interviewer. Once you've reached a consensus, be sure to either explain the components you plan to code, or make comments, before moving on to actually writing code.
- Once you're done writing code, walk through each line to look for errors. If everything looks good, you can verbally unit test your code. Depending on the difficulty of the problem, your interviewers may ask follow up questions or provide additional parts to the problem.
Remember that in an interview, timing matters! Don't assume that the first question that the interviewer asks will be the only question and be sure to keep a steady pace throughout the interview.
I hope all of this was helpful as you embark on the interview process! See below for key takeaways and additional resources.
- Whether you have old class notes, pick up a book to review, or study online, know your fundamentals before jumping into the process.
- Use your preferred coding language in practice and in interviews.
- Practice as many coding challenges as you can, ranging in level of difficulty. It helps to browse the website of the company's online coding challenge to get familiar with the set up.
- Practice sharing your technical thought process out loud.
- Reiterate the problem and state assumptions.
- Tell the interviewer why you're choosing the solution that you chose.
- At the end, walk through the code for errors and explain what you see.
- Always keep an eye on time and keep the conversation moving.
Become an Engineer at Yelp
We work on a lot of cool projects at Yelp, if you're interested apply!
How Gender Neutral Job Descriptions, Remote Opportunities, and Empathy Help Manifold Thrive
Ever read a job description and felt discouraged from applying? Or received a salary offer that just felt unfair? There are a lot of companies that show gender bias in job descriptions and offer non-competitive salaries... without even realizing they're doing it.
That's why remote-reliant cloud-computing company Manifold goes to such great lengths to ensure that they eliminate implicit bias from each step of their hiring process and offer fair salaries on par with industry standards (which is hugely important in tackling the gender pay gap, given that women are much more likely to accept low or unfair salaries than men).
Below is an article originally written by Ritu Vincent, Engineering Manager at PowerToFly Partner Checkr, and published on May 23, 2017. Go to Checkr's page on PowerToFly to see their open positions and learn more.
I recently switched jobs after spending four years with a company and team that I absolutely loved, and while I was ready to move on and find something new, I told myself that I had to find something pretty amazing before making any decision to switch. This meant I spent a lot of time (far too much, to be perfectly honest) interviewing with and talking to a LOT of different companies in San Francisco, so I could be absolutely sure I was making the right call.
Most engineering interviews in the Bay Area follow the same standard pattern — some amount of whiteboard coding, most often with a focus on algorithms and data structures, maybe some high level architecture design for more senior engineers, and a tiny bit of time getting to know about your future work environment over lunch or through a few minutes of (frequently rushed) Q&A with your interviewers.
This is a pretty broken process. Whiteboard coding is extremely contrived — no one actually codes blind with no access to an IDE or documentation or Stack Overflow on your actual job. In thirteen years of being an engineer, I've never had to balance a red-black tree or write out the implementation of insertion sort from memory as part of my job (even though both are interview questions I've encountered at very respectable tech companies). And when your most critical decisions during an interview are "should I use BFS or DFS?" or "should I use a map or a list?", you're not really getting a chance to show your potential employer what you bring to the table.
Every engineer I've spoken to acknowledges that this kind of interview is silly, and yet very few companies seem to be doing anything different. Two stand out in my recent experience — Stripe, which has been a notable trailblazer for the last few years when it comes to interview practices, and Checkr, which I was particularly impressed by (and eventually ended up joining).
Interviewing at Checkr
Checkr's interview loop starts, as most others do, with a phone screen, and then moves to a full day onsite. However, Checkr doesn't use any questions with "one magic answer", so there's no secrecy around the loop. My recruiter told me what each interview would be like weeks before I came onsite, and each of them evaluated things that good engineers do instinctively.
For example, one of my favorite questions during the day was a refactoring exercise, where I was given a chunk of bad code and asked to clean it up. This measures multiple things: 1) the ability to look at new code written by someone else and understand what it's trying to do 2) the ability to recognize ugly or inefficient code 3) the ability to change existing code without breaking functionality and 4) the ability to explain your changes to someone else and point out why you think it makes the code better.
This is what a majority of engineers spend most of our time on, so this ends up being a far better evaluation of engineering ability than an artificial toy problem on a whiteboard. In addition, throughout the entire interview, I was on my personal laptop, on an IDE of my choice, with full freedom to pull up any resources I needed (syntax, documentation, data structures, blog posts, etc.).
Two other coding interviews were also very hands-on, one focused on building a small end-to-end system and the other on solving a problem very relevant to Checkr's product space. All these exercises required me to spend more time thinking about testing, API design, and code cleanliness, and less time worrying about whether I could discover the "trick" that got me to the most elegant solution.
A second interview was a high level architecture problem, which is pretty standard practice, but instead of a standalone imaginary system, I was asked to basically design the Checkr system. The first half of the interview, I collected requirements from my interviewers and came up with a design I liked; the second half of the interview, my interviewers spent time talking about how their actual system differed from or matched what I had designed. By the end of the interview, both sides had had a good opportunity to evaluate each other, and I had learned a lot about what I would potentially end up working on.
Besides the technical interviews, I also got to have lunch with a small friendly group, which was far less awkward than the usual 1:1 lunch which my natural introversion always struggles with (I never really know if I should use a lunch break to talk more about myself, make small talk, ask more questions about the company, or, well, just eat. Being part of a group takes a lot of pressure off). And finally, I met with someone from HR and had a chance to ask questions about the company culture and career growth options, and generally get a sense of what life at Checkr was like.
At no point during the whole process did I feel like I needed to have "prepped" for these interviews. And that's how all interviews should feel. After all, I don't prep for a normal day at work. I don't spend time on weekends reading through books and posts that talk about the quickest way to "crack" code before I feel ready to come in on Monday. The best interviews should measure your real self, not who you are after a week of frantic studying.
I'd love to see more tech companies switch away from the traditional whiteboard interview. The whiteboard has had its time in the sun, and the technical interview is long overdue for a bit of disruption (sorry, I couldn't resist — I've been talking to way too many startups.)
Finally, quick recruiting plug :) Don't go and put yourself through yet another contrived graph traversing interview loop — come talk to us at Checkr!! We're hiring!
Also, read more about Checkr's interview loop here (this includes more detailed descriptions of what to expect with each interview, and what we look for when evaluating candidates.)
ATTEND THIS VIRTUAL SEMINAR FOR FREE BY BECOMING A POWERTOFLY VIP!
Did you know that 20% of onsite interviews at Google convert to an offer? Here is your chance to learn everything you'll need to nail that next big tech interview.
The virtual seminar will take place on May 22nd from 1pm to 2pm ET (10am to 11am PT).
ATTEND THIS VIRTUAL SEMINAR FOR FREE BY BECOMING A POWERTOFLY VIP!
On this virtual seminar, Martina Lauchengco, Operating Partner at Costanoa Ventures, will lend her 20 years of expertise as a marketing and product executive to help you discover what to do before, during and after your interview.
This seminar covers:
- The interviewer's perspective
- Doing pre-work
- What to do during the interview
- Post-interview strategy
- Why questions matter
Meet the speaker:
Martina Lauchengco is an Operating Partner at Costanoa Ventures. Martina spent over 20 years as a marketing and product executive building and crafting strategies for market-defining software like Microsoft Office and Netscape Navigator. As Costanoa's Operating Partner, she sits on multiple boards and advises companies on all things go-to-market. She also teaches at the UC Berkeley graduate school of engineering.