Even before my first day at UT, I thought I was set career wise. Set to work at one of those elite Silicon Valley companies that have 4 different brands of kombucha on tap and an indoor petting zoo. I thought I was set, because when I was visiting UT, a sophomore CS major boasted about how Google and Microsoft fought over him his freshman year. I thought I was set, because U.S News puts UT in its top 10 schools for computer science. I thought I was set, because the CNS career fair list was stacked with great companies, all hoping for UT students to come work for them.

Getting to UT was it. I was done. I put in enough effort in high school to now coast through the rest of my life. It was time to eat organic Himalayan salt popcorn in a nap pod while recruiters flirted with me on LinkedIn. And so, when recruiting season rolled around, rather than doing mock interviews or reading Cracking the Coding Interview, I salivated over obscene intern salaries and fantasized about what South Pacific island I would live on once I was rich. As a UTCS student, I'd obviously ace these interviews. I did open Cracking the Coding Interview once, actually. I checked out the first two chapters and saw they were about Arrays, Strings, and Linked Lists.

"Of course I know what a string is, these interviews should be easy."

I tossed it aside and headed to the career fair.

I strutted into the Frank Erwin Center with my arms outstretched in my ill-fitting blazer, waiting for a company to grab me by the hand and whisk me away to their swanky California office for an interview.

My confidence quickly decayed. Telling a company you were a freshmen is like telling someone you're on a first date with you have six kids. After several, "sorry you're just not my type, but feel free to take a shirt", I caught a glimmer of hope. My friend, an equally undesirable freshman, had just received an interview from a company (I'll call it company X). I scurried into their line, and after a 30 minute wait, a stone-faced engineer finally motioned for me to come over.

Disaster number one was the handshake. I looked at his outstretched hand, waiting to be shook. I was holding a cup of water in my left hand, my folder of resumes in other other, and was clutching unwieldy amount of swag under both my arms. After many excruciatingly awkward seconds of shuffling things around and dropping free t-shirts, I finally gave his hand a meek grasp so we could move on to me betraying my ignorance.

"So, Karthik, what do you know about company X?"

"Oh I've done a bit of research!" (I Googled them in line). "You guys do like, uh, trading stocks? Something something high frequency?" (Changing the details here).

"What? No. Not at all, actually. We're a..." (I was too flustered to hear the rest of this)

"Oh haha, right! That's so cool, that you guys, uh, do that. Here's my resume." I force my resume into his arms.

"Uh, ok. Before we get to that, I was going to ask you to..." (he flips my resume over and writes down a function signature) "...write a function that takes in a linked list and returns the kth to last element. I'll give you a minute or two, just come back when you're done."

"Oh ok, thanks!"

I stepped to the side. My obscene amount of sweat beginning to penetrate my blazer. Oh geez, why did I thank him, what I was thanking him for? I'm being way too peppy he probably hates me. I look at the function signature. Oh god. What was a linked list again? I should have asked him if it was singly linked or doubly linked, that would've sounded smart, I think. Or does that even matter? Oh no. I looked up at the interviewer, searching his face for a kind emotion that would make me feel more at ease. Instead, we made awkward eye contact, he shot me a confused stare, and I frantically looked away and drew a picture of a linked list to give the illusion of progress. After cobbling together some grotesque solution, I sheepishly returned to my interviewer, preparing to me roasted.

"Uh, so, I think I got an O(3^n) solution. So you have 3 hash maps right? And then in the first two for loops, you--"

"Yeah, I'm gonna stop you right there. Can you think of a simpler solution?"

"Uh, right now?"

"Yeah."

"Not really... could I get like 15 more minutes."

"Nah that's fine, I think we're done here."

"Oh ok, thanks!" And that was my horrifying first taste of technical interviews. I walked away wanting to die. I contemplated my incompetence on the bleachers until companies started packing up. You'd think this experience would make me take the process more seriously, maybe actually practice some interview questions. But instead I just thought, I know how a linked list works, I should have been able to solve that. Am I just bad at programming? Guess I'm not smart enough for company X.

The next week were spent opening up the latest HackerRank challenge that miraculously graced my inbox, passing 2/100 test cases, contemplating switching majors, and complaining to my friends about how I "just couldn't" pass a coding screen.

I knew what Cracking the Coding Interview was. Anyone who Google's "how to get tech job" for over ten seconds is going to know what it is. It wasn't a lack of resources or guidance that caused me to fail every challenge and interview presented to me, but the fact that I believed I "should" know how to quickly solve interview problems since I took classes that taught those concepts. I thought Cracking the Coding Interview was beneath me, when really if I had actually attempted any of the problems in the book, I would've quickly realized I had a lot of studying fundamentals to do. I'd given up all hope of on-site massages and nap pods and contemplated switching majors since I was "just really bad at programming", when really if I just prepared more, I definitely could've passed a few of the coding screens.

Well, fall recruiting was wholly unsuccessful for freshman year Karthik. In fact, I did so poorly that companies that interviewed me that first semester, where I actually didn't know anything, would go on to reject me the next year. One company, in addition to sending me three rejection emails after I failed the coding challenge, permanently put me as "In Progress" in their candidate application tracking service so every time I tried to apply in the future, a snide pop-up that said "You are already being considered" blocked my attempt, brutally reminding me of my past failures. (This is probably an HR mishap, but I wouldn't be surprised if it was on purpose—my interview went horribly).

I'll go into more detail on takeaways and spring semester failures in the second part of this post, but the major lesson I learned from fall semester was simply: study for your interviews. It seems obvious, but the feeling of "these interview questions are way too hard, so I'm not going bother studying" is a real sentiment among some people I talk to. Especially when you're a freshman and new to technical interviews, it might seem weird to have to study for an interview. Conventionally, interviews are conversations about existing abilities. You'd expect to be asked about your greatest weaknesses or maybe the pros and cons of your favorite programming language. But most technical interviews aren't like that. They instead rigorously test a specific subset of tricky problems related to data structures you cover in class, but not the of problems you'd really see in class. So, while you might know what a Linked List is, and can easily come up with the runtimes for inserting, deleting, and searching for a node, if you haven't familiarized yourself with these tricky Linked List interview problems and the common patterns of approach to solve them, you might still be stumped in the interview.

So, if you find yourself in a similar position as past me, don't doubt your abilities. What you learn in class doesn't directly map to what's asked in interviews, and a little bit of practice goes a long way with this.