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.
- These are my experiences
- I've only had 2 programming jobs (and had 4 interviews)
- YMMV
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
- 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
- small company will probably have:
- 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.
- this will affect the dynamics of the company.
- 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.
- 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
- 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?
- 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)
- 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'- 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
- 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
- TSV book recommendations parsing
- given a
.tsvfile (like.csvbut 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
- given a
- 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.
- Cracking the coding interview by Gayle Laakmann McDowell
- This is mostly oriented towards whiteboarding/CS stuff
- I haven't read it but it's super highly regarded
- Think like a programmer
- Uses C code for examples, but the thinking still applies.
- TodoMVC
- TodoMVC is a site that describes how to build a simple todo app in many different frameworks. Each one has a link to a repo with sample code, so you can see what a small app requires to get started.
- https://github.com/h5bp/Front-end-Developer-Interview-Questions
Nobody knows everything - beautiful!