Nailing the Tech Interview

@deniseyu21

Congratulations!

You've made it to the tech interview stage. This is a big deal!

Components:

• Technical questions

• Pairing interview

This talk is not about

• Take-home technical assessments
• Technical CVs

Keep in mind:

• You've made it out of the pile, and it was expensive to get you here. But still...

• Preparation matters!

December, 2014

• Just finished MA

• Never had a tech job

• Flubbed tons of interviews in past life

• Had 56 days (incl. xmas and New Year) to get a job before...
  DEPORTATION

Cold, hard truth #1:

No one cares if you're a
Jack-of-all-trades.

Master one language,
one web framework,
one test framework.

(maybe a JS framework too.)

After MA, I liked...

I wasn't too fond of...

It doesn't matter what you choose in the tech interview.

The important things that you will be judged on...

How fast can you get 'Hello world' up and running?

How well can you debug?

Do you have basic Test Driven Development skills?

How well can you communicate what you are doing, and why?

Cold, hard truth #2:

You're going to be asked questions you don't know, and can't prepare for.

BUT...

At this stage, storytelling will help you out a lot.

Don't panic if you don't know the answer.

The hardest question I've ever been asked...

(paraphrased):

"Say that in a Rails application, you have thousands of users who can book appointment slots. What happens if two users, at the same exact time, try to book the same slot? Assume each slot accommodates only one user."

How would you respond?

The interviewer didn't
expect me to know the answer.

What did I say?

1. I know that Rails uses ActiveRecord, so I would read ActiveRecord documentation.

2. Comb Stack Overflow.

3. Try to find similar use-cases. Perhaps Ticketmaster or Eventbrite have an engineering blog post about a similar problem.

4. Try to replicate the problem in a test environment and investigate.

(in case you care, the correct answer lies in docs on ActiveRecord::Transactions.)

The worst thing you can say...

"I don't know."

...UNLESS you have a follow-up.

"I don't know, because I've never extensively worked with databases. Sounds like it's worth it to learn a bit more about the tools we use for data persistence, so I'm going to read up on it when I get home."

"I don't know, because I have never written a web application in Clojure before. However, functional programming sounds like a cool way of thinking, and I'm keen to practice it on my next side project. Can you recommend some resources I should look at?"

"I don't know, but I'd like to understand the business use case for this feature. Do we want to prevent double-booking simply because Rails gets confused? If that is the case, then perhaps we need to investigate increasing booking capacity before building a limiting architectural feature that could constrain future development."

Demonstrate that you understood the question and are curious to learn more.

Use the opportunity to communicate something new about yourself.

It's OK to not know.

It's less OK to be clueless and uninterested in problem-solving.

Tell stories.

Don't stop at "I don't know."

Cold, hard truth #3:

It might not be enough to be an amazing developer.

The reason why they brought you in...

The interviewer is assessing whether you are someone he/she would like to have as a colleague.

You need to convince the interviewer that you can do the things that successful developers do.

Demonstrate that you understand the business domain before starting to code.

Be curious.

Be empathetic.

Be humble.

Be willing to seek help.

Advocate for maintainable,
readable code.

Don't compare yourself to your cohort.

Don't stress about your code samples.

(Imposter syndrome is real, and it's OK.)

Don't speak negatively about your past experiences.

Be the kind of developer you would want to work with.

It doesn't hurt to...

Read coding blogs

robots.thoughtbot.com/

www.sandimetz.com/blog/

devblog.avdi.org/

blog.8thlight.com/

developers.soundcloud.com/blog/

Listen to podcasts

https://thoughtbot.com/podcasts

https://changelog.com/podcast/

http://www.codenewbie.org/podcast

and so many more...

Go to conferences and meetups

Watch recorded talks

These talks made me a better junior developer:

'Boundaries', Gary Bernhardt

'All the Little Things', Sandi Metz

'Simple Made Easy', Rich Hickey

Learn a functional language.

(Seriously! It makes you better at OOD.)

Learn a bit of Vim.

(or emacs, if you have a lot of free time...)

Do an online course on computer science fundamentals.

Get to know developers outside of your bootcamp.

Build a side project every month.

Start mentoring before you think you're ready.

Give a technical talk before you think you're ready.

(and post it online and link to it on your CV)

Keep teaching and learning, everyday.

Questions?