Thread by @ASpittel

So, I've interviewed a bunch of software engineers, done some interviews myself, and teach my students about interviewing.

Here's a thread of advice 👇🏻

Interviewing looks different everywhere. Things you may encounter:

1) Behavioral interview questions such as: "What are your career goals"

2) Technical questions like: "Pretend I know nothing about React, explain it to me from 0" or "What is a float in CSS"

3) Whiteboarding or live programming challenges like the ones you'd find on @hackerrank

4) Takehome code challenges, where you're given a task to solve asynchronously

5) Pair programming challenges where you're working with one of the company's engineers to solve a problem.

I see a lot of questions about how to study for the algorithmic challenges that tend to come up in whiteboarding. Here's my advice:

First, to learn more about what data structures and algorithms are out there and what they're for...

I love @vaidehijoshi's BaseCS material which exists in so many formats now!

Blog posts: medium.com/basecs
Podcasts: codenewbie.org/basecs
Videos: dev.to/vaidehijoshi/l…

Cracking the Coding Interview also has really great primers if you have a higher base-level of knowledge.

While I was reading resources like these, I took my own notes and put them in a GitHub repository I could come back to:

github.com/aspittel/codin…

Taking notes allows you to have content in a format that works really well for you that you can come back to, plus writing it down cements the knowledge. These were originally handwritten notes that I typed up after the fact.

From there do a bunch of code challenges to practice. I used to do one every morning as I was waking up to warm my brain up.

I love codewars.com and @hackerrank for beginner - intermediate levels.

projecteuler.net is great for super mathematical problems.

If you're more advanced, I *love* the CodeJam problems: codingcompetitions.withgoogle.com/codejam

and #AdventOfCode adventofcode.com.

The problems in Cracking the Coding Interview are great too -- if you're starting out, translating the solutions given in Java to another language could be a great start.

During the interview itself, show how you think!

Explain your thought process, draw diagrams, write out the intermediary code, explain pitfalls in your approach, etc!

Be vocal, and ask clarifying questions.

That's part of being a good developer after all!

If you get asked a question like "Do you know React?" and you don't, be honest.

Don't lie and say you know something you don't -- it will be easy for them to figure out you're being dishonest.

But show a growth mindset -- "I don't know that yet, but I'd love to learn it --

I do know Vue which is also component-based, so I'm sure the transition would be smooth"

I'll close this out by saying that just because tech interviews are this way I don't think it's right -- a lot of these data structures and algorithms aren't used on a daily basis in most programming jobs, and the high pressure environment of interviews where you don't have

access to Google doesn't show off most people's full potential.

Also, interviews go both ways. If you have to jump through a million hoops that might be a red flag for what it's like to work at the company.

Hope this thread helps!!

Couple quick notes: not all companies have algorithm/data structures questions! I don't use them when I interview! That being said a lot of the FAANG/Unicorn companies do.

Second, I should have used a better example of a behavioral interview question, here's a list of some: pathrise.com/guides/45-beha…