The Golden Guide to Landing a Developer Position

Landing a software engineering position can be one of the most difficult obstacles that you can face. Each rejection can feel like a punch to the face.

This is why it’s important to keep a positive mentality while taking this journey. The company you end up working at can be the 3rd company you apply to or the 200th. Not every company will be looking for the exact skill set that you have to offer, but there is at least one company out there that is. It’s a numbers game. Every rejection is an opportunity to learn from your mistakes, which only increases your chances of finding that perfect match.

My goal is to show you what areas to focus on when applying to jobs and how you can become a champion in each one.

Table of Contents

• Portfolio
• Resume
• LinkedIn
• GitHub
• Getting Your Foot In The Door
• The Technical Interview
• The Golden Rubric For Technical Interviews
• The Behavioral Interview
• And Finally…

Portfolio

Your portfolio is the place where you’ll showcase your best work. It’s where you’ll prove that you can walk the walk. It’s comprised of your projects and your portfolio website.

Note: I’ll be using “project” and “app” interchangeably.

Projects

Companies want to see that you can apply your engineering skills to address an actual problem. Your app doesn’t have to be the next Khan Academy, but it should show that you can identify a problem and implement a way to solve it. To illustrate these points, I’ll talk about an app I built called Tangent.

Tangent is a mobile application for students to convert handwritten mathematical equations to beautifully typed digital text.

The first image below is an example of a handwritten math equation and the second is the digital text output. Students would then be able categorize these equations and save them for future studying.

The Problem

Tangent solves a clear problem. It targets the inefficiencies of taking handwritten notes and gives the user an easy way to store math problems.

The Implementation

Tangent uses the same technologies of the companies I was applying to. I was applying to primarily web developer positions, so it utilized JavaScript, Node.js and MongoDB.

And since I was applying to several educational technology companies, I made sure to use APIs and libraries that made sense. For instance, I used the Mathpix API and Khan Academy’s KaTeX library.

The journey to a finished product can be pretty daunting, so I’ll go over some guidelines on how to ace the main steps of the process.

The Process

1. Ideation

At the end of the day, you are trying to solve a problem. The more motivated and inspired you are about the problem, the more productive you’ll be. So, I recommend generating a list of problem domains that are personal to you. Try keeping a notebook and writing down anything that annoys you or you wish were different. What issues do you see as you go about your day? What obstacles do you see your closest friends/family face? Try doing this for around a week and you should find a few good starting points. After you find a problem, brainstorm ways an app could solve it.

Your worst enemy during this process is maladaptive perfectionism. I remember pacing in my room for hours critiquing my ideas. Every time I came across a decent idea, I ended up scrapping it because of one issue or another. Perfectionism can be a huge roadblock during this process, so don’t be afraid to simply pick an idea from your list and stick with it.

Now that you have identified a problem and how your app would solve it, it’s time to wireframe.

2. Wireframing

Wireframing allows you to visualize how the user will use your app. Imagine yourself in the user’s shoes and outline the steps they would take in the app to reach a particular goal.

With Tangent, the main goal was to convert handwritten equations to digital text. Here are the initial wireframes I used for that workflow.

The more complex the app is, the more workflows you’ll need. Paper wireframes are a great way to flesh out all of your workflows quickly and easily. However, there are great tools to build more sophisticated wireframes like Marvel and InVision.

Now that you have your workflows drawn out, it’s time to break these down into user stories.

2. Divide and Conquer with User Stories

User stories are how you make the jump from blueprint to code. They define the requirements of a specific feature in the app from the user’s perspective.

Let’s use Tangent as an example. One of the features is that a user can view all of their saved problems. When they look at the screen, they see the subject and category of each equation. Let’s convert this feature into a user story.

Title: As a user, I can see all of my saved problems in one place, so I can easily access them when needed.

Acceptance Criteria:

• User can see the problems in a scrollable list format
• Each problem should show the subject and topic
• When the user taps on any equation, they should be navigated to a detailed view of the problem

As shown above, the main components of the user story are the title and the acceptance criteria.

The title is a short summary of the feature written from the user’s perspective. It’s helpful to format it like so:

As a {end user}, I can {action}, so that I can {benefit}

The acceptance criteria is the set of requirements that must be completed to call the story done. As tempting as it may be: the acceptance criteria should not include implementation instructions. These user stories should be a description of what happens, not how it should be built.

The above user story is somewhat complex. It’ll probably require calls to the backend in order to fetch all of the problems. It may even need pagination to improve the user experience.

Not every story has to be this complex. Some may be simply adding a save button or changing the color of text in the app. Knowing the size of a story will help you determine your capacity, or how many stories you can take on at any point in time. Companies will sometimes use Fibonacci numbers to describe the size of a story. A “3” might be a small design change. A “13” may be a riskier feature that may not have an obvious implementation strategy. It’s important to keep your stories as small as possible. If you’re sizing at a “21”, you should consider breaking down the story into multiple smaller ones.

When working on smaller projects, I find it helpful to use T-shirt sizing. This involves sizing your stories as, small, medium or large. You can then assign a time duration for each size. Maybe small stories take 1–2 hours while large stories take a whole day to complete. This will vary depending on the type of app you’re building and your coding ability.

These user stories are your source of truth and will make your development experience much smoother.

Once you’ve finished your app, you can add it to your portfolio website!

Portfolio Website

Your portfolio website is your chance to show why you’re fit for that developer position. You’ll be able to utilize the visual potential that a website can provide in order to impress the recruiter/future employer in a way that a resume or LinkedIn profile simply cannot. I’ll breakdown the main components using my own portfolio website.

1. About Me

This section should tell a brief story of who you are, your competencies, and what you hope to do with your career. Be as compelling as possible. Make sure to include these points below:

• Speak to your passions (interested in fintech, edtech, etc).
• Mention accomplishments you’re proud of so your abilities stand out!
• Include links to your GitHub, LinkedIn and a PDF of your resume.
• Brevity is the soul of wit. Constrain it to 4–5 sentences.

Here is my About Me section with the text pasted below it.

“As a software engineer who studied at MIT, my goal is to use technology to improve how society utilizes the tools of education and science for social progress.

From founding a non-profit in the education sector to helping engineer software that allows anyone to view the microscopic world from their phones, my passion for technology brings me closer to that goal everyday.”

2. My Projects

The My Projects section is the core of your portfolio site. It not only showcases the hard work you put into your apps, but the engineering skills you’d be bringing to the position. This section should include:

• A brief description of each app. If possible, include an image/logo.
• The technologies and languages you used in each app.
• Links to the live app. If this is not applicable, be sure to link the GitHub repository.

Take a look at how I outlined my My Projects for reference.

3. My Education

Be sure to include any relevant education experience. Include the following:

• Years you attended the institution (e.g., 2015–2020)
• A description of what you did there. Could be your major or relevant skills you learned.

4. Accomplishments

Do you have any publications? Any organizations you started? Any popular articles you wrote on Medium? Here is the place to include it. This adds depth to your profile and can set you apart from other candidates.

Personally, I published a test-prep book and started a non-profit when I was younger, so I included those.

And there we have it! Your portfolio website. Now that we’ve covered the portfolio component of your application, let’s review with a short checklist. Use this as a loose guide to confirm that you’re on the right track.

Portfolio Checklist

• The​ ​portfolio​ ​is​ ​presented​ ​in​ ​a unique​ ​and​ ​inviting​ ​personal​ ​website that​ ​displays​ ​a​ ​rich​ ​portfolio​ ​of original​ ​projects.
• There are 3 or more projects and a few are creative/sophisticated.
• Projects are easy to explore and use. Make sure there are no barriers like authentication. Assume recruiters/potential employers won’t have the patience to sign up.
• Project code is easy to find.
• Stretch Goal: One or more projects has live users/revenue/GitHub followers.

At this point, you should have enough information to complete your resume. Let’s take a look at how to write an excellent resume.

Resume

The resume is a critical piece to any application. Your resume should be simple and easy-to-read. Keep these following formatting tips in mind when constructing your resume.

• Avoid fancy typefaces and images
• Stick to black and white
• Keep resume length under one page

Let’s review the basic resume components and the strategies to make each section a winner!

Personal Information

This should be at the top of your resume. It should include your:

• Name
• Address (city and state)
• Phone number
• Email
• GitHub link
• LinkedIn profile link
• Portfolio website link

I recommend using bitly to shorten links that are too long to fit on the page.

Technical Skills

This will consist of the languages and frameworks that you’re proficient in. List them in the order of strongest to weakest. Be ready to have conversations about any item on this list with your interviewer. Check out the Technical Skills section on my resume below for reference.

Products

The Products section should contain descriptions of the apps you’ve built and their impact. They should also emphasize your individual contribution to the product.

The word, “product” holds more weight than “project”, so I recommend using that. Before I dissect this section, I’ll show you an example from my resume for more context.

Ordering

Be sure to order your products from most to least relevant to the job description. For instance, your front-end apps should come first if you’re applying to front-end developer positions.

Roles

If you were a part of a team, make sure to include your role on the team. In my examples, I was the backend engineer.

Action — Result Format

The bullet point descriptions of your contributions should follow the action-result format.

The action will be a verb that emphasizes your skills and contributions. For instance, if you’re applying to startup roles, you would use words like, “built”, “created”, or “initiated”. The result is the outcome of your contributions. Take a look at the two examples below.

Managed [action] a $9,000 budget to organize hackathon events for 1,400 students [result].

Architected [action] Node.js backend with Mathpix and KaTeX APIs to convert 800+ raw image data objects to rendered html [result].

Make Use of Data

Notice that in the examples above, there are quite a few numbers used. Whenever possible, use data to quantify your impact. This could be the number of downloads, users, reviews, page visits, etc. Using numbers communicates the scope of the app’s impact and scale. It’s way more impressive to say my “app reached #X users” than to simply say, “I launched an app”.

Work Experience

This section should include descriptions of your previous roles. Be sure to include the most relevant roles first. Follow the action-result formatting like in the Products section. Feel free to use my Work Experience section below for reference.

Education

This section is pretty straightforward. Make sure to order by most recent. If your institution or program is not well-known, try including a short description.

If there is room, feel free to include other accomplishments such as awards or publications in your resume. You could also include relevant volunteer experience. For instance, it would be helpful for interviewers to know that you mentored high school students in computer science.

Both your resume and portfolio website are ways to convey your skills as a developer. However, neither would offer the same visibility that a great LinkedIn profile would. So, let’s take a look at some tips on how to construct an effective LinkedIn.

LinkedIn

Fortunately, several of the tips for constructing a strong portfolio website apply to creating your LinkedIn.

About Section

For the About section, you can paste the About Me section you wrote for your portfolio website. Additionally, you’ll want to include your:

• GitHub link
• Portfolio website link
• All the languages and frameworks you’re proficient in (paste the ones you wrote for your resume)

Make sure to exclude the word “student” and any high school experiences. Say that you’re currently an “engineer.” You are — you’ve built more apps than many full-time engineers. The word “student” may undersell your abilities.

Featured Section

Here, you should include:

• Your resume in PDF format
• Links to any relevant high quality articles you’ve written
• Any publication or media content that speaks to your credibility

Other Tips

• Be brief and make it easy for people to skim your entire profile.
• Put all your products in the “Experience Section” of your profile — it will make them more visible. When you do this, be sure to include some indicator that lets recruiters know that the product isn’t a full-time role. You can include the “(product)” at the end of the title. Or include the past time range during which you worked on the product.
• Get skill endorsements from classmates, colleagues and friends.
• Photo — should be professional: business casual with eyes facing the camera.

Once you’re finished with your LinkedIn profile, I recommend sending it to a classmate or colleague to review and offer feedback. Now that we have LinkedIn covered, let’s move onto your GitHub.

GitHub

A polished GitHub is key to your job search. Employers will visit your GitHub so it’s important that they can understand your projects and that they see clean code.

Make sure your GitHub meets these requirements:

Solid Profile

Your profile should contain your location, a link to your portfolio website, and a short bio. Feel free to draw from your About Me portfolio website section.

Well-written README

Use markdown when writing your README and make sure to check your spelling. When describing your project, make sure to:

• Name the languages, frameworks and technologies used.
• Describe the problem you were trying to solve.
• Include instructions on how the project should used.
• Include links to relevant, related info.
• Include pictures or GIFs.

Feel free to use Alamofire’s README as a solid example.

Other Tips

• Try to contribute to other projects. It adds credibility to your profile.
• Do your best to create work that people will want to star.

Now that we’ve reviewed the components you’ll need for your application (resume, portfolio site, LinkedIn, Github), it’s time to discuss how to get your foot in the door. What are the key strategies to landing the first interview?

Getting Your Foot In The Door

Hiring for tech jobs is driven by who you know. You can increase your chances for employment significantly by getting a warm introduction.

Let’s say you’re applying to LinkedIn. Your name can reach the hiring manager in one of 2 ways. They can pick out your name from a stack of hundreds of applications or they can hear your name from one of their engineers or recruiters. The latter case is a warm introduction. You’re essentially vouched for by the person giving the introduction. Let’s dive into the steps of getting that warm introduction.

Find Connections

To find the people you’ll reach out to, leverage your LinkedIn network.

The first step is to find your target jobs. They don’t necessarily have to be at your dream companies. They can be companies that you’re only somewhat interested in. Getting an interview with them is a win because all practice is good practice. You’ll sharpen your skills for your dream job interview.

Here are the steps:

1. Go to the jobs search on LinkedIn. Type in your city and the role. Filter by jobs posted in the past month.
2. Choose a job posting and check if you have any connections. Open those connections in new tabs. If you don’t have connections, use the list of employees at that company.
3. Select the engineers and recruiters in the list.

Request a Phone Call

The prerequisite for this step is that you apply to the company. After you do that, you can request a phone call from one of the engineers that works there.

What about reaching out to the recruiters? You definitely should, but I recommend reaching out to engineers first as their referral can hold more weight than a recruiter. These are the people who can better understand and appreciate your relevance to the department’s needs, and a referral from them is likely to be trusted more by the hiring manager.

Try using the following template when sending your message to the engineer on LinkedIn.

Subject : [Name] — [Role] Who Wants to Learn More About [Company name]

Hi [Engineer’s name],

My name is [Your name]. I recently applied to [Company name] and I believe I would be a great fit. I would love the opportunity to learn more about [Company name]. Are you free for a 5 to 10 minute phone call sometime this week?

This message gets straight to the point. It shows the engineer that you truly care about the company since you’re taking the time to learn more about it from someone else. By asking for a 5 to 10 minute phone call, you’re showing the engineer that you respect their busy schedule.

Here are some examples from when I was applying to LinkedIn:

Sometimes, they’ll simply refer you!

Setting up these phone calls is a great way to grow your network and increase your chances of getting a warm introduction. However, nothing compares to a face-to-face meeting.

The “Reach Out For Coffee” Guide

Getting coffee with your industry contact (e.g., engineer, recruiter) is much more effective than having a short phone call. The “face-to-face”aspect builds more trust and increases your chances of getting a strong referral.

The first step is to reach out to the contacts you compiled from the Find Connections section above.

You can use the following template when sending your message. Feel free to customize it with any details about you as an engineer that you think is important. Make sure to keep it short and simple:

Subject : [Name] — [Role] Who Wants to Learn More About [Company name]

Hi [Contact’s name], I’m a software engineer who is passionate about building awesome products. I would love to get some career advice and learn more about what you do at [Company name]. Would you be open to grab coffee?

If they reply, make sure to suggest a coffee shop near their office. Use a specific address or ask them to suggest a place that’s convenient for them.

Here are some other tips for the meeting:

• Meet at a location convenient for them. Making the logistics easy will improve your chances of meeting up.
• Meet for around 30 minutes. Try your best to not take too much of their time. Show up on time.
• Don’t forget to send a thank-you email. Talk about your biggest takeaways from the conversation. Mention that you appreciate them taking the time to talk.

What If They Don’t Reply?

If they don’t respond to your request within 4 or 5 days, send a follow-up message. Something like:

Hi [Contact’s name]. Hope all is well! I’m following up on my last message about meeting for coffee. Are you available this week?

Preparing For The Conversation

Whether you’re having a phone call or a coffee session, it’s important to prepare for the conversation. Try generating the following:

1. LinkedIn Research Notes

Scan their LinkedIn profile. Here are some example questions you can answer:

• What are their accomplishments?
• What do you want to learn more about?
• See if you share a place where you were raised. Do you use the same technologies and tools?
• What is their professional focus?
• What are their aspirations?

2. Top 3 Questions to Ask

Come up with 3 or more questions to ask. Some topics:

• The company’s culture. How it compares to other companies they worked at.
• Their experience and accomplishments.
• Challenges their facing.

3. Top 3 Connections/Interests

This is your chance to talk about what you have in common. Maybe you both really enjoy using JavaScript. Are you passionate about the same sectors? Maybe you lived in the same city.

The information you compiled above will help you contribute the conversation and warm up the connection.

Conversation Stretch Goals:

Try landing these stretch goals:

Stretch Goal 1: Show them one of your favorite portfolio apps. Ask for feedback and advice.

Stretch Goal 2: Offer to show your code. Request a code review. Request a review of the UI/UX of the project.

Finally, Ask For A Referral

If you feel like the conversation went well, try asking for a referral. You can say something:

Thanks [Contact’s name], for taking the time to talk. I learned a lot!

I actually already applied to [Company name]. Would you feel comfortable forwarding my resume to the hiring team?

Tools For Finding Contact Info

These tools below will assist you in finding the contact’s email/other contact info.

ContactOut — chrome extension to find email from their LinkedIn profile

Hunter.io — finds email from company directory

By now, you’re equipped with the tools to land an interview, so let’s dive into its main components. We’ll dissect both the technical interview and the behavioral interview.

The Technical Interview

The technical interview is usually the first interview. A technical phone interview is typical for the initial screening. If you’re able to pass that, you’ll face the more difficult, onsite interview. To ace these, you’ll need to have a solid problem solving strategy.

Problem Solving Strategy

Keep these points in mind as you’re solving the problem.

• Restate the problem. Ensure that you have a solid understanding of the problem.
• State your assumptions. Often times, we assume too much.
• Think out loud. Don’t be silent. Share your thought process.
• Try the simplest solution first. This is a great starting point. It leaves room for more efficient solutions and refactoring.
• Examine why it’s not ideal. Critique your solution. Analyze the complexity of the solution (both time and space complexities) and try to improve it.
• Test multiple inputs. Generate reasonable test cases. Make sure to start simple, then increase complexity.

Generating test cases definitely warrants its own section. Let’s dive into it!

Test Cases

It’s important to generate test inputs and their expected results. The test inputs are the inputs that will be used by your solution. The expected results are the results that you expect the solution to output. Returning different results than what was expected exposes bugs and gives you an opportunity to improve your solution. Using test cases shows that you’re thorough when solving problems, which is a skill that any good developer should have. We’ll focus on the follow types of inputs:

1. Good/Normal Inputs
2. Bad/Unusual Inputs
3. Edge Case Inputs

Good/Normal Inputs

The following points should give you an idea of what a “good” or “normal” input means.

• Uses valid data types
• The values and sizes of the inputs are well within expected bounds
• Uses expected types of values based on your assumptions. (e.g., positive integers)

Here are a few examples:

• List of 4–6 unique integers greater than 0 in a small range: [2, 8, 5, 12, 7]
• List of 4–6 unique mixed numbers in a small range: [2.7, -4.2, 0, 3.14]
• String with 4–6 words in different cases: “I like coding in Python”

Bad/Unusual Inputs

Bad or unusual inputs are any of the following:

• Invalid data types
• Unexpected values
• Data structures with improperly constructed data or pointers
• Data that may cause your function to throw an error

Here are a few examples:

• List of only integers and floats: [2, 8.2, 6.01e23, 0.000001]
• Numbers with unexpected values: [8.1, “nice”, null, NaN]
• String of digits with too many decimal points: “-14.28.57”

Edge Inputs

And finally, we have edge cases:

• Valid input, but one that has the possibility of breaking your code if not handled correctly
• Values and sizes of structures at the limit of expected bounds
• Breaks assumptions on values

Here are a few examples:

• List of integers with some duplicates: [7, 4, 5, 4, 3]
• List of only 1 or 0 elements: [7] or [“lonely”] or []
• Mismatched parameter values (e.g., function expects a number, but you pass a string)
• Linked list with 1 or 0 node(s)

Data Structures and Algorithms Practice

There’s no getting around that this process will take a lot of data structures and algorithms practice. Where do you start?

Save Your Problems

I recommend opening your favorite code editor and creating a folder called Interview Practice Problems. Here, you’ll store each problem you tackle. These problems can come from sites like, LeetCode or even companies you interviewed at. Why do this?

• You can revisit the problems that gave you the most trouble and attempt them again. Are linked list problems difficult for you? Then create a folder that contains those types of problems.
• Having one place that contains these different types of problems will help you recognize patterns in the types of interview problems companies give you. There are only so many ways you can ask a candidate to construct a binary search tree.
• This will be a resource for you once you start the job search again. When you decide to move onto a different company, there’s a good chance that you’ll be a bit rusty in the interview problems department. What better way to hit the ground running than to tackle these personally curated problems?

To give you a better idea of how this works, take a look at the setup I used when I was applying to jobs.

Notice that I have problems ranging from Interview Cake problems to the ones that I was given during my Google interview.

Practice Resources

It’s important to set aside structured blocks of time for technical interview practice. When you’re first starting out, there’s no need to time yourself. The focus should be understanding the fundamentals and the types of problems given. Once you feel comfortable, I recommend timing yourself and trying to improve your speed.

Here are some good resources for practice problems:

• LeetCode: Provides a large number of curated interview questions. You can choose questions by company (e.g., Top Amazon questions). You can even set up a mock interview in a timed setting.
• Glassdoor: Primarily used to learn more about a company(e.g., salaries and reviews), but it can be extremely helpful when it comes to company interview problems. Former interview candidates sometimes post their interview problems. It doesn’t get more authentic than that.
• Cracking the Coding Interview: This infamous book is a great tutorial of the fundamental data structures and algorithms you’ll need for your interview. It also includes useful information about interviews at specific companies like Amazon, Facebook, Google and Apple.

The above are powerful resources, but the best way to ramp up your interviewing skills is to actually interview with another person. The way you communicate your ideas is a major factor of these interviews and that’s not really something you can learn from a book. You’ll also be able to practice the problem solving strategies you learned in this guide!

Online Mock Interviewing

Below are two amazing online tools for mock interviews:

• Interviewing.io: You’ll be paired with a software engineer anonymously and will run through problems ranging from algorithmic questions to system design questions. The best part is that if you do well, you’ll have the chance to go straight to the onsite interview at that engineer’s company.
• Pramp: You’ll be paired based on your availability, experience, practice topics, etc. Pramp is unique in that you and your practice peer take turns interviewing each other!

Offline Mock Interviewing

Find a friend who’s also looking for a job or an engineer you know to give you a mock interview. You’ll get to experience the pressures and obstacles of an in person interview. Here’s a step-by-step guide:

1. Find a partner to do mock interviews with. One will play interviewer and the other, interviewee.
2. Work through the problem as if you’re in an actual interview. Your interviewer should have a checklist (see Golden Rubric below) to make sure you follow best practices.
3. Have your interviewer give you feedback on you did/didn’t do.
4. Swap roles and work through the next problem.

The following are a few great mock interview problems to start off with:

1. Given an array a of numbers and a target value t, find two numbers that sum to t (that is, a[i] + a[j] = t).
2. Find the k largest values in an array of n numbers. Return them in a new array sorted in decreasing order.
3. Given a list of n strings with mixed casing, return a new list of all strings that start with a capitalized letter.
4. Find the longest substring of unique letters in a given string of n letters.

I suggested that the interviewer use the Golden Rubric as a checklist. I wrote an article on this where I essentially do a breakdown of the 6 categories that interviewers use to grade your performance. Each category is assigned a score (1 to 4) with 24 points being a perfect score. Use this as a North Star. Aim for perfection (24 points), but understand that not getting there does not mean that you won’t get your dream job.

The Golden Rubric For Technical Interviews

1. Coding & Syntax

4 Points [Strong Hire]

• No syntax errors
• Translated solution and future improvements into code effortlessly
• Demonstrated exemplary knowledge of language constructs as well as paradigms in other languages
• Compare several coding approaches

3 Points [Leaning Hire]

• Few-to-none syntax errors
• Translated proposed solution to code with little difficulty
• Showed familiarity with common language constructs and paradigms

2 Points [Leaning Don’t Hire]

• Minor syntax errors
• Coded the naive solution but stumbled on occasion
• Poor use of language constructs

1 Point [Strong Don’t Hire]

• Several errors (logical or syntactic) that severely impacted the correctness of the solution
• Poor use of language constructs

2. Data Structures and Algorithms

4 Points [Strong Hire]

• Explained the naive solution and its drawbacks, then explained several solutions, ultimately selecting the most optimal
• Explained runtime vs. space trade-offs within the context of different product constraints

3 Points [Leaning Hire]

• Produced a naive algorithm that properly utilized common data structures
• Fully explained or coded a slightly more optimized solution
• Correctly evaluated O-notation for runtime and space

2 Points [Leaning Don’t Hire]

• Selected sub-optimal data structures for the given problem, demonstrating minor misunderstanding about their inner workings
• Produced a naive algorithm and perhaps suggested improvements

1 Point [Strong Don’t Hire]

• Selected poorly suited data structures for the given problem
• Demonstrated lacking knowledge about the inner working of basic data structures
• Struggled to expand past a naive algorithm

3. Problem Solving

4 Points [Strong Hire]

• Rapidly produced a well written and accurate solution with ample time to deep dive into supplementary problems or alternative solutions

3 Points [Leaning Hire]

• Solved the problem and had limited time to briefly discuss additional problems or expand on their original solution

2 Points [Leaning Don’t Hire]

• Barely finished the problem in the allocated time
• Either moved slowly or made several incorrect attempts before arriving at a final solution

1 Point [Strong Don’t Hire]

• Did not finish the entire problem
• Often became lost and were unable to progress without assistance

4. Communication

4 Points [Strong Hire]

• Clearly explained their solution while also demonstrating tangential knowledge by explaining the inner workings of the standard library and data structures they used
• Explained the pros/cons of various common approaches to sub-problems within their solution

3 Points [Leaning Hire]

• Explained their thought processes very clearly
• Failed to elaborate fully on the design and rationale behind algorithmic/coding decisions

2 Points [Leaning Don’t Hire]

• Explained their thought process, but would meander when they became lost in their solution
• Sometimes fell silent while they thought

1 Point [Strong Don’t Hire]

• Spent little to no time explaining their thought processes
• Interviewer had to actively prompt the candidate with questions

5. Thrives in Ambiguity

4 Points [Strong Hire]

• Was able to work independently
• Accurately discussed edge cases early
• Engaged in thoughtful discussion by providing several solutions and challenging common assumptions/answers

3 Points [Leaning Hire]

• Required minor hints
• Asked a few good questions
• Handled unforeseen edge cases once they became clear

2 Points [Leaning Don’t Hire]

• Required several major hints
• Unclear if they could have progressed without assistance
• Did not engage in thoughtful discussion regarding the problem

1 Point [Strong Don’t Hire]

• Struggled to work independently
• Did not attempt unfamiliar problems
• Relied heavily on interviewer for direction

6. Values Feedback

4 Points [Strong Hire]

• Incorporated feedback quickly
• Tried to understand the feedback on a deeper level
• Challenged the feedback where appropriate

3 Points [Leaning Hire]

• Incorporated feedback quickly
• Did not challenge or seek to deeply understand the feedback

2 Points [Leaning Don’t Hire]

• Incorporated feedback, but slowly and didn’t demonstrate satisfactory understanding of the feedback

1 Point [Strong Don’t Hire]

• Blindly ignored or made little use of hints

The technical interview is only one side of the coin. The other side is the behavioral interview.

The Behavioral Interview

The behavioral interview is a series of questions to find out if you’re a good fit for the job. The goal of this interview is not necessarily to see if you can do the job, but rather, if your experience qualifies you to do it. The goal is to find out how you’ll perform by analyzing examples of how you performed in similar situations before.

The behavioral interview doesn’t only benefit the interviewer. This is an opportunity for you to practice:

• Communicating the value you bring to the company.
• Showcasing your qualifications, talents, skills, and communication.

How to Prepare

It’s a huge mistake to go into an interview without having done your research on the company. Here are some actions to take beforehand:

1. Analyze the position and the company.
2. Identify your experiences and skills that are most relevant to the position.
3. Prepare a few scenarios that demonstrate teamwork, communication and leadership, etc.
4. Identify your strengths and areas where you can improve.

What Will They Ask?

The questions your interviewer will ask aren’t random. I mentioned that they are trying to see if you’re a good fit. They’re trying to figure out how well you’ll handle inevitable situations on the job. This means they want to know if you’re able to overcome challenges, handle setbacks, be a team player, make decisions, etc.

The following are common situational categories and the questions that they may ask for each.

Teamwork

• Do you like to work independently or as part of a group?
• Tell me about a challenging interaction with a team member.
• If I called your teammates, how do you think they would describe you?

Challenges

• Tell me about a challenge you faced while working on [portfolio project].
• Describe a time when you had conflict with a team member. How did you resolve it?

Failures

• Tell me about a difficult failure you experienced. How did you handle it?

Mistakes

• Tell me about a mistake you made. What happened and what did you learn from it?

Decision Making

• Tell me about a time when you had to make a tough decision.

Learning

• Describe a time when you had to learn something that was difficult for you. How did you approach it?

Tech

• What’s the hardest bug you’ve ever solved?

Achievement

• What is your greatest achievement to date?

Fun/Oddball

• If you were allowed to bring only 3 things to an island, what would you bring?

When answering these questions, do your best to be as specific as possible. It’s also important to avoid placing blame, especially when it comes to the mistakes category.

Fortunately, there is a well-tested technique to help you give excellent answers.

The STAR Technique

This technique will help you prepare clear and concise responses using real-life examples. Let’s break it down.

First, the interviewer will ask the question. Listen carefully and think of an event to use in order to illustrate your answer. Then, apply the STAR technique.

STAR stands for: situation, task, action and result.

Situation: Describe the event or situation you were in.

Task: Explain the task you had to complete.

Action: Describe the specific actions you took in order to complete the task.

Result: Close with the results of your efforts.

Here’s an example of the STAR technique in action.

Interview Question

Have you assumed a leadership role before?

Your Answer

S — Yes, I have. A developer on my team had to leave for 3 weeks due to personal circumstances and we were weeks away from a big release.

T — To make up for his absence, I knew we had to reassign the team’s tasks in order to meet the deadline.

A — I took the initiative to evaluate everybody’s tasks and see how we could make up for the absence as a team. Then I scheduled a meeting with the team to delegate the new tasks to keep us within schedule.

R — Almost everyone agreed to the change since it was a major release and we all understood the importance of it.

Follow up with lessons learned: I learned some people don’t like being assigned tasks on such short notice. I’ll communicate earlier next time if a similar situation arises.

By using this technique, you’ve fully addressed the question about leadership while demonstrating that you can complete a large task competently. And on top of that, you’ve shown that you can take feedback and learn from it. You’re showing rather than telling, which is key to acing the behavioral interview.

Interview The Interviewer

The interviewer is trying their best to gauge whether or not you’re a fit for the company. You should be doing the same exact thing. Try your best to answer:

Is this company a fit for me?

Here are some questions you can ask in order to better understand the company’s culture and to get a handle on what the day-to-day responsibilities would be:

• Could you describe a typical day or week in this position?
• Can you show me examples of projects I’d be working on?
• Where do you see this company in the next 3 years?
• What would you say is the biggest problem that the engineering team is facing today? What about the company as a whole?
• Do you have any office traditions?
• What was the last team event you all did together?

These are only a few examples. Try to ask questions specific to the company. Ask questions that don’t have a quick google search answer. Be curious!

Non-verbal Tips

There are several pitfalls you can become victim to that are unrelated to the content of the interview itself. Make sure to not miss these:

• Show up early. Get there 15 minutes early.
• Dress appropriately. You may not need to wear a suit, but don’t be sloppy.
• Firmly shake the hand of your interviewer.
• Greet your interviewer by their name.
• Have good eye contact.
• Have good posture.
• After the interview, follow up with a thank-you email.

This last tip also applies to life in general,

No matter who you are interacting with, treat them just as you would the CEO. A bad impression with an intern, recruiter, HR person, janitor, etc., can hurt your chances at landing the role.

And Finally…

Congrats! You’ve reached the end of the guide. I hope you found this helpful. Feel free to comment below with any questions you have about anything discussed here. Finally, I’ll leave you with some insight that I wish I had before I started applying:

Don’t apply when you feel ready. The worst thing you can do is convince yourself that you should apply to jobs only when you have the right number of projects in your portfolio or only when you feel like you have mastered all of the topics in Cracking the Coding Interview. Interviewing at companies is the best way to prepare for interviewing at companies. That seems obvious, but may not always feel so when you’re in the midst of studying for these interviews. Don’t let perfectionism block you.