Skip to content

Instantly share code, notes, and snippets.

@adityamulik
Forked from joelrojo/technical_interview.md
Created October 25, 2022 02:20
Show Gist options
  • Save adityamulik/47e41edb4d714a16e82591174c6d82be to your computer and use it in GitHub Desktop.
Save adityamulik/47e41edb4d714a16e82591174c6d82be to your computer and use it in GitHub Desktop.
Collection of resources for technical interviews, specifically Javascript and Ruby

Technical Interview Resources

General Guides/Practice

Whiteboarding

Good Reads

My Top Tips

1) Use the whiteboard efficiently and liberally.

Make efficient use of the board space by starting in the upper-left corner and working down and right. Leave space between your code lines. Writing in the center of the whiteboard is a waste of space and sometimes leads the you to awkwardly wrap code over to the left-hand side of the board. Show all of your work, even if you think it’s something obvious. This will help you visualize the challenge better, and allows the interviewer to observe your thought process, which is a major part of what they’re testing you for.

2) Talk and question. ALOT.

Take your time, ask a couple clarifying questions, and make sure you know what it is they want from you. While answering the question, think out loud. The interviewer wants to hear your thought process and approach. Draw on the whiteboard to express your thoughts. Diagrams, charts, numbers, whatever helps you. Often times, you will be judged on your thought process, regardless of whether you’re able to provide a solid answer. Seriously. Say, "Let's try doing it this way—not sure yet if it'll work." If you're stuck, just say what you're thinking. Say what might work. Say what you thought could work and why it doesn't work. This also goes for trivial chitchat questions. When asked to explain Javascript closures, "It's something to do with scope and putting stuff in a function" will probably get you 90% credit. Also, keep in mind that the interviewer wants to know what it feels like to work through a problem with you, so make the interview feel collaborative. Use "we" instead of "I,".

3) Be honest about what you don't know

Don't try to appear to know something you don't. Instead, say "I'm not sure, but I'd guess $thing, because..." The because can involve ruling out other options by showing they have nonsensical implications, or pulling examples from other languages or other problems. You’ll look worse trying to pretend as if you know what you’re doing, than you would admitting a particular challenge is new to you, and then applying the knowledge you do have to work it out anyway. Even if you don’t get it right, the interviewer will appreciate the approach.

4) Be confident, but not pretentious.

Keep in mind that being on the right track will always be better than giving up halfway. Think of the whiteboard interview as a way for the company to evaluate how you would handle difficult situations, so be yourself and you’ll get through it! And if you're feel like you're absolutely crushing the interview, refrain from coming off as overly confident or "know-it-all". You're being judged for your character as much as your intellect. No one wants to work with an asshole.

5) Maintain a positive attitude.

If you have a positive attitude, focus on learning skills that really matter and treat every interview as a life experience you intend to learn from, rather than being nervous about the outcome, you will win in the long term.

6) Ask the right follow up questions

The team’s workflow. Think about your experience coding with a team, and ask about protocols you followed to see if they match up.

  • “Does the team use Test Driven Development (TDD) to ensure the code is working?”
  • “How does the team perform code reviews? Do you use GitHub pull requests?”
  • “How will I as a developer be assigned specific tasks?”
  • “Am I involved in the sprint planning, or just handed off tickets like a cog in the machine”.

The company’s operations.

  • How will my day-to-day work impact the company’s vision of X”
  • How long of runway does your company have” [particularly for venture funded startups]

Technology decisions

  • Why are you using ruby on rails instead of java spring?”

JavaScript

Ruby

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