One of the very first tech interviews I’ve ever had was with a French tech company. After passing their take-home project, I was invited to a technical screen that was supposed to take place over video with the CTO. However, when I joined the call, I realized the CTO wasn’t alone. He had brought three other engineers in what turned out to be a panel interview. This being my first foray into the world of tech interviews, I felt like I was facing down the barrel of a cannon.
To say I bombed would be putting it lightly. After 15 minutes, a handful of questions, and several stuttered answers, the CTO cut the interview short. He said he would deliberate with the other panelists and call me back after they had talked. However, the deliberation seemed more like a formality, as I received a callback not five minutes later telling me they wouldn’t be moving on with me.
I took the rejection as an opportunity to ask him about some of the questions I had struggled with and what answers they had been looking for. And to each question I asked about, he first responded with, “Oh, that was an easy question.” Being half-French, I can say that French people, particularly Parisians, aren’t known for being hospitable. But damn if nothing makes you feel crappier than a CTO implying you’re an idiot to your face.
I have a bone to pick with take-home challenges. I’ve never liked them. My biggest issue with them is that they’re a time sink. Every company underestimates how long they take to complete. It takes time to understand the requirements, set up the boilerplate, read the documentation, and then finally code the damn thing. But every interviewer just brushes those details aside and states, “It should only take a couple of hours.”
In 2018, I was interviewing with a company that tasked me with creating an entire full-stack, real-time chat application in just two days. If I had had a completely empty schedule, I might’ve been able to pull it off. But during a job search, where my day was filled with applying, studying, and interviewing, it seemed impossible.
But since I didn’t have a job, I wasn’t in a position to be too picky. So I acquiesced, hoping for a miracle. And lo and behold, a miracle was granted.
While researching web socket libraries that I could use to implement the chat feature, I realized Socket.io has a demo chat app with the code available on their GitHub. I ended up just copying the code from the demo and submitting it. The company was none the wiser, and I made it to the next round. Some may call this plagiarism, but I call it open source.
Unsurprisingly, that code challenge ended up being the start of the worst interview I’ve ever had.
Even when you do great on interviews and are given an offer, it’s not always sunshine and rainbows. I remember interviewing with one company and absolutely nailing it. I had breezed through all the coding challenges, and all the interviewers liked me. I had standing offers from other companies for other mid-level positions, but this seemed like a great match by all measures.
The hiring manager even told me that because of my other offers, they would go above their typical salary band. I awaited the offer details with bated breath.
However, when they called to formally give me the offer, it was for an entry-level position well below market rate by a good $20K and below my highest offer by $60K. I remember feeling bad for the other engineers who interviewed me. If this offer was above their salary band, they were all severely underpaid.
I thanked them for the offer but told them that it was too low and I was going to pass. But since I had done so well on the interview, they didn’t want to give up that easily. They upped their offer. They didn’t increase the salary, however, but tacked on 90,000 stock options.
The hiring manager promised that the company was considering going public soon and this stock package would be worth a lot. As tempting as it sounded, I still decided to pass.
So who wants this company with the lucrative stock package? I mentally refer to them as “All Stock, No Substance,” but you may know them as WeWork.
There will likely come a time during an interview where you feel the need to…improvise, so to speak. However, I always advocate for telling the truth and admitting when you don’t know something. An interviewer can always tell when you’re winging it and may call you out — though sometimes you may get lucky.
During a system design interview I had, the interviewer had me write out on a whiteboard how I’d architect a URL shortener akin to Bitly. Like any good interviewee, I started with the naive approach of a basic web server and database. When it came time to talk about scaling strategies for the database, I mentioned one approach was to use a cache, like Redis, to alleviate traffic from the database server and speed up data retrieval.
Taking the opportunity to test my knowledge of databases, the interviewer asked, “So why is Redis faster than a relational database?”
I had gotten this question a handful of times before and answered with my go-to response: “Redis is a key-value store, so it has O(1) retrieval of data.”
Most interviewers are satisfied with this answer, so I prepared to continue — but this interviewer wasn’t. He stopped me again. “Using JSON blobs and indexes, relational databases can attain an O(1) retrieval of data as well. However, Redis is still faster. Why?”
My mind went blank. I had never gotten that question before. I’m sure in the recesses of my brain I knew the answer he was looking for. However, at that moment, I couldn’t recall anything. And the longer I paused to think, the more the interviewer looked concerned. So I went with the only resort I could: bullshit my way out of it.
“Well….” I hesitated. “Not all O(1) solutions run in the same amount of time. Redis’s O(1) requires fewer steps. So it’s faster.”
Sensing that I was talking in circles and wasn’t going anywhere, the interviewer let out a small exasperated sigh. “It’s because Redis stores data in memory while databases store their data on disk.”
At the time, I was pretty green behind the ears and fuzzy on the differences between memory and disk. In an earnest attempt to learn, I asked the interviewer, “Why is in-memory faster than disk?”
“In-memory data is stored in RAM, which is physically located closer to the CPU. It takes fewer hops” — the interviewer momentarily paused, realizing what he was saying — “to retrieve data from RAM compared to disk.” Thinking that I had asked the question as a way to make a point, he added, “Touché.”
In my attempt to bullshit, I had inadvertently given an answer that was technically the truth. However, that didn’t prevent me from receiving a rejection email the next day.
For all the discussion of algorithms, data structures, and system design in interviewing, there’s one skill that isn’t discussed as much: time management. This especially comes into play when you’re juggling multiple ongoing interviews.
While balancing multiple interviews is a good problem to have, it’s still a problem. One strategy I employ is scheduling interviews to be close together. This way, I have a better chance to have multiple offers that I can use for negotiation leverage. In order to do this, I batch phone screens and recruiter calls on the same day to get them out of the way. The issue with this is that sometimes you end up with days full of phone screens, which is what happened to me during my last job hunt.
There was one day in particular where I had six phone interviews scheduled, three of which were back-to-back with another shortly after. Not wanting to be stuck in my apartment the entire day, I went to a nearby coffee shop. I took the three consecutive interviews there while downing plenty of caffeine and water. By the end of the last batched phone call, I had been at the coffee shop for an hour and a half. I decided to walk back to my apartment for my last interview of the day so that I could just relax on my couch afterward.
However, shortly after leaving the coffee shop, my bladder began to feel the effects of drinking copious amounts of caffeine and water. The pressure mounted slowly at first and then came like a tidal wave. Luckily I had just enough time to walk back to my apartment and relieve myself before taking the recruiter call. Unluckily, the recruiter called early.
Just as I was entering my apartment building, I felt a buzzing in my pocket and knew it was the phone screen. I thought about ignoring it, but I didn’t want to have to potentially reschedule the call for later, so I answered it. The call was only supposed to last fifteen minutes, so I figured I could just wait it out.
Five minutes into the call, I regretted my decision. The pressure had built to the point where I was having trouble thinking and responding to the recruiter’s questions. To this day I still don’t know why I didn’t just ask, “Hey, I need to use the restroom, can you hold on for a second?”
Part of it was my inability to think. The other part was I wasn’t able to find a natural pause to interject. The recruiter was giving me a spiel about the company’s background, and I didn’t want to interrupt them. So I went with Plan B.
I rushed to the bathroom and did all I could think of to mask the sound. I held the phone as far from me as I could, leaned as much into the toilet bowl as I could, kept the bathroom door open to dampen any echoes. I looked like I was riding a mechanical bull, except pants-less and ashamed. But like I mentioned before, I lived in NYC where the bathrooms are tiny and the acoustics are pretty decent. Despite all my attempts, there was no hiding the unmistakable sound of water running into more water.
The recruiter gave a brief pause, and I knew I’d been caught with my pants down — literally. Fortunately, they continued on as if they hadn’t heard anything, though with an air of disbelief in their voice. I had to give it to the recruiter, they were a true professional. The interview ended shortly thereafter, and the recruiter sounded just slightly too excited to get off the call. Unsurprisingly, I received a rejection email before the day was over. While I still feel a pang of shame whenever I recall this memory, it makes for an entertaining story for the both of us.