Let’s say you went to the career fair.

You dutifully printed out 30 or so copies of your resume (not in the GDC, of course), wore your best clothes, and took the shuttle from Littlefield Fountain or Kinsolving to the Frank Erwin Center. You handed out your resume to a bunch of different companies ranging from the titans of industry to the startups raring for talented new coders. And now, the “we’ll get back to you in three to four weeks” period has passed, you’re getting anywhere from a handful to a massive wave of emails from recruiters trying to schedule you in for an on-campus interview (as you silently wonder why they offer a 9 AM slot and/or why anyone would take it), and you’re preparing for your interviews.

Maybe you’re reading Cracking the Coding Interview cover to cover and working out the problems for yourself. Maybe you’re solving every A- and B-level Codeforces problem you can get your hands on. Or maybe you’re brushing up on your 429 knowledge, making sure you can still subtract in two’s complement and predict cache misses. Ultimately, while all of this will help with the technical part of the interview (which, to be fair, does make up a significant portion of the interview), it will only get you so far. The rest of it is up to how you interact with the interviewer at a personal level.

Broadly speaking, interviewers rank candidates by three categories—technical skills, communication skills, and potential. Technical skills are measured by how well you answer the question—was your solution elegant, or did you end up writing a lot of meaningless spaghetti code? Realistically, though, that’s only part of the solution. The rest of it is centered on how well you can talk about your solution, and how well you can reason about where to go next when trying to solve a problem. If you can nail these two things, then for the vast majority of interviewers, you’ll do fine.

Basically, after a certain threshold, the question becomes less about whether or not you’re talented enough to work at the company and more about whether or not the interviewer would want to sit next to you at work. A lot of that means talking through your thought process as opposed to sitting silently, waiting for the solution to come to you in a flash of insight. (And if you do need some time to yourself, you should only do so if you ask the interviewer first.)

And it’s not just that people don’t like silence in a potential colleague. Even the most brilliant solutions need explanations—arguably, especially the most brilliant solutions need explanations, because they often rely on using standard techniques or data structures in decidedly non-standard ways. If you use a linked list to solve a problem that would at first glance use an array, you should definitely include details about your solution, because even if your solution runs in a fraction of the time using constant memory, it’ll be meaningless to the thousand people who might one day have to use your code in practice.

Ultimately, though, a lot of the interview process comes down to whether or not the interviewer likes you, and while you can do a lot to make them like you more, you can often get accepted or rejected just because the interviewer didn’t agree with your choice of coat color, or because you spoke too slowly or quickly, or because your handwriting looked funny to them. And while that sounds like it sucks, ask yourself if you really want to work for a company whose engineers discriminate based on these meaningless characteristics. Chances are that you don’t.

Which brings me to the last part of the interview. Companies don’t just want to know about what questions you have for them for the sake of making you let them talk about themselves for a bit. They care about how much you care about them—about how much working for them would excite you, and about how excited you’d be to show up to work every morning. That’s why you should prepare questions for companies you want to work for—not just so that you get a better idea of what working for them would be like, but because it shows you have an interest in what they do.

In the end, though, don’t put too much stake in how you think you did during an interview. I’ve had friends tell me they bombed interviews, only to get calls that night with offers, and I’ve had interviews I thought I aced, only to get the dreaded “Thanks from <company>” email two days later. Interviews are meant to test whether or not you’d be a good fit at a company, and chances are that if you don’t get an offer, you probably wouldn’t have enjoyed working there, no matter how nice their offer might have been. What makes or breaks a job is the people you work with and the problems that you solve. Keep that in mind as you approach your next interview or as you start prepping for interviews in the spring, and you’ll almost certainly find somewhere awesome to work.