10: Print "Hire me" 20: Goto 10
October 17, 2012 6:15 AM Subscribe
I have an interview for my dream job next week, help me not screw this up.
I'm getting flown out for an interview at my "dream job" in a few days. Getting this job will allow me to move somewhere I want to live, work in an industry I want to work in, and start my career. So naturally this is incredibly important.
My mindset going into any job interview, in order to take off the pressure, is that "I don't need this job" and indeed, I don't. I already gainfully employed and the pay is pretty good. But the stakes are higher here.
The interview itself is at a software company, I'll be meeting with at least 5 people, and the interview is expected to take 3 hours. I'm not quite sure I have that kind of stamina. I've read through "programming interviews exposed" a few times and I've done programming interviews before, but never with that kind of length.
My biggest fear is that there will be a bunch of trivia questions about the programming language used, or that they'll ask me to crank out some code on the spot (although I regularly crank out code just for fun). I've heard of instances (at other companies) where they'll bring in a senior programmer to basically pepper me with questions to find my "breaking point", which seems silly to me. I dread having to say "I don't know"
Nearly every conversation I have about the industry I'm in gets me kind of excited, so I'll talk about problems I'll have and how I solve them (or not), or other things that interest me. If the interview were basically a series of these, I'd probably get the job.
I'd like to just treat this as a visit, rather than an explicit examination. Is it the impression that counts more than just knowledge?
To prepare, I'm going to study the more of the intricacies of the programming language I use, along with some other CS stuff I need a refresher on, but what else could I do to prepare?
I'm getting flown out for an interview at my "dream job" in a few days. Getting this job will allow me to move somewhere I want to live, work in an industry I want to work in, and start my career. So naturally this is incredibly important.
My mindset going into any job interview, in order to take off the pressure, is that "I don't need this job" and indeed, I don't. I already gainfully employed and the pay is pretty good. But the stakes are higher here.
The interview itself is at a software company, I'll be meeting with at least 5 people, and the interview is expected to take 3 hours. I'm not quite sure I have that kind of stamina. I've read through "programming interviews exposed" a few times and I've done programming interviews before, but never with that kind of length.
My biggest fear is that there will be a bunch of trivia questions about the programming language used, or that they'll ask me to crank out some code on the spot (although I regularly crank out code just for fun). I've heard of instances (at other companies) where they'll bring in a senior programmer to basically pepper me with questions to find my "breaking point", which seems silly to me. I dread having to say "I don't know"
Nearly every conversation I have about the industry I'm in gets me kind of excited, so I'll talk about problems I'll have and how I solve them (or not), or other things that interest me. If the interview were basically a series of these, I'd probably get the job.
I'd like to just treat this as a visit, rather than an explicit examination. Is it the impression that counts more than just knowledge?
To prepare, I'm going to study the more of the intricacies of the programming language I use, along with some other CS stuff I need a refresher on, but what else could I do to prepare?
Don't be afraid to say "I don't know". Nobody knows everything.
Have you read Steve Yegge's post about interviewing at Google?
Although it's four years old, they still follow much the same pattern. You're a bit late for the in depth revision he advises, but it's probably worth doing some whiteboard coding practice.
posted by pharm at 6:33 AM on October 17, 2012 [1 favorite]
Have you read Steve Yegge's post about interviewing at Google?
Although it's four years old, they still follow much the same pattern. You're a bit late for the in depth revision he advises, but it's probably worth doing some whiteboard coding practice.
posted by pharm at 6:33 AM on October 17, 2012 [1 favorite]
Also? If they're a good company, even though it's a tech job, they mainly want to know about your behavior. Are you a jerk. Do you lie. In what ways are you honest. How do you communicate. Do you share credit. Are you fun to be around. Do you have humility. Do you laugh. How do you do on teams, in pairs, and on your own. Will you fit into, and bring something to, the culture of the firm.
So brush up on your behavior, too. Think about experiences in your life that you can relay that explain you. And practice never fudging anything ever.
People hire people they like. (That is a good and bad thing.)
posted by RJ Reynolds at 6:47 AM on October 17, 2012 [3 favorites]
So brush up on your behavior, too. Think about experiences in your life that you can relay that explain you. And practice never fudging anything ever.
People hire people they like. (That is a good and bad thing.)
posted by RJ Reynolds at 6:47 AM on October 17, 2012 [3 favorites]
pharm: Don't be afraid to say "I don't know". Nobody knows everything.
Agree fully with that, but in an interview, it is important to say, "I don't know, but if I needed to find out, I'd go to [website] or check [reference work] or call my old buddy [buddy] who has [expertise] or I'd check with my manager/coworkers to see who the guru in the office is for this kind of stuff. It sounds like it might be similar to [thing you actually know something about] though, and the time I fixed the problem with the [thing you fixed] by [how you fixed it]. Am I on the right track?"
Like a politician in a debate, if you are asked a question you can't answer, always try to shift it to a question you can answer.
posted by Rock Steady at 6:48 AM on October 17, 2012 [5 favorites]
Agree fully with that, but in an interview, it is important to say, "I don't know, but if I needed to find out, I'd go to [website] or check [reference work] or call my old buddy [buddy] who has [expertise] or I'd check with my manager/coworkers to see who the guru in the office is for this kind of stuff. It sounds like it might be similar to [thing you actually know something about] though, and the time I fixed the problem with the [thing you fixed] by [how you fixed it]. Am I on the right track?"
Like a politician in a debate, if you are asked a question you can't answer, always try to shift it to a question you can answer.
posted by Rock Steady at 6:48 AM on October 17, 2012 [5 favorites]
Ask for a break when you need it - maybe about halfway through. This can let you use the restroom, take a drink of water, and just re-collect. Figure out what you said that went well, what didn't, and how to reconfigure things.
Plan on having some bullet points about what makes you the best damn candidate for the job. Hit on those over and over again.
posted by entropone at 6:52 AM on October 17, 2012
Plan on having some bullet points about what makes you the best damn candidate for the job. Hit on those over and over again.
posted by entropone at 6:52 AM on October 17, 2012
I'm with @RockSteady on this one. Explain your reasoning, explain how you would go about finding out. One of our standard interview questions really has no answer (it involves a blackbox piece of code, so we can have it behave however we want), but tests how the applicant approaches problem at hand and one of the lasts answers ends up being, "I ask for help".
So to sum up, don't sweat saying I don't know. Be honest, but strategic. If asked something you don't know, say "I'm not sure, but I would imagine it works like this... But to be sure I would look it up." If asked to write a piece of code and you don't remember the particular syntax - "I don't remember the exact syntax, but in pseudo code it looks like this." If this company is worth working for, they'll accept those answers gladly.
Good luck!
PS: Do NOT forget to ask questions about the company, code and culture! And some light (honest) flattery never hurt anybody either.
posted by pyro979 at 7:11 AM on October 17, 2012
So to sum up, don't sweat saying I don't know. Be honest, but strategic. If asked something you don't know, say "I'm not sure, but I would imagine it works like this... But to be sure I would look it up." If asked to write a piece of code and you don't remember the particular syntax - "I don't remember the exact syntax, but in pseudo code it looks like this." If this company is worth working for, they'll accept those answers gladly.
Good luck!
PS: Do NOT forget to ask questions about the company, code and culture! And some light (honest) flattery never hurt anybody either.
posted by pyro979 at 7:11 AM on October 17, 2012
Why do you dread saying "I don't know"? How could anyone know the answer to every possible question in a computer programming related field? All it takes is a quick glance at the one-question-every-few-seconds activity on Stack Overflow to realize how vast and complicated computer programming is. As a hiring manager, I'd be more concerned about someone who thinks they know (or should know) the answer to every possible question since such a person probably either has inflated self-regard or is just clueless about the scope of knowledge possibilities.
You seem mostly focused on your core job function skills. You should also think about other things: communication skills, people/social skills (including teamwork skills, which are probably important in any computer programming job), the vibe you have (positive, energetic, etc. - and you did mention you get excited, and you should definitely let that show), the questions you ask about the job and company, body language (sit up and forward, don't slouch, and make good eye contact, etc.), etc.
I'm not sure why you think you wouldn't have stamina for a three hour interview. That concerns me because computer programming is demanding. Not sure if you want to elaborate on that point.
posted by Dansaman at 8:22 AM on October 17, 2012 [1 favorite]
You seem mostly focused on your core job function skills. You should also think about other things: communication skills, people/social skills (including teamwork skills, which are probably important in any computer programming job), the vibe you have (positive, energetic, etc. - and you did mention you get excited, and you should definitely let that show), the questions you ask about the job and company, body language (sit up and forward, don't slouch, and make good eye contact, etc.), etc.
I'm not sure why you think you wouldn't have stamina for a three hour interview. That concerns me because computer programming is demanding. Not sure if you want to elaborate on that point.
posted by Dansaman at 8:22 AM on October 17, 2012 [1 favorite]
In my experience, long interviews include breaks, and people are generally pretty friendly as you're getting passed around to meet various people. It does take some stamina, but it's really not so bad. You will be at the company for 3 hours, you will be "on" for 3 hours and being conscious of the impression you're making the whole time, but you won't be "interviewing" for 3 hours. Presumably you'll talk with your boss/manager, you'll shake hands with people more important than that manager, you'll spend a little while talking with someone in HR (who doesn't really have much say in whether or not to hire you, this is more an exchange of information), and you'll meet some of the people you'll be working with, project team leaders, etc. If you were sitting in the same room for 3 hours straight getting grilled like an oral exam, yes, that would take serious stamina, but this probably won't be so bad, you'll have a few minutes of down time.
As others have said, it's okay to have your mental answer be "I don't know". It's less ideal for your interview answer be "I don't know", but there are ways around that. Also, don't panic. I was once asked a really impossible question on an interview: I'd just given a talk about research I'd done at a synchrotron source, and this guy with impressive credentials from high-end schools says "those aren't electrons, they're positrons - I remember reading about it when the site was built." My mind boggled. Of course they're electrons, everybody at the site knows they're electrons. Oh, crap - he's totally just screwing with me. He knows there's no way I can prove it; the particles are identical except for charge, and charge doesn't make a difference when you're making x-rays. Crap. I'm so screwed. There's nothing I can do to argue this point. Wait, I bet there is. I bet there's some difference that he's waiting for me to say, it must be obvious, oh, craaaaap!! And then I calmed down and said "Well, to the best of my knowledge, they're electrons. I can't think of any way to test it, no machine features that would matter if charge was positive or negative; but since there's nothing I can do to prove it either way, we'll just have to agree that it doesn't make a difference to the discussion here, either." He seemed disgruntled - that was not the answer he wanted, I'd basically told him to go shove it, and I was terrified that I wasn't allowed to tell their scientists to go shove it no matter how polite I tried to be about it. So I went home and asked somebody at the site what was up, and she told me it had been designed for positrons then they decided to flip polarity and run electrons instead. Huh. When I started the new job a month later, turned out that question had kept them busy at lunchtime for 3 days straight trying to argue whether it was or it wasn't positrons and nobody could figure it out. The guy was not actually trying to trip me up. He was genuinely curious, was sure he'd remembered one thing and here I was telling him another, and he was asking me because I was the expert. He ended up being my project leader that first year; eventually I told him how much he terrified me that day, and he laughed and apologized.
Sorry for the long story. The moral here is: stay calm, trust your gut, don't get upset if someone asks for the impossible. If there's a question you don't know the answer to, say why you don't know and how you could find out. The one thing you don't know is often only one small piece of the overall question they're asking. If you can say something to demonstrate that you understand the question and the context of the question, that you have all sorts of information relevant to the situation, but you can't give a final answer because you're missing one piece, that's almost as good as - or maybe sometimes better than - popping out the right answer without discussing it at all.
posted by aimedwander at 8:26 AM on October 17, 2012
As others have said, it's okay to have your mental answer be "I don't know". It's less ideal for your interview answer be "I don't know", but there are ways around that. Also, don't panic. I was once asked a really impossible question on an interview: I'd just given a talk about research I'd done at a synchrotron source, and this guy with impressive credentials from high-end schools says "those aren't electrons, they're positrons - I remember reading about it when the site was built." My mind boggled. Of course they're electrons, everybody at the site knows they're electrons. Oh, crap - he's totally just screwing with me. He knows there's no way I can prove it; the particles are identical except for charge, and charge doesn't make a difference when you're making x-rays. Crap. I'm so screwed. There's nothing I can do to argue this point. Wait, I bet there is. I bet there's some difference that he's waiting for me to say, it must be obvious, oh, craaaaap!! And then I calmed down and said "Well, to the best of my knowledge, they're electrons. I can't think of any way to test it, no machine features that would matter if charge was positive or negative; but since there's nothing I can do to prove it either way, we'll just have to agree that it doesn't make a difference to the discussion here, either." He seemed disgruntled - that was not the answer he wanted, I'd basically told him to go shove it, and I was terrified that I wasn't allowed to tell their scientists to go shove it no matter how polite I tried to be about it. So I went home and asked somebody at the site what was up, and she told me it had been designed for positrons then they decided to flip polarity and run electrons instead. Huh. When I started the new job a month later, turned out that question had kept them busy at lunchtime for 3 days straight trying to argue whether it was or it wasn't positrons and nobody could figure it out. The guy was not actually trying to trip me up. He was genuinely curious, was sure he'd remembered one thing and here I was telling him another, and he was asking me because I was the expert. He ended up being my project leader that first year; eventually I told him how much he terrified me that day, and he laughed and apologized.
Sorry for the long story. The moral here is: stay calm, trust your gut, don't get upset if someone asks for the impossible. If there's a question you don't know the answer to, say why you don't know and how you could find out. The one thing you don't know is often only one small piece of the overall question they're asking. If you can say something to demonstrate that you understand the question and the context of the question, that you have all sorts of information relevant to the situation, but you can't give a final answer because you're missing one piece, that's almost as good as - or maybe sometimes better than - popping out the right answer without discussing it at all.
posted by aimedwander at 8:26 AM on October 17, 2012
Come prepared with good questions to ask the interviewers. Even with the last interviewer, have a good question or two to ask.
Don't be afraid to ask for a bio break.
The purpose of "asking questions to the breaking point" is twofold: see how deep your knowledge goes and see how you handle stress. Find a way to keep from getting flustered.
Don't ever lie -- if you don't know the answer, don't make it up. Especially for technical interviewers, this is a deal breaker.
posted by elmay at 9:15 AM on October 17, 2012
Don't be afraid to ask for a bio break.
The purpose of "asking questions to the breaking point" is twofold: see how deep your knowledge goes and see how you handle stress. Find a way to keep from getting flustered.
Don't ever lie -- if you don't know the answer, don't make it up. Especially for technical interviewers, this is a deal breaker.
posted by elmay at 9:15 AM on October 17, 2012
Saying "I don't know" isn't a bad thing. I recently got a job at a place that had a similar place (in fact, it could be at the place you're applying for all I know, as I had a very, very similar setup for the interview process. Is there a lot of focus on the ethical/moral side of the company? Does it require a LOT of travel?)
One of the reasons I got the job was because they asked me about a time I had failed, and I had multiple examples to pick from, and let them know as much. When I got the job, the interviewer who asked me that question let me know that so many interviewees don't want to admit to making mistakes in interviews; they think it makes them look bad. In reality, they wanted people who didn't try to bullshit their way through the process, people who knew they were human and made mistakes and were going to make mistakes at their new job, if they got it. And who were big enough to admit that. So don't sweat being imperfect.
posted by nushustu at 11:29 AM on October 17, 2012 [1 favorite]
One of the reasons I got the job was because they asked me about a time I had failed, and I had multiple examples to pick from, and let them know as much. When I got the job, the interviewer who asked me that question let me know that so many interviewees don't want to admit to making mistakes in interviews; they think it makes them look bad. In reality, they wanted people who didn't try to bullshit their way through the process, people who knew they were human and made mistakes and were going to make mistakes at their new job, if they got it. And who were big enough to admit that. So don't sweat being imperfect.
posted by nushustu at 11:29 AM on October 17, 2012 [1 favorite]
Sorry, I forgot to add:
If this potential job sounds similar to the company I described, memail me.
posted by nushustu at 11:30 AM on October 17, 2012
If this potential job sounds similar to the company I described, memail me.
posted by nushustu at 11:30 AM on October 17, 2012
« Older Goldilocks searches for a wedding ring | Blue? Only in color, Michael. Oh, also in mood. Newer »
This thread is closed to new comments.
Don't worry too much about knowing the language -- the hard bit of programming isn't about writing the code but working out what you want to write. Writing code on the spot is likely, though.
Definitely revise CS fundamentals. Off the top of my head, you should be able to name and write pseudocode implementing linked lists, graphs (matrix/list), heaps, and hashmaps, as well as talk about the worst/average case CPU and memory performance. You should also have the usual algorithms in your head -- binary search, a few dynamic programming ones, graph traversal and shortest path, ...
posted by katrielalex at 6:24 AM on October 17, 2012