Preparing for software interviews as an underprepared graduate
August 10, 2016 3:32 AM Subscribe
I will be starting the last year of my CS degree (combined BS/MS) this fall, which means recruiters are already starting to contact me. And I feel extremely not ready.
I go to a top 10 college, in the top 25 for CS. There's a lot of recruiting on my campus from Amazon, Google, etc. My GPA is good. I did well in algorithms (one of my favorite classes).
I have a feeling I'm one of the infamous "academics" who flubs technical interviews, with my name on a forthcoming publication but frankly terrible coding/software skills, and a lack of instincts when it comes to tackling interview problems. I know there are resources, like Cracking the Coding Interview, which I just ordered, but on top of everything else I have terrible nerves and I am awful, absolutely awful, at talking through problems out loud and the Fermi questions that usually get asked at places like Google.
On top of that, I don't really have competitive internships, since I spent most summers working in my research group. (I have a couple small-time internships from around the time I first decided to do CS instead of math.) I could optionally stretch my degree slightly and try to get a cool internship next summer, and graduate the fall afterward. It seems like graduating students have a certain edge in interviews with top companies, so maybe this is worthwhile?
So, besides practicing the heck out of algorithms and other practice coding questions, how can I prepare for interviews? Can I even get better at Fermi questions? How much better at actual coding languages do I need to be? I know they ask questions like "what's your language of choice? How would you improve it?" which, uh.
Maybe I need more experience building things? Anyway, advice is much appreciated.
I go to a top 10 college, in the top 25 for CS. There's a lot of recruiting on my campus from Amazon, Google, etc. My GPA is good. I did well in algorithms (one of my favorite classes).
I have a feeling I'm one of the infamous "academics" who flubs technical interviews, with my name on a forthcoming publication but frankly terrible coding/software skills, and a lack of instincts when it comes to tackling interview problems. I know there are resources, like Cracking the Coding Interview, which I just ordered, but on top of everything else I have terrible nerves and I am awful, absolutely awful, at talking through problems out loud and the Fermi questions that usually get asked at places like Google.
On top of that, I don't really have competitive internships, since I spent most summers working in my research group. (I have a couple small-time internships from around the time I first decided to do CS instead of math.) I could optionally stretch my degree slightly and try to get a cool internship next summer, and graduate the fall afterward. It seems like graduating students have a certain edge in interviews with top companies, so maybe this is worthwhile?
So, besides practicing the heck out of algorithms and other practice coding questions, how can I prepare for interviews? Can I even get better at Fermi questions? How much better at actual coding languages do I need to be? I know they ask questions like "what's your language of choice? How would you improve it?" which, uh.
Maybe I need more experience building things? Anyway, advice is much appreciated.
Do your problem sets and projects on paper/whiteboard first and talk to yourself as you're doing them. Get used to writing your ideas down rather than typing them. Practice with humans as much as you can, but practice on your own too.
posted by mskyle at 5:34 AM on August 10, 2016
posted by mskyle at 5:34 AM on August 10, 2016
Locate the ACM chapter's International Programming Contest practice session and attend religiously every week.
See here
It will be ridiculously frustrating for the first 2 months. Stick with it, try for a spot on the regionals team. Learn the hack pack. Hang out with the team members on the regionals team.
You will rarely fail a coding interview again, you will be friends with people that will move into Google, IBM, etc., and you will be heavily recruited straight out of school.
posted by pdoege at 8:53 AM on August 10, 2016 [1 favorite]
See here
It will be ridiculously frustrating for the first 2 months. Stick with it, try for a spot on the regionals team. Learn the hack pack. Hang out with the team members on the regionals team.
You will rarely fail a coding interview again, you will be friends with people that will move into Google, IBM, etc., and you will be heavily recruited straight out of school.
posted by pdoege at 8:53 AM on August 10, 2016 [1 favorite]
1) Those kinds of questions are usually poor predictors of work place success.
2) That said, the industry as a whole remains stubbornly fixated on those kinds of questions
It really comes down to reps and practice. If your goal is to work at a place that fetishizes this kind of interview, you need to find a way to get those reps in. pdoege's suggestion of programming contests is a great one because it weaponizes this kind of question at a level beyond what you'd find in typical interviews.
FWIW (and not the question you asked), but you should be looking for places that are actively asking you to give multiple solutions to a given problem, then asking you to evaluate why one solution might be better than another, and to describe the contexts and inputs that would motivate selecting a given solution. That's a very different way of using these kinds of questions than seen in most technical interviews as those are generally treated as a puzzle solving exercise. Places that suck (which is most places) don't care if someone got the right answer simply because they've seen that specific puzzle before, or if they derived it in real time - all that matters is they got it.
posted by NoRelationToLea at 11:12 AM on August 10, 2016
2) That said, the industry as a whole remains stubbornly fixated on those kinds of questions
It really comes down to reps and practice. If your goal is to work at a place that fetishizes this kind of interview, you need to find a way to get those reps in. pdoege's suggestion of programming contests is a great one because it weaponizes this kind of question at a level beyond what you'd find in typical interviews.
FWIW (and not the question you asked), but you should be looking for places that are actively asking you to give multiple solutions to a given problem, then asking you to evaluate why one solution might be better than another, and to describe the contexts and inputs that would motivate selecting a given solution. That's a very different way of using these kinds of questions than seen in most technical interviews as those are generally treated as a puzzle solving exercise. Places that suck (which is most places) don't care if someone got the right answer simply because they've seen that specific puzzle before, or if they derived it in real time - all that matters is they got it.
posted by NoRelationToLea at 11:12 AM on August 10, 2016
What do you mean a lack of instinct? I know plenty of research people who never thought they could write production code, but are fine at it; I, with my multiple industry internships, couldn't do a whiteboard interview for my life (nerves, and the contradictory dgaf of having an offer from internship) in senior year.
You'll be fine; interview a lot, practice with friends, do leetcode.oj. Don't be afraid to code a "naive" solution first, since some working code is better than none; then analyze the algorithm and discuss optimization if you can.
posted by batter_my_heart at 11:19 AM on August 10, 2016
You'll be fine; interview a lot, practice with friends, do leetcode.oj. Don't be afraid to code a "naive" solution first, since some working code is better than none; then analyze the algorithm and discuss optimization if you can.
posted by batter_my_heart at 11:19 AM on August 10, 2016
Maybe I need more experience building things?
You need more experience building things.
posted by brennen at 12:37 PM on August 11, 2016
You need more experience building things.
posted by brennen at 12:37 PM on August 11, 2016
As others have mentioned, practice in the same environment that you test - stand at a whiteboard to and talk out loud (even if you're alone).
The best advice I have for interview candidates is to "teach the answer". It's very important to share your thinking, explain clearly not only what you're doing but also why you're doing it, and to acknowledge alternative approaches and why you choose this approach that you're implementing on the whiteboard. For many people, taking the attitude of teaching also helps them get over the interview/
Always write down the question (on the whiteboard, up in the corner), and make sure you understand it. Ask clarifying questions (define the requirements) about the problem to be solved. Make sure you understand the edge cases and limits.
Then go back to the question when you're done and walk through your answer, checking that it actually solves the problem. Create your own example data if you need. Too many candidate never check their work and miss obvious logic or coding errors.
Draw pictures! It helps get you and the interviewer on the same page wrt to your solution, and helps you clarify your solution as you're implementing it.
Code to an outline - this is called "top down design", and is generally the easier approach, it allows you to defer complicated stuff while you figure out the main logic. As you get more detailed, the complicated parts become smaller, and soon you're done! It's also easier to write the complicated parts when you know exactly what you need. Coding is all about breaking big problems into little problems.
posted by jpeacock at 9:32 AM on August 13, 2016
The best advice I have for interview candidates is to "teach the answer". It's very important to share your thinking, explain clearly not only what you're doing but also why you're doing it, and to acknowledge alternative approaches and why you choose this approach that you're implementing on the whiteboard. For many people, taking the attitude of teaching also helps them get over the interview/
Always write down the question (on the whiteboard, up in the corner), and make sure you understand it. Ask clarifying questions (define the requirements) about the problem to be solved. Make sure you understand the edge cases and limits.
Then go back to the question when you're done and walk through your answer, checking that it actually solves the problem. Create your own example data if you need. Too many candidate never check their work and miss obvious logic or coding errors.
Draw pictures! It helps get you and the interviewer on the same page wrt to your solution, and helps you clarify your solution as you're implementing it.
Code to an outline - this is called "top down design", and is generally the easier approach, it allows you to defer complicated stuff while you figure out the main logic. As you get more detailed, the complicated parts become smaller, and soon you're done! It's also easier to write the complicated parts when you know exactly what you need. Coding is all about breaking big problems into little problems.
posted by jpeacock at 9:32 AM on August 13, 2016
« Older How do you spot a dud in an otherwise terrific... | My father doesn't approve of my fiancée -- how to... Newer »
This thread is closed to new comments.
If you're good at algorithms and enjoy studying them (which you should do), then the other part of the equation is communication and presentation skills.
This blog post by Steve Yegge has good advice.
posted by As the space-crow flies at 4:51 AM on August 10, 2016 [3 favorites]