Every few months we go through the laborious recruitment process of SE Factory students. It’s a multi-staged interview that starts with an online application, followed by an on-site interview, and ends with a relatively difficult technical challenge. Given the hundreds of applicants we receive each cycle, we had to strip down the on-site interview to the bare essentials with a maximum duration of 20 minutes. During these 20 minutes the future 4 months (and possibly more) of a candidates’ life are decided based on a set of questions and responses.
We want to assess potential students for they have been trained on in their undergraduate level so we have design the interview to involve some basic questions about Data Structures, Relational Database Theory and Algorithms. Most of the candidates fail this part of the process and it’s not uncommon for students to get defensive and burp out horrendous statements such as:
“But I know X, Y and Z languages and I’ve never used neither Algorithms nor Data Structures in the projects I’ve done”
“I’ve worked professionally for X months and I’ve never had to implement a LinkedList or a Binary Search Tree or <insert Data Structure name here>”
“I took this course a couple of years ago, I forgot it all…”
“I graduated X months back but this was never part of our Computer Science curriculum”
To make matters worse, our questions are not difficult at all. They’re even quite far from puzzles or whiteboard problem solving, and generally revolve around having a discussion with the candidate to gauge whether they can vocalize the purpose of algorithms and data structures, and describe how a developer can estimate the space and time complexity of an algorithm. What else can one evaluate fresh Computer Science and Engineering graduates, who have not written a single line of code beyond their University projects, on?
A number of major technology companies (Google, Amazon, Facebook etc.) rely heavily on solving problems of an algorithmic nature during the interview stage to evaluate candidates. Furthermore, there is huge controversy in the software engineering community about the advantages of using Data Structures / Algorithm / Puzzle questions in the interview process to gauge the abilities of the interviewees.
David Heinemeier Hansson (DHH) is the “creator of Ruby on Rails, Founder & CTO at Basecamp (formerly 37signals), NYT Best-selling author of REWORK and REMOTE, and Le Mans class-winning racing driver.”
However, let’s not confuse the value of these questions during an interview with the importance of these areas in the career of a software engineer!
During the first few years of a software developers’ career (specifically web and mobile developers), one might be forgiven for not building capacity in these theoretical areas. In fact, many of us are explicitly instructed not to re-invent the wheel and just use existing solutions to get the job done. It’s true.
I have never implemented Bubble Sort or traversed a Binary Search Tree during my first 5 years of building software products and yet, as my career advanced I found myself tackling a wider array of problems whose solutions are not readily available on StackOverflow! I’ll explain:
- Recently I had to work on transforming data stored in a relational database to a Network visualization with named edges. Good luck solving that problem without having an understanding of Network theory and Trees.
- Does the application you’re building require that you send an email to a user after they create an account? Are you thinking of something along the line of: “I’ll just execute the send_email() method in my controller and call it a day”? Think again. While that might work for 5, 10, 20, heck 100 concurrent users, sooner rather than later you will reach a limit and the need to use a Queue will be inevitable. Here’s a twist, what happens if the email you’re sending has failed for whatever reason, how will you handle that?
- You’ve built an API for one of your web products and to everyone’s surprise within months you now have 100,000 requests made daily to your endpoints. Your server is crashing, it’s not able to cope with that number of requests, and your database resource utilization is off the charts! Adding new servers is not an option because your application isn’t designed to sit behind a load balancer AND you neither have the time nor money for those. Caching comes to the rescue, but then again, you don’t know what key/value (dictionaries) stores or hashmaps are.
The list goes on…
Sure, packages and libraries abstract a lot of the routine work we do on a day to day basis. However, rarely, but undoubtably, we stumble upon the problem that simply does not have a Googleable / downloadable fix and having a narrow arsenal of tools to pick from renders you hopeless in the face of the challenge.
At SE Factory we highly believe in the value of the fundamental topics of Computer Science and how developing an understanding of them helps in uplifting a developer from a mediocre calibre to a high valued asset across the years of service.
As such, we’re introducing a new recurrent program titled “Foundations of Computer Science (FCS)” which spans over a period of 4 weeks 3 days a week (Monday, Wednesday and Friday). During these weeks we will go over the building blocks of programming, Algorithms and Analysis, Data Structures, Object Oriented Programming, Relational Databases as well some selected topics in Filesystems and Networking all in preparation for our flagship Full-Stack Web Development program.
The first cycle of FCS will take place on January 15th 2018.
Thank you Mohammad Skafi for reading a draft of this post