Skip to content

Instantly share code, notes, and snippets.

@jabyess
Created June 12, 2018 14:56
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jabyess/2240c856b72332ef5a56ea99acf50c4e to your computer and use it in GitHub Desktop.
Save jabyess/2240c856b72332ef5a56ea99acf50c4e to your computer and use it in GitHub Desktop.

Technical Interview Prep v2

Intro myself

My background

  • Always been a computer guy, but only been programming for about 4 years.
  • Was 27 when I got my first full time dev job.

Caveats

  • These are my experiences
  • I've only had 2 programming jobs (and had 4 interviews)
  • YMMV

Tech Interviews

3 types of coding interviews (usually)

  • take home (with or without a time limit).
    • all kinds of exercises.
    • these are usually the most involved, like build a small express or react app that does something.
  • in-person or remote session coding
    • usually limited in scope, problem solving focused, or live-debugging code
  • in-person whiteboarding
    • i hate these and always fail them
    • write a function to sort an array of integers
    • some big companies can use these as a weed-out step, so beware

Sometimes you'll just have to answer technical questions over the phone.

- What are 5 ways to hide an html element from the page?
- What's the difference between `<script>` and `<script defer>`?
- Difference between `==` and `===`?
- explain x concept

Where do you want to work?

  • size of the company is gonna affect the culture
    • small company will probably have:
      • more freedom, less structure
      • less process
      • wider range of projects to work on
    • larger company will probably have:
      • more structure, process
      • large, older applications (angular 1, java spring, rails)
      • clearly defined role, slotting you into one project/role
  • does the company focus on selling a product, or services?
    • this will affect the dynamics of the company.
      • product companies often make engineering decisions internally + have consistent processes
      • services companies (like agencies, consulting, political firms) sell their time, and the client often gets to make the calls because they pay the bills. but probably you get to work on lots of different things.
  • don't call yourself a junior. You're a developer.
    • take junior dev off your resume right now
    • let the company decide what role they want to put you in
    • you want to emphasize what you're willing to learn. Nobody knows everything.
    • you probably have some knowledge that others don't. The venn diagram of knowledge has overlaps.
  • remember that you're interviewing them!
    • makes you less anxious, less dependent on the outcome
    • be prepared with questions about the job and company
    • what's important to you? money? culture? tech stack? work life balance? benefits? process? mentorship/learning opportunities?
  • be okay with a bad interview
    • dc market is pretty strong for hiring
    • if the job doesn't feel right, don't take it. but also be realistic.
  • its not about knowing everything, its about being able to find the right answer
  • don't put it on your resume if you aren't ready to talk about it at least somewhat in-depth.

How to make it through when you're stuck

  • RELAX
  • Try to understand the problem. This is the hardest part.
    • What are they asking you to do? Are you sure?
    • What are you trying to do? Is it what they're asking?
  • Use whatever tools you know to start debugging.
    • HTML inspector
    • Network tab
    • REPL
    • console.log() everything.
  • Ask for clarification if you're not sure about something
  • Explain what you're trying to do
  • Google when you forget stuff that's easy to look up, like function syntax/usage/argument order
  • Don't google what they asked you right in front of them

What I look for as an interviewer

  • Understanding of the problem I've asked you to solve.
    • are you going in the right direction?
    • if you're not, are you asking for clarification?
    • Sometimes the instructions are intentionally vague to get you to drill down
  • Understanding of what you're doing, not just stabbing in the dark
  • How you deal with getting stuck (that's like 80% of the job!)
  • Can you walk through what you're doing (as you're doing it?)
  • When finished, can you explain why you did it that way?

Sample code challenges

  1. StackExchange API
    • build a site that logs you in to the SXC API using oAuth.
    • once logged in display a form that allows you to search the api for programming terms
    • search results should be listed on the page
    • click on a result and it takes you to the SO link
    • 4 hour time limit (hackerrank enforced)
  2. Ad/episode splicer
    • Given a set of inputs (ads and episodes), write a function to remove the placeholders from the episodes and insert the ads
    • Don't repeat any ads
    • Don't modify the "audio" (+ signs) in any way
    • Sample data (roughly):
const ads = { pre: ['Apple','Casper'], mid: ['Casper','MeUndies'], post: ['XYZ'] }
let episode = 'PRE+++MID++MID+++++POST'
  1. WordPress setup/post
    • Spin up an AWS instance, install WordPress on it
    • set up an API endpoint that accepts a string of HTML and publishes it as a new post
  2. reddit API ajax call/basic css card
    • use jquery/axios/whatever to make an ajax call to reddit.com/r/aww
    • parse the results, picking out a title, score, url, image, etc
    • make those results appear on the page in the style of a card layout
  3. TSV book recommendations parsing
    • given a .tsv file (like .csv but tabs), read it from disk
    • takes an input N (integer)
    • write a function that counts each book title & author (recommendation) and returns all books recommended N times

Keep learning

  • Coding should be fun. It's frustrating but rewarding.
  • You'll learn more deeply if you're having fun, and if you enjoy it.
  • Build something of your own that you're interested in.
  • Build a small app in one language or framework, then do the same in another. Compare how they work.
    • You'll start to realize that many of the problems are solved in similar ways. It'll help you recognize patterns.

Resources

@jdnichollsc
Copy link

Nobody knows everything - beautiful!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment