There already is a book on "Cracking the Coding Interview", but not one for how to not totally flunk it.
This blog post assumes an interview for a job involving coding. Many server admin jobs, UI jobs, testing jobs, might not call for you to ever write a line of code.
If you don't know it say so.
I have never written a line of rust or so much as read a book about it. I know it is a programming language. I will not try to leverage that into solving a live programming puzzle in rust on a whiteboard.
If you don't know, say so, don't bullshit.
Better to preface it with, "I'm not sure but...." than to confidently bullshit as if no one will notice. The HR person might not notice, but techies will. And don't waste your breath on technobabble with the HR folk anyhow, even if it is actually true and coherent. HR wants to hear about successful past projects and happy customers, not the finers points of fdisk.
Go read up on the common questions.
They're on google. Interviewers suck at coming up with interview questions. Have a good canned answer for what a value type is and why you'd use one. Most people know the what x is, but not why. If you can answer both, it is really impressive. So a value type is on the stack. What benefit is that? What is the difference between stack and heap? What is an object? Why would you use an object over the alternatives?
Don't google for the answers during the interview.
The interviewer is also googling for the answer and googling the exact words you just used. If you don't know, but want to demonstrate how you'd find out in a real-world scenario, then say, "I don't know, but in a work setting, I'd google that" Not an impressive answer, but at least you don't come across as a liar and cheat.
Go practice the common interview question problems.
Fizzbuzz and reverse string are cliches, but virtually no one practices them, and too many people can't do either.
Interview puzzles generally rely on basic data types, are a problem that can be solved in one or two functions and involved some operators, loops and if statements.
The questions might be in the form of a unit test. No one cares that you are special and don't have to use test-first methodologies or to use automated testing in general. Learn how to write a basic unit test.
If you can solve it in programming language A but not B, offer to do so.
It is more impressive to watch someone solve reverse string in C than to write bad VBNET to try to solve it in C#.
Have some example code
No one gives a flying foik if your past code was on proprietary code bases and you can't share it. Bring some code you wrote as a side project, a learning project, anything legal, or better yet have a public github account with some code you wrote you can show off. It should be a small project, not some large sprawling thing.
While interviewers want to hear that you have worked on a large complex system, you can't demonstrate that by giving the interviewer a crash course on a complex system in 10 minutes. Pick a tiny part of it and show it off. You might be really proud of the 150,000 lines of code you wrote in a system with 1 million lines of code written over 15 years by 30 people, but at that point, the interviewer doesn't have time to understand what is going on or what part of that is yours. It just creates noise.
Don't give me the "I'm too senior for this shit"
If you're that hot of a developer, you probably will need to teach coworkers how to solve coding like this. If you're that hot of a developer, you should be able to solve the problem as easy as sneezing. If you really don't have the time, then get some portfolio code up somewhere and be ready to talk about it.
Use a linter
A linter looks for common coding mistakes. Pretty much every gripe and quibble that has ever happened in a code review has been implemented with linters. Immediately after you solve your coding puzzle, it will be code reviewed by a human linter. If you've ever worked with an automated linter you will be expecting 80-90% of the comments.
Don't gun for a job that is over your head, but don't be timid either.
You know you are gunning for a job over your head if you're bullshitting.
Don't panic if the problem is hard.
Some interviewers think they work at a FAANG company and are going to hire the top 0.001% of the smartest people to work for $60,000. Think about your competition, everyone else is going to flunk the hard question too.
Ask for a different problem. Do something. If it is a computer science question (Implement a black-red graph!), remind them that your degree is in 16th century English Poetry and you didn't take Algorithms or Data Structures.
Or if that is the sort of company you want to work for, go get "Cracking the Coding Interview" and study for 6 months (really, lots of people have posted their experience doing that). But for 99.99% of jobs, employers want to see you have the aptitude to write code in general, not that you can solve problems taught in computer science.
Think about the competition.
If someone is asking you to demonstrate recent & prolonged used of a brand new technology, you can be sure that no one has it if that tech has only been out for a few years. Better to say you have experience in something similar and learn fast than to bullshit.
Comments
Post a Comment