Job interviews can be tough. That goes double for technical interviews for roles like software engineer or web developer.
As you embark on landing your first programming job, you may come across some fodder from developers about how fundamentally wrong the interview process can be.
Jaded developers are more than willing to air grievances.
While I do agree with the flaws of some interview processes (it comes out from time to time in this post), your preparation will stem any anxieties.
During my initial job hunt after graduating from a coding bootcamp, I managed to land a good amount of interviews — which also meant I failed a good amount of interviews.
To help you avoid stressing out over technical interviews, here are 5 examples of the kinds of interviews I experienced.
The Dreaded Whiteboard Interview
Whiteboard interviews are perhaps the most loathed version of technical interviews.
Why?
Well, for starters, you don’t code on whiteboards. The argument is that it’s unnatural, and doesn’t reflect your standard working environment.
Fair enough. There’s a decent chance that whiteboard interviews are literally the only time you’ll ever write code by hand.
Personally, I think people hate it because you can’t Google the solution.
Also, I believe that part of it is the idea of standing up in front of your interviewees and presenting your thought process.
Let’s face it, the stereotype of the introverted developer has some strong roots. When someone that’s used to burrowing in with a hoodie and oversized headphones is asked to stand up and talk through their code, it puts them on edge.
Play this to your advantage. Developers work in teams — your ability to communicate effectively will be a deciding factor.
When practicing at home, find someone to present some coding challenges to. Stand up in front of them and explain how you would go about solving a coding challenge.
Assuming you don’t have a whiteboard, write it out on paper, or even screencast to a TV.
In short, don’t let your whiteboard interview be the first time you’re explaining code out loud.
That said, what does an actual whiteboard interview look like?
In my experience, whiteboard interviews consisted of two things. It was either to test my SQL knowledge, or to test me on algorithms.
But there was a catch.
In numerous algorithm whiteboard challenges, I couldn’t use the language’s built-in functions.
For example, in a Ruby interview, I was asked to reverse a string without using .reverse. As you could imagine, not using built-in methods/functions are a knock against coding interviews.
It sort of goes against the core philosophies of programming; but being asked to code an existing function from scratch is a good way to test your knowledge of loops array methods.
What to do when struggling in a whiteboard interview
I had warped perspectives about whiteboard interviews before I actually experienced one first-hand.
I envisioned that, upon getting my question, I had to immediately transcribe the answer while articulating my logic fluidly — a la Matt Damon in Good Will Hunting.
My ability wasn’t (and still isn’t) at that level. Don’t create unnecessary pressure. Take your time and communicate with your interviewers in order to make progress on the algorithm.
Keep in mind that whiteboard interviews are often fairly conversational. In my experience, as I was vocalizing my thought process, the interviewers would offer input about how my thinking was on track — or off-point.
Here’s a tip.
If you feel self-conscious about what you’re going to write, briefly square yourself up against the whiteboard to block your writing from the interviewer’s line of sight.
Taking those few seconds for judgement-free whiteboard coding helped because I could better evaluate my code when it was written out, as opposed to in my head.
Now, this tactic is beneficial if you feel under the gun. A better way to alleviate pressure is to be better prepared than I was.
In reality, I never would have felt the need to briefly block my code if I studied algorithms more, and made my studying time closely match the interview environment.
Recap: Whiteboard Interviews
Whiteboard interviews get some moderately-justified shade from developers. While they don’t reflect your coding environment, they’re a good test of your knowledge and communication skills. Like them or not, you’ll come across one in your next job hunt.
Prepare for them by studying algorithms, hand-writing code, and by working through problems in front of a soon-to-be-bored friend or family member. Again, don’t let the whiteboard interview be the first time you’re talking through an algorithm.
Hypothetical Web App Scaling
“ Say your web app gets very popular overnight. How would you handle the influx of the requests? “
You’ll get this question at any big company that you interview at. For me, it was BNY Mellon and Target. Organizations like these need to run their platforms efficiently because of the volume of requests they handle.
If you have experience with large scale applications, great — talk all about it. Now, they knew that I was coming from a coding bootcamp, so they were looking for a theoretical answer.
As I’m not employed at either Target nor BNY Mellon, you can guess that I didn’t have a good answer.
I said that you use a CDN (Content Delivery Network) to use geographically distributed servers to reduce request time, then use a load balancer to divvy up the requests within those respective locations.
At Target, I got a brief nod followed by some note-taking. At BNY, the interviewer looked at me with a “Go on…” face, followed by a “That’s it?” face — then he took some notes.
Always with the notes.
To have better results than I did, I’d suggest studying the following resources on scaling web applications:
Practice by taking these principles and applying them to an app or project that’s on your resume. Rehearse your answer by jotting down some bullet points or steps, and ideally, practice out loud.
Projects
Some interviews request that you complete a project of some sort. This typically happens after a phone screening interview. I got project interviews for full-time roles at Target and Ceros.
At Target, I was asked to develop a product page using React (it was a React developer job) based on a desktop and mobile mockup.
It was fairly straightforward. My only regret was not knowing about the wonderful CSS flexbox module — I would have finished it in half the time. Otherwise, no major bumps in the road.
Ceros was a different story. I had completed what I had been told was the final round of interviews for a web developer role. When I got a call from their HR team, I was expecting to hear whether or not I was hired.
Instead, I was asked to troubleshoot and add features to their coding project — a remake of the 1991 SkiFree game.
With the exception of some more modern sprites, the Ceros code challenge operated the same way as the original game. Or rather, it partially operated, and I was responsible for fixing bugs and adding features.
In fact, here are the actual requirements from the repo:
- Fix a bug:
There is a bug in the game. Well, at least one bug that we know of. Use the following bug report to debug the code and fix it. - Steps to Reproduce:
- Load the game
- Crash into an obstacle
- Press the left arrow key
- Expected Result: The skier gets up and is facing to the left
- Actual Result: Giant blizzard occurs causing the screen to turn completely white (or maybe the game just crashes!)
- Write unit tests:
The base code has Jest, a unit testing framework, installed. Write some unit tests to ensure that the above mentioned bug does not come back. - Extend existing functionality:
We want to see your ability to extend upon a part of the game that already exists. Add in the ability for the skier to jump. The asset file for jumps is already included. All you gotta do is make the guy jump. We even included some jump trick assets if you wanted to get really fancy! - Have the skier jump by either pressing a key or use the ramp asset to have the skier jump whenever he hits a ramp.
- The skier should be able to jump over some obstacles while in the air.
- Rocks can be jumped over
- Trees can NOT be jumped over
- Anything else you’d like to add to the skier’s jumping ability, go for it!
- Build something new:
Now it’s time to add something completely new. In the original Ski Free game, if you skied for too long, a yeti would chase you down and eat you. In Ceros Ski, we’ve provided assets for a Rhino to run after the skier, catch him and eat him. - The Rhino should appear after a set amount of time or distance skied and chase the skier, using the running assets we’ve provided to animate the rhino.
- If the rhino catches the skier, it’s game over and the rhino should eat the skier.
- Documentation:
- Update this README file with your comments about your work; what was done, what wasn’t, features added & known bugs.
- Provide a way for us to view the completed code and run it, either locally or through a cloud provider
I was not even remotely capable of doing it.
I’ve failed a lot of coding challenges. Unlike a TED Talk from a multi-billion dollar Silicon Valley entrepreneur, I’m not thrilled about failing this much.
I must have spent around 24 total hours working on it, and I only fixed one bug. I managed to, in my manic I’m-never-getting-a-job state, to only fix the first bug.
As the repo states, the game would break if the player hit the left arrow key after they crashed. It was breaking because the sprite for the crashed skier image was in position 0 of the array.
According to the controls, hitting the left arrow key would subtract 1 from the position of the array and show the n-1 position of the array.
Like I said, the crashed sprite was position 0, and 0–1 equals “error”.
I got that, and I started the jump functionality until I ran into my deadline. No jumps, no unit tests, and certainly no Rhino that chases you down and eats you.
Submitting my barely completed assignment, my morale equivalent to a deflated balloon, I hopelessly wrote out some pseudo-code about what I would have done to complete the remaining elements, then sent it in.
Can you guess where I never ended up working?
Why Developers Dislike Projects for Interviews
Projects come in all shapes and sizes. The one I had at Target seemed perfectly reasonable. The Ceros one, less so, but not unrealistic given that every dev that worked there had done it.
Sometimes, developers are given access to the company’s repos, website, etc. and are asked to do a project that could actually get used. It may be an item that’s lower on their priority list. Or it may be a project they recently worked on, and they’re seeing how your code compared to theirs.
The issue people have with that? You’re working for free.
The argument is, that if your work is potentially going to be published, you should be compensated appropriately — whether you get the job or not.
It seems reasonable to me. Your work is benefitting the company, you should be paid for it. Some places, in fact, do pay you for the work you do in interviews.
DuckDuckGo, a privacy-oriented search engine, compensates interviewees. DuckDuckGo was built on protecting the user, so this approach makes sense — but I wouldn’t expect it from most places.
If you get a project assignment as part of an interview, don’t ask if you’re being paid for it. It isn’t common, and companies that do pay for it will let you know (it’s a point of pride for them).
Preparing for Project Interviews
If you get a project or assignment as part of your interview, time and resources are on your side. In a sense, projects are the closest thing to the day-to-day job.
There isn’t much you can do for direct preparation, but in general your coding experience will get you through it.
If you’re wondering — yes, you could probably find solutions (or partial solutions) on Github or Stack Overflow. It’s common practice to clone their interview repo from Github, then push to submit it — so chances are someone has done it before.
If you’re stuck or out of time, I’m not going to tell you not to look online for answers. However, if you genuinely don’t know how to do it, chances are you may not be ready for the role.
Evacuate Manhattan
Yes, you read that right.
“You’re in charge of overseeing the evacuation of Manhattan before it floods entirely — what do you do?”
I was surprised, but not opposed. I had just botched a whiteboard round (and was about to stumble through another one afterwards), so I welcomed the hypothetical disaster scenario.
This one was asked at a chat-bot start-up called “Snap”. At the time, I think there were only 20ish employees, so getting eccentric questions like this one really comes down to the individual’s preference, and not some HR protocol.
Anyway, for the next hour, I was in charge of evacuating Manhattan.
I immediately get way too specific about evacuation routes (the only thing New Yorkers love more than New York is sharing their ‘immense’ knowledge of it). More seriously, I think I have a habit of looking too deeply into specifics right off the bat (see bikeshedding).
It’s safe to say that part of this round was to test exactly that. Oops.
Fortunately, the interviewer, who was the director of engineering, stopped me before I went into a rabbit hole. “Hold on. What’s the very first thing you would do?”
It put me back on track, and I reset myself and answered that I’d prevent any incoming traffic from entering Manhattan.
From there, we went through all of the viable transportation methods and made rough estimates on how many people could be transported in a given vehicle, and how many out-and-back trips public transportation could take.
What’s more, he guided me into making nice round estimates so the math was easy. “Say a subway car holds 100 people, and there are 10 subway cars, and a round trip to an outer borough takes 10 minutes”.
After establishing the very convenient evacuation rates, we touched upon some more nuanced topics. “What if the Transit employees aren’t feeling very heroic, and you’re concerned that once they make their first trip into safety, they’ll abandon their post?”
At this point, I was informed that the Coast Guard was involved (this disaster scenario had everything!) so I put the Coast Guard in charge of the transit.
With all of that out of the way, we had agreed that we had the entirety of Manhattan exfiltrated in what was the most tranquil and mathematically rounded evacuation in human history.
Phew. That was something else, huh?
Like whiteboard interviews where you can’t use a built-in method, any seemingly absurd interview question is testing a core principle at heart. Ultimately, a programmer is a problem solver, so at a high level (ok, very high level) this was testing that.
If you’re curious, or want to plan for every interview option that can be thrown at you, here’s how to evacuate Manhattan:
- Determine total population of the area you’re in charge of evacuating
- Stop all incoming traffic
- Assimilate exfiltration options (we settled on trains, subways, buses, and people walking across bridges)
- Determine how many people can fit in each vehicle, and how many vehicles can circulate in a given time
- Gauge how long it would take for the total population to be extracted
Yes, it was a bit random. But like I said, it’s just a different way to test your problem solving abilities without using code.
There isn’t much to do in preparation for these theoretical questions. Should you come across one, identify the key variables, then work at a high level before drilling into details.
Technical Phone Interview with a Non-Technical Employee
It’s common for any job interview that the first round will be through an HR employee. Sometimes, companies try to kill two birds with one stone by combining the initial cultural and technical interview.
On the upside, it’s an easy round. On the downside, it’s close to pointless.
I don’t mean to play the overly-opinionated developer card, it’s just that it doesn’t make sense to have a non-technical employee ask technical questions. It would be like putting me in charge of interviewing nurses — our areas of expertise simply don’t line up.
Typically they’re given a list of questions that, when answered, go in one ear and out the other.
Some actual examples from my interview experience include:
- “Do you code for the cloud?” (the role was for a Jr. Web Developer)
- “Can you make apps? We want Tinder, but for {industry that wouldn’t benefit from a dating app knock-off}.” (This was for my first contracted gig, a web developer role, and it only paid $15/hour)
- “Can you code JavaScript, Java, C, Go, PHP, and it says here, ‘Python’?” (It’s all too common for job description to list far too many languages — don’t be deterred)
- Prefacing every question with “Now, I don’t know what this means, but…”
Now, depending on your mood at the time, these can be either comical or just plain frustrating. With every ridiculous question I got, I felt less and less inclined to work at that given place.
Ultimately, that stress was unwarranted. I can guarantee that you’ll come across a technical interview by a non-technical interviewer.
Instead of rolling your eyes (please save that for phone interviews) take it as an opportunity to reinforce your learning by giving concise explanations.
If you feel your interviewer is non-technical (they will often admit this) treat questions as if you’re answering “Explain {concept} like I’m 5 years old”.
In your next job, not every person you talk to will be an engineer. This makes for good practice.
Preparing for All Types of Coding Interviews
With these real-world examples of coding interviews, I’m hoping you can better prepare for your next job hunt. Study your algorithms, and practice for whiteboard interviews by explaining your code out loud.
I really don’t think there’s such a thing as over-preparing for the variety of interviews you may get. For whatever time you put into preparation, it’ll be dwarfed by the payback you’ll get from being hired.
With that, I wish you the best of luck on your next interview!
Originally published at https://www.themarketingdev.com on November 11, 2020.
