The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
Hey everyone! I'm graduating after this semester, and I've started applying to jobs pretty regularly. I'll be graduating with a Bachelor's in Computer Science. Even though I've started applying only a week or two ago for jobs, I've already got two phone interviews scheduled for the next week or two. Both of them are for rather large, well respected companies, and I'm pretty sure there will be technical questions. I'm not really worried about normal interview questions, what I'm more interested in is what kind of technical questions might be asked over the phone. All of the positions I'll be interviewing for are Software Developer / Test Engineer / Back End type stuff.
I can't speak specifically for tech, but phone interviews usually tend to be very generalized. You shouldn't get code questions, etc., over the phone as it is a venue for them to determine if you're the sort they want to bring in to have a face-to-face with (which is where you'll get specific, technical questions).
When conducting phone interviews for new college hire (NCH) Software Engineers, I occasionally will throw in some very rudimentary technical questions specific to the job that I would expect a college grad to know. Simple stuff like STL usage, polymorphism, etc.
I would agree with @The Crowing One though that in general there shouldn't be too much on the technical front. They're trying to gauge if you're worth spending money on to bring to an on-site interview. Basically just be honest in your answers and try not to be full of bs.
Oh, one personal pet peeve of mine... when asked about things you have done make sure to actually talk about what YOU have done, not "this is what my team did". "I was on a team and did X, Y, and Z towards the goal of the project, which was this..." I tend to get a lot of folks that are very quick to talk about the projects they've worked on but can't seem to articulate what role they had in the team.
Yeah, don't get too worried about being asked detailed technical questions during the telephone interview stage. I just had a telephone interview a few weeks back (2nd job after graduating) and the most technical thing I was asked was what a virtual method was. They tend to save the deep questions for the face to face interview.
You're probably better off spending your prep time on other parts of the interview, like researching the company and thinking up a few good, solid questions to ask.
Disagree somewhat on the above, especially if the company is not local. If it is your first interview and it is with HR, it is probably a fit screen and relating your resume to your future job. However if HR has already talked to you and this phone interview is the first "official" interview (in particular if the interview is with a developer), then it may very well get more technical.
For the larger, more prestigious firms, they may go through 2-3 phone screens and at least one later one will definitely be technical. If they talk about setting up a Google Docs or Collabedit then you're going to be writing some pseudocode. Also, if it is a named company, it is worth googling for their interviewing practices - Microsoft and Google in particular are quite well documented.
Steam/LoL: plushycthulhu
0
Mike Danger"Diane..."a place both wonderful and strangeRegistered Userregular
Glassdoor can be a big help with what to expect if the company is listed on there. I ignored what it said about one interview I did and felt like an idiot, because half the questions I recognized from there.
Generally, a phone interview is a chance for us to see if someone has the passion for programming and games that we're looking for. We'll poke about technical details to make sure someone actually knows what they're talking about, but we're really looking for someone to jump at the chance to talk about what they've worked on. The phone interview is a chance for this person to convince us it's worth the effort to fly them out for an interview.
Our on-site is where we make people prove they're a good programmer.
When we did phone screens, the ones I liked the best were the ones that not only communicated well over the phone, but asked questions that showed they were really interested in the job. Look up information about the company ahead of time and ask some simple questions like "I see you guys did X, would I get a chance to work on something like that?". These same types of questions will earn you big points during the in-person interview, assuming you pass technical muster.
Also, it is OK to say I don't know to parts of a question. While you should have some amount of knowledge in your head, your thinking process is as important more or less. You can look up the specifics of the STL or how to program in Ruby or language of the week, but knowing how to arrive at an answer can be just as vital.
Note I'm taking this from a Software Engineering perspective, but this should overlap with most of the positions you look at.
Speaking as a software engineer who has been on both sides of the hiring process recently, you should absolutely be prepared for tech questions even if not every interview will involve them. However, for an entry level position the questions are not likely to be very involved - they'll probably be more for just weeding out the absolutely worthless candidates.
If tech questions come up, you'll probably be asked a couple questions about each intersection between what they use and what you've claimed on your resume. This means that if you don't really know anything about a subject, it shouldn't be on your resume just for padding. There tend to be some standard questions that almost everyone will ask about a particular language or skillset, and then each company might have additional questions. The less specialized the skill, the more questions will tend to be the same between companies. Some examples of standard questions I was asked a lot and have asked myself are below. You will notice a pattern in the style:
.NET:
- What is the difference between an interface and an abstract class? (This one gets asked for Java too)
- What is the difference between a class and a struct?
SQL:
- What is the difference between an inner and outer join?
- What is the difference between a WHERE clause and a HAVING clause?
If you don't know the answer to a technical question, say so. Under no circumstances should you try to stall and look it up. It's super-obvious when someone is stalling, and we can hear your keyboard. That's an instant-fail on an interview. If you know part of the answer, tell them that and then provide as much of an answer as you can.
For general phone interview advice:
- Go to the bathroom 15 minutes before they are scheduled to call. Similarly, eat beforehand. You don't want distractions.
- Make sure you are well-rested. You don't want to be yawning all over the call, or spaced out
- Ensure you are somewhere quiet. If your roommates tend to play loud dubstep, ask them to stop for the duration. Don't take it at the bus station.
- Have a copy of your resume in front of you so you know exactly what they're looking at.
Edit: And as Ganluan says, make sure you've got some questions to ask at the end. It's good to have a list of a few things you could ask any employer if they don't cover them, and better to have more specific questions.
JHunz hit it on the head. I'm in a very similar position (graduated college last year and have conducted numerous phone interviews where I work) and agree that you should be ready for technical questions. The one thing I would add is have a pad of paper and pen ready. For me, I do my best with technical questions when I can write down the details and requirements and look them over visually rather than try to remember it all in my head.
It's very possible that you'll be expected to psuedocode and handle some basic algorithms, but nothing you shouldn't have already covered in school. Be ready to handle more conceptual questions as well, such as talking about data structures and their uses, run time analysis, and general object-oriented principles (all of these will depend on where your applying and what matters to them). Talk through your thinking process. It'll help you organize your thoughts and also provide the interviewer a better idea of your thought process, which is really what's important at this stage. Finally, don't be afraid to ask questions if you need more clarity during the interview.
Rhapsody on
0
OrthancDeath Lite, Only 1 CalorieOff the end of the internet, just turn left.Registered User, ClubPAregular
I'm not US based, so take this with a grain of salt, countries do tend to have slightly different hiring cultures. But I am a Software Developer (team lead now technically) that does technical interviews when we're hiring new devs. We don't tend to do phone screens, we either get people in the office or if they are remote we do the full interview on skype. From what I understand the US tends to have a phone screen before the actual interview, so it's worth working out if this is a screen or the interview it's self. But either way take it seriously.
Now for the hard part. If you've just graduated you know nothing. I know you've just been through uni and think you've learnt a lot of stuff but when you look bak 5 years from now you'll understand what I mean. The reason I say this is that if you're being interviewed as a grad the interviewers are not looking for technical knowledge. What they're looking for is how you think. Hiring grads is an investment, they're looking for people that can solve problems, that can be trained. Not necessarily deep knowledge of a particular technology. There will be technical questions, but they're not really looking to see if you know the answer, they're looking to see how you think and respond under pressure.
When I do technical interviews all I do is get the person talking about a project they've worked on. I get them to talk me through it, I get them to explain why particular choices were made. I get them to talk to me about a tech they are familiar with, doesn't matter if I am. What I'm really looking for through all of this is can they explain the system to me, can they explain their choices. What I'm looking for more than anything else is the ability to communicate, because if we can communicate then I'll get a good feeling for whether you're technical or not. The other thing I get from this almost as an aside is if they understand what they're doing or are just doing what they're told.
Now all interviews are different, that's my style but others do different things. But they're generally looking for the same key points:
- Can this person communicate a technical system to a technical person
- Can this person learn / be trained
- Does this person get it
So with all of that, what I recommend is:
- Be honest, it's OK to say "I don't know" or "I'd need to look it up". But if you claim to know something then it all falls apart when prodded it's not a good look.
- Think of a project that excites you and keep pulling the interview back to that. For grads, excitement is a key thing that interviewers look for. And if you're passionate about the technology and get it that will shine through naturally.
Posts
I would agree with @The Crowing One though that in general there shouldn't be too much on the technical front. They're trying to gauge if you're worth spending money on to bring to an on-site interview. Basically just be honest in your answers and try not to be full of bs.
Oh, one personal pet peeve of mine... when asked about things you have done make sure to actually talk about what YOU have done, not "this is what my team did". "I was on a team and did X, Y, and Z towards the goal of the project, which was this..." I tend to get a lot of folks that are very quick to talk about the projects they've worked on but can't seem to articulate what role they had in the team.
You're probably better off spending your prep time on other parts of the interview, like researching the company and thinking up a few good, solid questions to ask.
For the larger, more prestigious firms, they may go through 2-3 phone screens and at least one later one will definitely be technical. If they talk about setting up a Google Docs or Collabedit then you're going to be writing some pseudocode. Also, if it is a named company, it is worth googling for their interviewing practices - Microsoft and Google in particular are quite well documented.
Generally, a phone interview is a chance for us to see if someone has the passion for programming and games that we're looking for. We'll poke about technical details to make sure someone actually knows what they're talking about, but we're really looking for someone to jump at the chance to talk about what they've worked on. The phone interview is a chance for this person to convince us it's worth the effort to fly them out for an interview.
Our on-site is where we make people prove they're a good programmer.
When we did phone screens, the ones I liked the best were the ones that not only communicated well over the phone, but asked questions that showed they were really interested in the job. Look up information about the company ahead of time and ask some simple questions like "I see you guys did X, would I get a chance to work on something like that?". These same types of questions will earn you big points during the in-person interview, assuming you pass technical muster.
Note I'm taking this from a Software Engineering perspective, but this should overlap with most of the positions you look at.
If tech questions come up, you'll probably be asked a couple questions about each intersection between what they use and what you've claimed on your resume. This means that if you don't really know anything about a subject, it shouldn't be on your resume just for padding. There tend to be some standard questions that almost everyone will ask about a particular language or skillset, and then each company might have additional questions. The less specialized the skill, the more questions will tend to be the same between companies. Some examples of standard questions I was asked a lot and have asked myself are below. You will notice a pattern in the style:
.NET:
- What is the difference between an interface and an abstract class? (This one gets asked for Java too)
- What is the difference between a class and a struct?
SQL:
- What is the difference between an inner and outer join?
- What is the difference between a WHERE clause and a HAVING clause?
If you don't know the answer to a technical question, say so. Under no circumstances should you try to stall and look it up. It's super-obvious when someone is stalling, and we can hear your keyboard. That's an instant-fail on an interview. If you know part of the answer, tell them that and then provide as much of an answer as you can.
For general phone interview advice:
- Go to the bathroom 15 minutes before they are scheduled to call. Similarly, eat beforehand. You don't want distractions.
- Make sure you are well-rested. You don't want to be yawning all over the call, or spaced out
- Ensure you are somewhere quiet. If your roommates tend to play loud dubstep, ask them to stop for the duration. Don't take it at the bus station.
- Have a copy of your resume in front of you so you know exactly what they're looking at.
Edit: And as Ganluan says, make sure you've got some questions to ask at the end. It's good to have a list of a few things you could ask any employer if they don't cover them, and better to have more specific questions.
It's very possible that you'll be expected to psuedocode and handle some basic algorithms, but nothing you shouldn't have already covered in school. Be ready to handle more conceptual questions as well, such as talking about data structures and their uses, run time analysis, and general object-oriented principles (all of these will depend on where your applying and what matters to them). Talk through your thinking process. It'll help you organize your thoughts and also provide the interviewer a better idea of your thought process, which is really what's important at this stage. Finally, don't be afraid to ask questions if you need more clarity during the interview.
Now for the hard part. If you've just graduated you know nothing. I know you've just been through uni and think you've learnt a lot of stuff but when you look bak 5 years from now you'll understand what I mean. The reason I say this is that if you're being interviewed as a grad the interviewers are not looking for technical knowledge. What they're looking for is how you think. Hiring grads is an investment, they're looking for people that can solve problems, that can be trained. Not necessarily deep knowledge of a particular technology. There will be technical questions, but they're not really looking to see if you know the answer, they're looking to see how you think and respond under pressure.
When I do technical interviews all I do is get the person talking about a project they've worked on. I get them to talk me through it, I get them to explain why particular choices were made. I get them to talk to me about a tech they are familiar with, doesn't matter if I am. What I'm really looking for through all of this is can they explain the system to me, can they explain their choices. What I'm looking for more than anything else is the ability to communicate, because if we can communicate then I'll get a good feeling for whether you're technical or not. The other thing I get from this almost as an aside is if they understand what they're doing or are just doing what they're told.
Now all interviews are different, that's my style but others do different things. But they're generally looking for the same key points:
- Can this person communicate a technical system to a technical person
- Can this person learn / be trained
- Does this person get it
So with all of that, what I recommend is:
- Be honest, it's OK to say "I don't know" or "I'd need to look it up". But if you claim to know something then it all falls apart when prodded it's not a good look.
- Think of a project that excites you and keep pulling the interview back to that. For grads, excitement is a key thing that interviewers look for. And if you're passionate about the technology and get it that will shine through naturally.