On Hacker News, “hidro” asked:

How to keep yourself prepared for potential interviews?

There are a lot of things related to studying up on the company, learning about the problem they hope hiring you will solve, and so forth. I’m not going to address any of that, I’m going to talk about technical interviews, interviews where the stated purpose is to judge your technical aptitude and problem-solving style.

While I don’t aggressively preach “Walk out if they ask you an algorithm problem,” I also don’t preach “Study for algorithm problems.”

Trust that they are sincerely looking for the way you approach a problem and that they are judging the way you respond to something you don’t know off the top of your head, rather than judging whether you know the problem off the top of your head.

(They might actually be doing a bad job of interviewing, but you can’t control that, so don’t worry about it.)

I believe that if today is Sunday, and you have an interview on Monday, there is actually no point in trying to study something today. Whatever you already know, that’s what you know. What you want to do is be the best possible you in the interview. And studying the night before is counterproductive:

1. It actually reminds you how little you know. When you study something with no particular interview in mind, you get a little boost of endorphins. You learned something! But when you study something the night before, you get the opposite effect: You don’t know this! And you might be missing something important! And theres something else you ought to learn! And Oh God, it’s one in the morning!
   
   
2. Studying is hard work, and even if you get a good night’s sleep after studying, your brain is still trying to integrate what you just “learned” into what you already know for some time, possibly weeks. So you can regurgitate things the next day, but you haven’t learned them to the same level.
   
   I believe it’s better to say, “Oh, yeah, I know of Red-Black Trees, but I don’t know them,” than to display a superficial familiarity based on a night of study. A good interviewer will quickly root out that you don’t know them that well. Better to read about them when there’s no interview on the line, and let the knowledge truly soak in.

So if you aren’t going to study, what are you going to do?

1. Get a good night’s sleep the night before. And that means, no binge-studying, no trying to get ahead with your day job’s obligations to justify taking a half day off for tomorrow’s interview.
   
   
2. If they want you to bring a laptop ready to do some coding, set up a coding environment from scratch, possibly in another account where you won’t be distracted. Reboot. Turn on the do-not-disturb mode and quit all non-essential applications.
   
   Write FizzBuzz, compile it if that’s your gig, write some tests, make sure you aren’t yak-shaving in the interview trying to figure out why some gem doesn’t compile because __DEBUG has been removed from version 6.3 of your commend line tools under OS X 10.10.3.
   
   
3. Arrange your schedule such that you can arrive ahead of time without heroics. Try to be at a nearby coffeeshop an hour beforehand, spend the hour on Hacker News reading about things you find interesting, and walk in ten minutes ahead of time refreshed and thinking abut things that spark your curiosity.
   
   
4. Further to #2, sometimes on HN or other sites there are controversial issues that you care about. Diversity, whether PHP is a “real” programming language, drone strikes, whatever. The 24 hours before an interview are not the time to read them, share links on social media, or otherwise engage the fight-or-flight argumentative side of your brain.
   
   
5. This goes double for discussions about what is or isn’t an appropriate way to interview someone. Argue about that up to two days before an actual interview, then disengage the judgmental part of your brain.
   
   Whether consciously or unconsciously, people judge whether you seem to be antagonistic or constructive, and you want to come across as constructive when you disagree. Getting engaged with emotional “hot-button” topics in the 24 hours before an interview is exercising the wrong part of your disagreement skills.
   
   
6. The interviewer will offer you caffeine, so if you drink coffee, tea, coke, &c., do not have any in the hour before your interview. If you do have some at the coffee shop, either make it a decaf or ask the interviewer for a decaf beverage.

I think that if you walk into the interview with a sense that the things you know, you actually know, and the things you don’t know, you are comfortable saying, “I don’t know but I’m happy to work my way through the problem as best I can,” you will do as well as can possible be expected.

And further to that, if you accept that no matter what preparation you make, you can’t win them all, you will be more relaxed than if you have an idea that there is a right way to interview. Because if you think there is a right way to ask interviewing questions, and there is a right way to study for interviews, then if you aren’t offered a job, it’s somebody’s fault.

That turns the pressure up, and is depressing. Far better to accept that interviews are hit-and-miss, and if you miss, it’s no big deal, there’s another interview, with another company tomorrow.

So what about more than one day before the interview? Should you study algorithms? Or language constructs? Or anything else that interviewers seem to ask?

I think not. Or at least, not for the sake of an interview. Instead, discipline yourself to seek out books and blog posts and lectures that are technical. There is a vast difference between learning about Merge Sort because you think you may want to use it one day, and learning about Merge Sort because you were browsing Glassdoor and heard that Company X likes to ask about it.

Instead of setting aside an hour a day for practice, I’d say be curious about technical subjects, and when you run into something new—like generators and iterators when you’re reading about infinity—pause for a moment to write out some generators and iterators for yourself.

This is far more engaging than just reading, and as a pleasant bonus, if you do get asked about generators and iterators, you can always say, “I don’t use them a lot, but I read about them in a post on Hacker News about infinity,” and you come across as someone who is eager and curious, rather than someone who is trying to game the system by studying things they don’t actually know how to use.

All of this is JM2C, of course. The truth is, nobody really knows how to win this game every time, sometimes the best you can do is to play with dignity and style.

Good luck!