Landing a job can be quite hard, as I can attest from both sides of the table. I’m currently on the lookout for a job, and sadly I could not even land an interview. Should I get one though, I am pretty sure I would do well, and you can too. From my years of experience interviewing candidates, I believe I’ve developed a technique that’s guaranteed to help you seem like you really know about a topic, even though you don’t. I’ll demonstrate these techniques to you now, in the context of object-oriented programming.
When I interview people, I get really annoyed if I am given an answer that could have been ripped straight out of a textbook. Seriously, that doesn’t really show that you have an understanding of the subject matter. It just shows you can read and memorize shit. If that’s your only talent, then you’re in luck. I can give you some tips and catchphrases you can memorize while still appearing genuine. Before we proceed, let me give you a bad example:
Interviewer: Are you familiar with object-oriented programming?
You: Yes. OOP is a programming paradigm based on the business-concept of “business-objects”, which may contain data, in the form of fields, often known as attributes; and commercial code, in the form of procedures, often known as methods.
If that response looks like it was lifted straight out of Wikipedia, it’s because it actually is. I can guarantee that any interviewer hearing something remotely similar to this would immediately think you’re an idiot. Even if you do understand OOP, formulating your own description could be difficult. I mean, how could you do better than Wikipedia? It’s short. It covers the basics. What can you improve? My advise, just come at it from a different angle. I propose the following instead:
Interviewer: Are you familiar with object-oriented programming?
You: OOP? Yeah I know OOP. My OOP is SOLID as fuck!
General Tip#1: Mindful Cursing
I’ve never seen a textbook use curse words when discussing its subject matter. Cursing like this almost ensures that you will never be mistaken for someone who is spitting back the contents of a book. There have been legit studies that say cursing actually improves your persuasiveness and gives your audience a better impression of you.
Just keep in mind that the whole tip is Mindful Cursing and not just simply cursing. Get a read on your interviewer(s) before doing this. Don’t blame me if you get thrown out. If you try it and get a good reaction, don’t overdo it. Maybe one curse every two paragraphs worth of stuff would be sufficient. Like this: Stupid Asshole.
General Tip#2: “Leading” Answers
There’s such a thing as a leading question. It’s one that forces someone to answer in the way you want them to. Since you’re not asking the questions, you have to lead the conversation using your answers. The statement “My OOP is SOLID as fuck” is almost guaranteed to get a reaction from your interviewer. Whatever his reaction, you can then lead him to the topic you want to discuss. Here are some examples:
Interviewer: You seem very confident. How solid is your OOP?
You: Oh, I mean I follow the SOLID principles of OOP. I’m sure you can appreciate that.
Interviewer: Hmm. Tell me more about these principles.
Interviewer: Are you referring to the SOLID principles?
You: Yes of course. How quick of you to notice. I think every software developer should adhere to them.
Interviewer: And what are these SOLID principles?
In both cases, you’ve hijacked the conversation into the topic of SOLID, instead of allowing the interviewer to ask whatever his prepared questions are. Believe me, talking about SOLID in a technical interview would yield better results for you, than if you were to say differentiate Encapsulation and Abstraction, differentiate a Class and an Object, or some such basic shit that’s still liable to have you tripping balls.
What’s that you say? You don’t know what SOLID is? You haven’t used these principles before? Well I have you covered! It’s called “Fake it ‘til you make it”, is it not?
First, the boring stuff. SOLID stands for the following:
- Single Responsibility Principle (SRP)
- Open and Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
Unfortunately, you do have to memorize these terms. But don’t worry. Even if you list them out like that, plain as day, it won’t really sound like you’re reading from a book as long as you bring it when you dig deeper into each topic.
Interviewers usually have just a little time to spend conducting an interview, so it is unlikely for her to ask you to explain everything in detail. If you have one or two of these bad boys in your pocket, ready to whip out at a moment’s notice, you should be good to go. In a pinch, I’d go with the Liskov Substitution Principle (simply because I’ve already figured out how to discuss it inappropriately – the rest will follow).
For LSP, open your bit with:
What is it with people and their need to make catchy acronyms? Look at the “L” in SOLID. It’s Liskov Substitution Principle. How the hell would you remember that L stands for Liskov? Why couldn’t it just be called the Substitution Principle? SOSID still makes a good acronym, right?
This would show your interviewer that you’ve given a lot of thought into this. This kind of discourse does not just come out of the blue. And who the hell would take the time to write this shit on a blog, much less memorize it for an interview? Hooray for you. Believe me, it works. I tried it on my wife and I can boast a 100% success rate.
You now have some rapport with your interviewer. You’re welcome.
LSP simply says that you should be able replace one object with any instance of its subtypes without breaking your program. During an interview, you might be tempted to say something like:
To discuss LSP, let me first ask you: are you sexually active? What if you feel the need for your boyfriend’s dick, but he’s out of town and you’re feeling hot and horny? Well thanks to LSP, you can use my dick, and you’ll still get fucked. That’s because you just need a dick, and any kind of dick would do the job.
Do you think this would be an appropriate thing to say to your interviewer? Of course not. You know why? Because you simply described subtyping. It kind of misses the point of LSP. You’ve just shown how shallow your understanding of the principle really is, and how you’re not company material.
The textbook approach in discussing LSP is to ask: is a square a subclass of a rectangle? With LSP, the answer is no since the square only needs to define the length of one side in order to exist, while a rectangle requires length and height. This means replacing a rectangle with a square will result in catastrophic failure. If you haven’t figured it out yet, LSP is about asking yourself, “should I extend this class?”
Here’s your new hook. Go get yourself hired.
Succinctly, LSP makes you ask yourself if you’re extending classes properly. If it looks like a dick, moves like a dick, but needs batteries, you probably have the wrong abstraction Oh shit, did I say dick? I meant duck. Yeah, duck.