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).
We sat down with Gary Poster, VP of Engineering at Manifold, to learn more about Manifold's commitment to eliminating gender bias, as well as their hiring process and work culture.
Spoiler alert, Gary emphasizes some of our top values like empathy, employee engagement, and product excellence to achieve a productive work environment.
Headquartered in Canada, Manifold is on a mission to help developers break free from the closed ecosystems of the cloud and into a more open, standards-based community of services and APIs. They offer awesome benefits like flexible working hours and $2,000 towards professional development to help their team thrive (and even give back to the communities they love)!
Read on to learn more about the culture at Manifold and what you can do to join their team!
1. What traits are you looking for in your next team member?
We have several positions open right now, including a Customer Success Lead, a couple of frontend engineers, and a backend engineer or two. Each of those have their own specifics, of course. More generally, for all of our positions, we look for empathy, good written and oral communication skills, and a growth mindset.
For the customer success position, a key characteristic we're looking for is experience supporting developers. For backend, we're looking for Go, and ideally GraphQL experience. For the frontend, React is the key, and if you happen to have experience with Stencil or d3 in addition, that would be amazing!
2. Why do women and underrepresented talent feel they can thrive at your company?
We have a number of key positions held by women. We think that when people identify with company leaders, they will feel that opportunities are real.
From a cultural perspective, we work hard to make Manifold an environment that helps everyone thrive. Emphasizing empathy helps with that. We also coach growth, feedback, collaboration, and excellence, and we have the people and programs to back it up. In particular, we have had a number of internal lunch-and-learns that supported some of these topics, ranging from inclusion to psychological safety. We have a group that chats in Slack and sometimes in meetings about inclusion in our culture. These have all led to small but welcoming changes, like many of us specifying our pronouns in our Slack profiles.
Most importantly, we believe that integrating diverse ideas and perspectives leads to the best teams and the best solutions. We want people to have different ideas, to feel that they are welcomed, to empathize with others, and to feel that they are included, aligned, and committed to the results. That's hard work, and it holds us all to a high standard, but we believe it's the best way forward for innovation.
3. What does the interview process at your company look like and how long does it usually take?
Our process is a screening call, a short questionnaire, a 3-4 hour homework project, and three interviews with potential peers. We wrap up with a call with our CEO and figuring out the nuts and bolts of getting you a contract. We can do it in a week, scheduling all three interviews in a single day, but it's more typical for candidates to want to find time in their own schedule, and do it over the span of two or three weeks.
The process typically goes like this.
We usually start with a phone call with your hiring manager or the person otherwise leading the search for your position--a "screen," but 30-45 minutes, to let you ask questions too. We often also try to set ballpark salary expectations in this call. When possible, we like using the Gitlab salary calculators (see their backend and frontend developer calculators, for instance) to set expectations in an open way that tries to reduce bias.
If you and Manifold both want to proceed after the call, we collect two things from you over the next several days. For one, we ask you to fill out a questionnaire, containing seven or eight questions about your experience. For the other, we typically ask you to do some kind of homework. For developers, this is a timed four hour project in Go or React. For the customer success position, we have a scenario for you to work through.
Once we have these two items, we share them with several people who would be your peers in the organization, and ask them for an evaluation. To again try to reduce bias, we generally evaluate our homework assignments and questionnaires anonymously--without names or resumes, and using gender-neutral pronouns. We only tell reviewers how many years of experience you have. We care a lot about both the questionnaire and the homework, and have decided that candidates are not a fit right now based on one or both of them.
If we decide to proceed after the review, we schedule three hour-long interviews, each with you and two people from Manifold, for a total of six people. You'll typically have a chance to meet people who have jobs like yours, as well as jobs adjacent to yours. Interviewers will have seen your resume, questionnaire, and homework. Conversations will be about all of them, as well as your own questions.
If we all want to proceed, we're in the home stretch! We'll figure out the details about your salary and contract, have you chat with our CEO, and hope to have you signing a contract quickly!
4. What's a hot tip about your interview process that PowerToFly members can know?
I'll give three. First, come to all your calls with questions! They help us both evaluate one another better.
Second, the questionnaire is just as important to reviewers as the homework. You don't need to write a novel or overthink it, but we're looking at your culture fit, your interests and passion, and your ability to communicate in writing. Four or five sentences per answer is a good middle ground, in our experience.
Lastly, if you are a developer, when you are doing your homework, write a good PR, as if you were communicating with peers on your team. Make it concise, clear, and friendly. Quickly summarize what you've done, why, and the key points you have questions about.
5. Can you relay an encouraging anecdote about someone who was hired by your company who may have thought it was a long shot, or they applied multiple times?
A few months back, one person took our junior-level React homework assignment and didn't do quite well enough. After we told them, rather than stop the process, they decided to take two weeks and dig deep into React with self-study and practice, and then take our advanced React homework. They did well in the advanced homework, we were impressed during our interviews, and we hired them. We no longer have two available tests, but in our screening calls we do sometimes explore the possibility of people studying React for a week or two before taking our homework, if that's interesting to them.
6. What do you love most about working at your company?
We all care about growing ourselves, our culture, and our product's excellence, and I think it shows. Even within a distributed team, we care about each other. We bring our full selves to the team, and put in the extra touches inside and out that come from pride, passion, and empathy for our peers and our customers.
7. What is your favorite thing about PowerToFly and why is it valuable to your organization?
It targets a group we're highly interested in: gender diverse candidates who want remote technology jobs. Also, the people running it seem to be really nice!
We're a pretty small company, but we've gotten several hires through PowerToFly, including key positions. We also really appreciate PowerToFly's active approach to outreach, beyond simply being a job board.
8. What can other recruiters do to be more successful when looking for diverse talent?
I'm confident that there's more to be done, but based on our own experiences, there have been a few things that have worked well for us.
When we are hiring, we use products, companies and recruiters that help us target diverse candidates--like PowerToFly! We have had a lot of success from simple searches and requests. Showing up is a good start.
Happy employees bring in their own network to candidate searches, and happy employees from underrepresented groups have helped bring in more diverse talent.
We care about our job descriptions and work to make them gender neutral with tools like textio.
As I mentioned before, to try to avoid bias, we evaluate our homework assignments and questionnaires anonymously--without names or resumes, and using gender-neutral pronouns--and clarify that process to candidates.
During the hiring process, we collect feedback privately before sharing it with one another to try and prevent groupthink.
9. What do you think that candidates find most appealing about the opportunities at your company?
Many folks like the idea of helping developers create faster and more powerfully. Our product's story--an independent marketplace of developer tools that can build win-win relationships between customers, providers, and platforms--can really excite people.
Also, working remotely on a strong, distributed team is something that appeals to many people who want to have more freedom in where they live, and commute less.
Finally, we are using newer technology like Go, React, Kubernetes, and web components. And we're operating with leading operational and organizational practices, such as those from the DevOps movement. Some candidates are excited to use and learn these tools and skills.
10. What are the top skills/character traits that make you so successful in your work?
We strive, and I personally strive, for empathy, a growth mindset, excellent communication, openness and transparency, the pursuit of excellence, and a lean/Agile/DevOps mindset. I often summarize all this as trying to balance alignment and autonomy while pursuing growth. I wrote a blog post about the principles I try to follow and grow, if you'd like to read more!
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.