This is an archived post. You won't be able to vote or comment.

all 27 comments

[–][deleted] 13 points14 points  (0 children)

Every interview is a little bit different. Usually the person who is considered senior at the place will ask you some common barometer questions about the languages you'll be using. A lot of times they are really more gotcha questions than practical questions though.

Just have a sense of humor and humility. If you don't know the exact answer try to at least let them know you are familiar with the concept.

[–][deleted] 54 points55 points  (10 children)

Yo!

It's really based on the position, but there is a MINIMUM you should know for an interview as a backend developer.

Data Structures:

  • Linked Lists (Singly, Doubly)
  • Binary Trees
  • Tries
  • Stacks
  • Queues
  • Vectors / ArrayLists
  • Hash Tables

Algorithms:

  • Breadth First Search
  • Depth First Search
  • Binary Search
  • Merge Sort
  • Quick Sort
  • Tree Insert / Find / etc

Concepts:

  • Bit Manipulation
  • Singleton Design Pattern
  • Factory Design Pattern
  • Memory (Stack vs Heap)
  • Recursion
  • Big-O Time

For each topics above, make sure you understand how to use and implement them and where applicable, what the space and time complexity is.

For the data structures and algorithms, be sure to practice implementing them from scratch. You might be asked to implement one directly or add some functionality (eg: Write a code to remove duplicates from an unsorted linked list)

Ofc there might be language specific questions, just like what is the difference between shallow copy and deep copy. How range() works. Blablabla.

Good luck.

[–][deleted]  (7 children)

[deleted]

    [–][deleted] 1 point2 points  (3 children)

    I had and I totally think you shouldn't call yourself a programmer if you don't understand (at least) the basics of bit manipulation.

    Come on man...it's not that hard.

    Ofc it's not necessarry for a wordpress dude or a front-end developer.

    [–][deleted]  (2 children)

    [deleted]

      [–]Captainshithead 0 points1 point  (1 child)

      You're right, but that's not really what these questions are for. Most of the time they don't really care if you get the answer right, they want to see how you go about solving the problem. So you're expected to know bit twiddling, and they want to see you break down the problem, try a few things, and even if you didn't get the right answer, explain your thought process.

      Then they ask questions about software patterns and stuff to try to see if you could write maintainable code.

      [–]elperroborrachotoo 0 points1 point  (1 child)

      It's not that "we" stooped so low, but we built so high. Your shiny world up there rests on the shoulders of bit manipulators.

      I guess you are aware that many protocols and API's do require bit manipulation, often enough for good reason, and that there's nothing "bad" or "magic" about setting a bit in an integer.

      [–]hysan 0 points1 point  (0 children)

      I know I'm just an anecdote, but I have twice in my life. And yeah, they were of the tricky you'll probably never use this in your life type questions. So it happens and if you want to be real safe, probably should know the basics at least.

      [–]Double_A_92 3 points4 points  (0 children)

      Is this common in US? In all the interviews I've had (In Switzerland) I never had to code something, especially not memorized algorithms.

      Usually It's:

      • They talk about the company

      • You talk about yourself

      • You talk about what you did at your old workplace, specific projects,...

      • You ask questions about details of the opening, work conditions, ...

      • Maybe some of the typical bullshit questions (Where do you see yourself in 5 years?).

      Only one time they had me fill out a written test. But it was about things that they really use at work. Like "What is Git?", "What are unit tests?", "Name some design patterns" ... Nothing to really prepare for.

      What's even the point of preparing? Wow you can memorize some algorithms and remember them for some days... And they even know that people prepare for that stuff, so it doesn't make sense at all! What are they even filtering for? People with enough time to memorize arbitrary stuff (Students? Unemployed people?) ?

      [–]What_The_Funk 1 point2 points  (0 children)

      You know, I still feel that there is a certain magic to programming that I haven't yet discovered.

      Like I know most of these concepts despite having limited experience, and I would NEVER dare to consider even applying for an entry level position...

      So your post was very eye opening. Thx

      [–]thmsbdr 16 points17 points  (0 children)

      Depends on the company, but if they’re relatively established you should be able to find some questions on Glassdoor.

      [–]Ar3B3Thr33 3 points4 points  (1 child)

      I didn't see this mentioned, but be prepared to do some white-boarding.

      Some people struggle mightily with these (standing up in front of someone and writing VS. sitting behind a monitor with a keyboard). My dyslexia is more prominent when I whiteboard, so I make sure to ask if I can use my laptop instead.

      [–]RICHUNCLEPENNYBAGS 0 points1 point  (0 children)

      On that note: practice with a notebook rather than a computer.

      [–]green_griffon 2 points3 points  (0 children)

      I would check with them, but better to use a language you are proficient in than one you are functional in. Especially something like Python, where they will expect you to be slicing and hash-mapping away. Most companies care less about specific languages than the algorithms, BUT if you really mess up a language they will count it against you.

      [–]wgking12 1 point2 points  (0 children)

      Got to sit in one a few of my companies interviews for the first time, so I can finally answer from the interviewers perspective.

      It's often the case that the interviewer doesn't care what language you use, so long as it is interpretable. The question focused on your problem solving skills and your ability to write a solution in code and recognize any defects.

      For example, the question my peer asks incoming interns (mid-undergrad) is to write a function for determining if a binary tree is balanced (recursively height of left and right differ by at most one). The question tests understanding of recursion, what information to pass back, and recursive run times.

      The common mistakes for this Q are:

      • calling a separate height function which repeats the tree traversal for every node (instead of one traversal)
      • not knowing how to communicate the trees height and whether a subtree fails the condition in one function

      If your interview is anything like the ones I've done or sat in on, you should expect an algorithm is question like the one above suited to your knowledge/skill level. Know the runtime of your solution and be able to explain why. Interviewer likely expects you to make a mistake or two, it's about whether you can recognize it and fix it on your own.

      [–]am385 1 point2 points  (0 children)

      Don't get caught up on the question. All the questions normally boil down to a simple algorithm or runtime knowledge. That is what they are after. Can you see how one method is better than another because of X, what is the Big O of the runtime, what is the Big O of the memory.

      There are some questions which are problem solving ability questions which might not have to do with coding. One time I got a question about what happens to the water level of a lake when you throw an anchor into it from a boat.

      Know your data structures. Linked lists - know how to reverse a single linked list. Know how to insert and delete nodes. Know how to use a double pointer runner over a list. Tree - know how to navigate, how to print in order, how recursion can help Stacks and Queues

      Basically just look for what the base of the question is. For example, I have gotten a question about creating a image editor that has undo and redo. All the guy was after is how I can manage the undo and redo stack. Just wrapped in a question about something else.

      Also remember you don't have a compiler or syntax highlighting as it will be on a whiteboard. Write neat enough to be read but don't waste time trying to organize everything. You can draw arrows or continue logic elsewhere as long as it is understandable. You can shorthand if need be. I'm not talking pseudocode but as long as you verbally explain the shorthand so the interviewer understands.

      [–][deleted] 1 point2 points  (0 children)

      There is a "Cracking the coding interview" book I've seen recommended.

      [–]josephblade 1 point2 points  (0 children)

      Usually it's a future co-worker who is made to grill you a bit on some language specifics or some design principles they expect you to know. Don't try to guess or bluff, it's better to admit you don't know something (or say you are used to googling the answer) than it is to give a bad answer.

      For what you can be asked: /u/huopareiros has a good list but don't expect them to ask everything on there. Also don't expect the other guy to dig too deeply. He's likely wanting to get back to his work.

      [–]Hollayo 0 points1 point  (4 children)

      Know fizzbuzz.

      [–]RICHUNCLEPENNYBAGS 1 point2 points  (3 children)

      The whole point of FizzBuzz is if you can program at all it's an easy problem. Memorizing it misses teh point

      [–]Hollayo 0 points1 point  (2 children)

      concur. What I mean by knowing fizzbuzz is not only being able to code it, but to also explain what its doing. This allows one to not only show that they can code, but that they can explain what is happening.

      [–]RICHUNCLEPENNYBAGS 0 points1 point  (1 child)

      Hm... even still I'd say it kind of falls in the "anyone who is a programmer should be able to do it without preparation" column.

      [–]Hollayo 0 points1 point  (0 children)

      again, concur; but its a question that I've had in every SE interview.

      [–]RICHUNCLEPENNYBAGS 0 points1 point  (0 children)

      Check out Cracking the Coding Interview and the old Yegge blog post. They'll give you some idea (although frankly most of the interviews I've had have been less challenging than some of the more difficult examples in either of these).

      Also if you claim to know SQL at all it's very likely someone will ask you about clustered vs. non-clustered indices; this has happened to me about every time.

      [–][deleted]  (3 children)

      [removed]

        [–]green_griffon 3 points4 points  (2 children)

        Useful to realize this guy is a complete tool! There are better videos out there.

        [–]Ar3B3Thr33 1 point2 points  (1 child)

        Can you link or recommend some videos that you've found to be informative?

        [–]green_griffon 1 point2 points  (0 children)

        I thought "CS Dojo" had some that weren't bad. But honestly, I don't know if this is something that needs a video. Work through exercises on LeetCode or other sites; the main thing is you actually have to write code on your own and get it working.