Will Whiteboard for Pay
Interviewing for jobs has been quite the experience for me, and probably in more insidiously negative ways than positive. Before this year, I definitely looked at technical interviews as a meritocratic way of selecting the best candidate for a development role. I knew the process was a game, but I thought our ability to solve these algorithmic puzzles were an accurate indicator of how competent we were as computer scientists. I practiced these problems from Cracking the Coding Interview, Hackerrank.com, and did mock interviews with upperclassmen. I started feeling really good about my ability as an engineer. It all came to a point when I went through the interview process at Facebook for an internship, and got the offer.
I was, unsurprisingly, super proud of myself and naively thought this meant I was a great software engineer. I was going to take the skills I learned and honed over the past few months to Menlo Park and kill it there.
When I got to Facebook, I woke up. I was put on a team that worked on iOS; I didn’t have any mobile experience. I had to learn how to use their proprietary front end and backend APIs on my own in addition to learning Objective C and MVC. Wait a second, I thought, where were the DFSes and the binary trees? Where do I use Dijkstra’s? Why did they ask me about all those things during the interview if I wasn’t going to use them? It was rough.
I left Facebook feeling defeated, but definitely wiser. My naivety didn’t serve me well in Menlo Park, but it allowed me to learn and develop a fresh perspective on what it means to be a software engineer. Leaving Facebook I felt like 10x the software engineer that I was going in. I also gained a new perspective on how effective technical interviews really are.
During the fall of last year, I felt many of the same opinion expressed by Quincy Larson. I became disillusioned with whiteboard coding and algorithmic coding. I knew I wasn’t going to use any of this when I work, so why am I asked to do these questions? I was definitely frustrated by the process not only because of the questions that were being asked, but also because I was doing really poorly on all of them.
I wasn’t sure what the problem was, but the mojo I had when I interviewed last cycle was all gone. I was getting interviews with some pretty big firms, but not ever moving past the technical phone screens. The frustration of not doing well was compounded by my opinion that these questions didn’t really show how good of a software engineer I had become. What made me even more annoyed was that interviewers would never give me any feedback on what I needed to improve on, despite my asking. If I wasn’t good enough for your firm, is it against your interest to help me improve so that I may one day join your firm? The frustration snowballed and really threatened to throw me off track.
Then one day, it ended. Over break I went and interviewed onsite for a startup. I knew startups usually look for more experience, and wasn’t expecting much. I thought I performed how I normally performed, so again I wasn’t expecting much. Then they called me back and gave me an offer. Oh, I said. I guess that’s it.
At the end of it all, I still agree with Quincy Larson and Dan Luu (I definitely experienced some bias because of my school). The interview process is better than just random behavioral questions and Fermi estimation questions (dear Lord). But really, shouldn’t a better assessment of skills consist of questions related to the actual work experience? Like take home assignments or questions about work situations and experience? I think the industry is starting to realize that the current system, while ethical, is not that effective, and turns away more qualified employees than unqualified. I am starting to see a shift towards more relevant interview processes so I guess I’ll have that to look forward to in my career.