• Behavioral
  • Least directly-focused section by applicants
  • Can, and should cause you fail a technical interview, if you pass the problem solving portion, but fail this section
  • Questions should focus on, but are not limited to, the following areas:
    • Why do you want to join?
      • Why do you want to join the company?
      • What is it about the role that you'd be taking on that you like?
      • How interested are you?
        • Interested enough to ask questions about what the interviewer does?
        • Interested enough to know a small amount of background info (e.g. a blog post you can ask about)?
    • Do you show potential for growth?
      • Are you self motivated?
      • Are you passionate about your interests?
        • How in-depth can you go about them? How long could you talk about them, if you had to give a lecture?
      • Do you constantly strive to improve?
  • Also affected by interviewee's questions
    • Are you asking questions?
    • Are you asking relevant, important, non-obvious questions?
  • General behavioral observations are important here, as well
    • Main reason for including video calls and on-site in interview process
    • Looking for "culture fit" and agreeability
  • Tips:
    • Be honestly interested
    • Don't be cocky or rude
    • Treat your interviewer as a person. Better yet, as a casual acquaintance

• Problem Solving (whiteboard questions)
  • Main focus area for most applicants
  • The most obvious indicator of how well you'll do on a technical interview
  • It is very important to describe your thinking process throughout this stage
  • Questions can focus on, but are not limited to, the following topics:
    • Recreating data structures with a twist
    • Showing an understanding of when to use data structures, recursion, specific algorithms, etc.
      • Data structures are almost always more important to know than algorithms, and you can find useful examples of what to know from both categories online
    • Dynamic programming (uncommon)
    • Networks of nodes (uncommon, except at specific companies)
  • Applicants should be able to give the runtime and space complexity of their solution, and describe how they got to that conclusion
  • These questions should generally be solved in under 30m each. This applies to the majority of questions you'll find online
  • Tips:
    • Focus on this section by practicing interview questions, and by asking friends to interview you, just as a technical interviewer would, and give honest feedback
    • Break problems into sections, then solve them
    • Try using a brute-force technique if you get stuck, then expand on it and make it more efficient
    • Test for unexpected sample inputs that match your input qualifications
    • If you get anxious during coding interviews, try one of the following:
      1. Don't get anxious
      2. Turn that par 30m into a par 25m to account for cycles lost worrying
    • For finding interview questions, try:
      • Careercup
      • Hackerrank
      • Your friends who have taken technical interviews and remember the questions asked
      • Googling some combination of the following ['swe', 'technical', 'interview', 'questions', 'cs', preferredLanguage]

• Technical Wisdom
  • This section somewhat tests for, heavily favors for, and is most easily passed with industry experience
  • Questions such as, but not limited to:
    • What was the weirdest bug you've had?
    • How would you go about debugging [x]?
    • How are [data structure] implemented internally in [language you listed first on your resume]?
    • Tell me about some interesting past projects that you've worked on
      • What problems did you encounter? How did you solve them?
      • What did it solve?
      • How did you design it to solve that? Why this way specifically?
    • Design [x]
    • What are the pros and cons for a microservice vs monolith architecture?
  • Tips:
    • Read MDN if you're going in for a javascript position
    • Have industry experience
    • Work on side projects
    • Talk to techies

• Technical Knowledge
  • Similar to technical wisdom, but it's the info you'd learn in class or textbooks, and not from experience
  • Questions basically follow the structure:
    • Explain [memory management, polymorphism, etc.]
  • Sometimes ask about OOP concepts (explain polymorphism, difference between overloading vs overriding)
    • In this case, they're generally found in place of the problem solving section in interviews for less desired positions
  • Often will ask position specific knowledge that you should know before starting, such as:
    • How does javascript handle async (for a frontend position)
    • How do network requests work? (usually scoped to a specific section)
    • How do you vertically center in CSS?
    • What are the differences between UDP and TCP and when would you prefer one over the other?
    • How does DNS work?
    • How do you exit vim?
      • Pro tip: never use it, just edit files using github's web editor
  • Tips:
    • Know your favorite language's internals
    • Understand the protocols relevant to your position
    • Understand how data structures are implemented
    • If you click the middle mouse button on Chrome, you can open links in a new tab. Go on Wikipedia, and do that on every moderately interesting link you see on the [DNS, JS, UDP, etc.,] page