Technical Interviews (Seeking Advice)

[Neftren]

So I just went through a particularly brutal technical interview with a company that makes a high-level numerical computing environment that begins with M, and is matrix based (you can guess which of the three companies that is).

I was first asked a variety of discrete math problems which I wasn't particularly apt at solving -- likely my fault, as I studied up on data structures and algorithm design over discrete math. Then the interviewer proceeded to ask me a variety of questions on general programming concepts, which I did reasonably well on. Then the huge curveball was when I started to get a ton of language specific concepts related to a language that isn't on my résumé. I'd also made it clear I wasn't very familiar with this language, but the questions persisted. :smallfurious: I get the feeling the interviewer hadn't even read my résumé, and was just told to "interview" me by the manager.

Any tips or thoughts on how to deal with this? Or just technical interviews in general?


I admit, I'm pretty new to the whole technical interviewing thing, but I've gone through two other interviews now with major software companies and the questions I asked weren't nearly as difficult or specific to elements or features of one specific language.

[Palanan]

Well, you have my sympathy for surviving a tough interview. Wish I could offer something more.

I've gone through plenty of rough interviews, but never one that was quite such a technically focused grilling. Maybe it's because of my field; I've been asked general questions on experimental design, but what you describe sounds like a mini-qualifer, with all the stress and misery that entails. Is this the norm in computing fields?


Originally Posted by Neftren
...a company that makes a high-level numerical computing environment that begins with M, and is matrix based (you can guess which of the three companies that is).

Actually, no idea. English major.

:smallsmile:

[valadil]

It's okay to say "I don't know." Really. The interviewer can't hold it against you if you haven't encountered $LANGUAGE before. He will judge you if you start lying to him though.

Sometimes I ask about those new concepts that come up. I can't tell if that's actually a good move or not. I'm legit curious, but I'm worried that it looks like I'm faking it.

> I get the feeling the interviewer hadn't even read my résumé, and was just told to "interview" me by the manager.

I've been in that interviewer's position. Sometimes I've had warning. Sometimes my manager disappears for an hour then reappears with a stranger and tells me to do an interview. It happens. I'm guessing the interviewer heard what you were saying but didn't really know what else to talk about.

Oh yeah, write things down. If he asks you about a new concept, you can go home and research it and be that much more prepared for the next interview. I'm also a big fan of writing things down because when "do you have any questions for me" rolls around, my mind goes blank. If I have a whole page of things that caught my attention, I can ask questions. Interviewers really like that.

[Jay R]

You have two goals in your answer to such a question.

1. Tell him that what he is asking about isn't the skill you're showcasing, and
2. Showcase the skill you want him to be impressed with.

You want to be kind of subtle in your handling of goal one, so it doesn't look like you're insulting the interviewer. Then instantly move to goal two, so the major part of your answer is about your strengths.

"Well, I haven't ever used $Language1. But last year we had a similar situation at <OldEmployer>, which I solved with $Language2 this way. <Insert excellent example of your problem-solving skills here>"

You should walk into an interview with your greatest triumphs in that field well-rehearsed, and be on the lookout for a graceful way to sandwich them into the interview.

[factotum]

I would say that there's no shame in pointing out you don't know this language and can't answer his questions, but you're a quick study and will pick up the principles quickly if given the job. If he asks why you're in the job interview when you don't know the language, that's when you point out it's not on your resume and therefore he should be asking that question of whoever offered you the interview! Be honest and open about it, that's all you can really do.

[Neftren]

Is this the norm in computing fields?

I honestly don't know. This was my second interview. Fourth if you count the screening interview I did with the company two days earlier, and the third was a screening interview with another company.


It's okay to say "I don't know." Really. The interviewer can't hold it against you if you haven't encountered $LANGUAGE before. He will judge you if you start lying to him though.

I was upfront with him in saying I was unfamiliar with Java. He acknowledged it, and proceeded to ask the questions anyways. :smallannoyed:


I've been in that interviewer's position. Sometimes I've had warning. Sometimes my manager disappears for an hour then reappears with a stranger and tells me to do an interview. It happens. I'm guessing the interviewer heard what you were saying but didn't really know what else to talk about.

Oh yeah, write things down. If he asks you about a new concept, you can go home and research it and be that much more prepared for the next interview. I'm also a big fan of writing things down because when "do you have any questions for me" rolls around, my mind goes blank. If I have a whole page of things that caught my attention, I can ask questions. Interviewers really like that.

I tried to move the conversation towards something that was on my resume (i.e. GPU programming, web programming), but he seemed more interested in just going down the checklist of questions. In all honesty, it felt like he was administering an hour-long test over the phone, rather than actually getting a sense of me as a candidate. I'm a little disappointed really, as I had pretty high hopes after the screening interview -- my understanding of interviews is that I'd also have an opportunity to see what life is like working at the company. Suffice to say, I won't be recommending any of my friends to this company anytime soon, heh.


"Well, I haven't ever used $Language1. But last year we had a similar situation at <OldEmployer>, which I solved with $Language2 this way. <Insert excellent example of your problem-solving skills here>"

You should walk into an interview with your greatest triumphs in that field well-rehearsed, and be on the lookout for a graceful way to sandwich them into the interview.

My answer above handles this a bit. Keep in mind this was an internship interview, not a job interview. That being said, it felt like I was being grilled with questions for a full-time position, as it covered a lot of ground about terminology and best practices within certain programming languages.


I would say that there's no shame in pointing out you don't know this language and can't answer his questions, but you're a quick study and will pick up the principles quickly if given the job. If he asks why you're in the job interview when you don't know the language, that's when you point out it's not on your resume and therefore he should be asking that question of whoever offered you the interview! Be honest and open about it, that's all you can really do.

Hm, I covered this above also.

1

Okay, moving forward though! I just got a scheduling email to fly out to what is likely my first choice company now -- second/final round interviews. You might have heard of them. They're a company that makes transparent openings in walls, located outside Seattle.

With that in mind, anyone have any tips? Just in general, as this is going to be my fifth interview now. I can provide more information. Not quite sure where to start though.

[Errata]

The interviews I've been on have each been dramatically different from one another in lots of different ways. It's hard to know what to expect walking in, because it probably won't meet your expectations. The ones that aren't challenging are the ones that make me nervous, because I wonder how many bad coworkers they would hire that way.

I haven't experienced precisely the situation you're describing. That sounds like a bad fit to me, or a lazy interviewer.

Some companies will try to ask about stuff they expect very few candidates will be experts on. They'll give you all the information you need and ask you to work with something unfamiliar. The point isn't to look for knowledge but the ability to pick up new concepts and problem solve about them. Specific knowledge is something you can learn on the job, but the ability to think can't be taught, so that's what the best employers are looking for. The way you describe it, I don't think that's applicable though, assuming the language is pretty common and other candidates would be likely to know it.

I've had some interviews that are language agnostic, and you may work in pseudocode on white boards, for instance. Others care about a specific language, but they'll screen resumes for candidates who are strong with that language. Others may adapt the process to allow you to work in your preferred language, within reason.

If you think you don't have the information you need to get through what they're asking you, just be honest. Maybe you can salvage it or maybe it's not going to work out, but it's definitely not going to work out if you don't try to change the direction of the interview to something you can handle. If they persist, then it wasn't meant to be.

I don't do anything special to prepare for interviews. You've been preparing your whole education/career. I just make sure to get a good nights sleep, a good breakfast, have clean, appropriate clothing, be alert and in a good frame of mind, etc. The technical stuff you're either already ready for or you're not so don't stress too much. For me the adrenaline kicks in in important situations, and that's when I'm at my best, but I know people react differently to pressure and I don't know what to tell you there. I haven't been on a huge number of interviews, but I do have a 100% track record of getting job offers from the ones I've been on.

[Manga Shoggoth]

It's okay to say "I don't know." Really. The interviewer can't hold it against you if you haven't encountered $LANGUAGE before. He will judge you if you start lying to him though.

On the (very rare) occasions I have been asked to set up interviews, I usually run about 8 questions.

The first 7 questions are general problem solving ones around the work that needs to be done. I am not expecting a "right" answer - I am more interested in how they think and approach the problem.

On the other hand, the last question is specifically designed to see if the interviewee is prepared to say "I don't know". To me it is critical that the person can admit the limits of their knowledge, rather than blunder around making wild guesses.

[Chen]

Okay, moving forward though! I just got a scheduling email to fly out to what is likely my first choice company now -- second/final round interviews. You might have heard of them. They're a company that makes transparent openings in walls, located outside Seattle.

With that in mind, anyone have any tips? Just in general, as this is going to be my fifth interview now. I can provide more information. Not quite sure where to start though.

I've had some friends with interviews at the company you're talking about and they had some tricky brain-teaser/logic puzzle questions asked to them in the interview. I don't recall how long they were given to solve them but it wasn't an extremely long time. They wanted to see you work out the problems on the board in front of them, presumably to see what your thought process was in solving the problems.

An example one of my friends told me about: One train is moving at 10 mph and another at 5 mph, each and moving towards each other. They start 20 miles apart. A bird flies at 15 mph and flies back and forth between each train. How far does the bird travel before the trains pass each other?

[valadil]

On the other hand, the last question is specifically designed to see if the interviewee is prepared to say "I don't know". To me it is critical that the person can admit the limits of their knowledge, rather than blunder around making wild guesses.

I like that as a tactic. What's the question (if you don't mind sharing)?

Last one I had like that was on the specifics of object inheritance in javascript. I looked it up immediately after the phone screen and figured that it was hairy enough that if I ever had to use it I'd probably want to look it up again then too.

[Tylorious]

Whatever you do, don't make the mistake that I did when I first got out of college. When they ask you if you have any questions at the end of the interview, don't say "When can I start?" It will not go over well.

[Manga Shoggoth]

I like that as a tactic. What's the question (if you don't mind sharing)?

Not at all... This is about 15 years ago now, so the same problem probably wouldn't appear now.

The job opening was for a Sybase DBA dealing with the Sybase Replication product, so the first seven questions were all about tracking down fairly common replication problems.

The last question was "When loading up a database dump you get (obscure error number and message). What has happened and how do you fix it?"

What had actually happened was that the size of the data in the dump file had crossed the 2G boundry, so - despite the actual database being 5 times the size - the dump file wouldn't load. However, the error message bore no relationship to what had actually happened.

(The fix, incidentally, was to split the single 10G data device into 10 seperate 1G data devices.)

[Douglas]

I've had some friends with interviews at the company you're talking about and they had some tricky brain-teaser/logic puzzle questions asked to them in the interview. I don't recall how long they were given to solve them but it wasn't an extremely long time. They wanted to see you work out the problems on the board in front of them, presumably to see what your thought process was in solving the problems.

An example one of my friends told me about: One train is moving at 10 mph and another at 5 mph, each and moving towards each other. They start 20 miles apart. A bird flies at 15 mph and flies back and forth between each train. How far does the bird travel before the trains pass each other?
Last I heard, that was an experiment that became a fad and then died out when studies showed it didn't actually help identify good programmers.

[Chen]

Last I heard, that was an experiment that became a fad and then died out when studies showed it didn't actually help identify good programmers.

*shrugs* The friend in question had the interview probably a good 6-7 years ago. Maybe they stopped doing that now.

[valadil]

*shrugs* The friend in question had the interview probably a good 6-7 years ago. Maybe they stopped doing that now.

Not everyone has gotten the memo yet. Those that have still haven't figured out a good replacement, so they stick with what they know.

I didn't mind puzzles like this when I'd just finished college and was looking for a job. Then I got to one interview where I beat the company's own answer by a fair margin. The interview jumped out of his seat and shook my hand. Still didn't get the job. Kinda lost hope for puzzles being useful after that.

[Equinox]

So I just went through a particularly brutal technical interview with a company that makes a high-level numerical computing environment that begins with M, and is matrix based (you can guess which of the three companies that is).

I was first asked a variety of discrete math problems which I wasn't particularly apt at solving -- likely my fault, as I studied up on data structures and algorithm design over discrete math. Then the interviewer proceeded to ask me a variety of questions on general programming concepts, which I did reasonably well on. Then the huge curveball was when I started to get a ton of language specific concepts related to a language that isn't on my résumé. I'd also made it clear I wasn't very familiar with this language, but the questions persisted. :smallfurious: I get the feeling the interviewer hadn't even read my résumé, and was just told to "interview" me by the manager.

Any tips or thoughts on how to deal with this? Or just technical interviews in general?


I admit, I'm pretty new to the whole technical interviewing thing, but I've gone through two other interviews now with major software companies and the questions I asked weren't nearly as difficult or specific to elements or features of one specific language.A very important interviewing skill is to be able unobtrusively to shift focus from your deficiencies to your strengths. Not an easy thing to do, but something like "I don't know Python, but I have solved a similar problem in Java before, and ..." would be a good start.

[factotum]

An example one of my friends told me about: One train is moving at 10 mph and another at 5 mph, each and moving towards each other. They start 20 miles apart. A bird flies at 15 mph and flies back and forth between each train. How far does the bird travel before the trains pass each other?

The trains will take 1 hour and 20 minutes to pass each other, and if the bird is travelling constantly at 15mph for that entire time, it has to travel 20 miles. Do I get a cookie now? :smallwink:

[Equinox]

On the other hand, the last question is specifically designed to see if the interviewee is prepared to say "I don't know". To me it is critical that the person can admit the limits of their knowledge, rather than blunder around making wild guesses.That's a good idea.

I also like asking questions that are deliberately missing something in the problem definition. I want to see if the interviewee will find the sense to ask clarification questions ("and this is supposed to be optimized for area or power?"), or maybe state his assumtions ("I'm going to assume optimization for area..."). I mean, in the real life, most problems are not 100% defined, and you have to communicate any issues you have.

[Jay R]

The trains will take 1 hour and 20 minutes to pass each other, and if the bird is travelling constantly at 15mph for that entire time, it has to travel 20 miles. Do I get a cookie now? :smallwink:

More or less. That's the second easiest solution, though far better than a brute force summing of an infinite series. The bird is covering the same amount of ground as the two trains combined. and therefore covers the same 20 miles.

(This method is better for a programmer, because it can be easily used in versions of the problem in which the time is less easy to calculate. If the trains start 37.3245 miles apart, the bird flies 37.3245 miles.)

[Equinox]

When this problem was presented to the renown physicist Wolfgang Pauli, he gave the correct number in seconds. The quizzer complimented him on the speed and correctness of the solution, adding "usually people are trying to solve it by adding a convergent series". Pauli raised an eyebrow. "You mean there's a solution other than adding a convergent series?!"

[Neftren]

The interviews I've been on have each been dramatically different from one another in lots of different ways. It's hard to know what to expect walking in, because it probably won't meet your expectations. The ones that aren't challenging are the ones that make me nervous, because I wonder how many bad coworkers they would hire that way.

This seems interesting. How do you address interviews that are hard because of the interviewer? For instance, at my school, TripAdvisor has a relatively poor reputation. Apparently they're incredibly rude and demeaning in the interview. To my knowledge, I don't think their interview questions were exceptionally hard, but I couldn't say. I have yet to experience an intimidating interviewer breathing down my neck.

Just what I heard anyways.

I do think the interview described in the original post was a bad fit though, after seeing what sorts of questions they asked. I got the feeling they were really looking for a Math/CS dual major, rather than CS+something else.


On the other hand, the last question is specifically designed to see if the interviewee is prepared to say "I don't know". To me it is critical that the person can admit the limits of their knowledge, rather than blunder around making wild guesses.

I like this approach. When you did interview, how many candidates actually admitted that they didn't know the answer?

I think there's a lot of pressure to give an answer, any answer so as to not stare awkwardly at the interviewer for half an hour in silence. I wouldn't stoop to lying about skills (and in a technical interview? really?!), but what would you suggest if I really don't know the answer?


I've had some friends with interviews at the company you're talking about and they had some tricky brain-teaser/logic puzzle questions asked to them in the interview. I don't recall how long they were given to solve them but it wasn't an extremely long time. They wanted to see you work out the problems on the board in front of them, presumably to see what your thought process was in solving the problems.

An example one of my friends told me about: One train is moving at 10 mph and another at 5 mph, each and moving towards each other. They start 20 miles apart. A bird flies at 15 mph and flies back and forth between each train. How far does the bird travel before the trains pass each other?

Well, I'd heard said company has been moving away from the brain teaser questions. That being said, I did get a question about how I would design a certain hotel (mechanical) subsystem, which was actually rather fun to work through. I got a little stumped after a while. I thought of a whole bunch of things initially and kinda puttered out. The interviewer didn't seem particularly impressed with my solution at the time, but I guess it was enough for me to get into final round interviews, so I'm happy about that.


I didn't mind puzzles like this when I'd just finished college and was looking for a job. Then I got to one interview where I beat the company's own answer by a fair margin. The interview jumped out of his seat and shook my hand. Still didn't get the job. Kinda lost hope for puzzles being useful after that.

I actually managed to beat the interviewer's question on my very first interview. Sort of. To be fair, it was my friend interviewing me, so we had a pretty fun time, but I did answer all his questions.

Basically, it started off as a pretty standard "list of paired numbers, find the number with no pair" question. I walked through the various steps as he added constraints. The answer most interviewers I've talked to seem to want the hashtable/dictionary/map approach, which I did give him. I then gave an alternate solution about six hours later (at dinner) using Python Sets, which triggered a whole "mind blown" expression.

The company ultimately passed me over though. My friend said the manager thought there was too much game development on my resume. Meanwhile, game companies are saying I don't have enough, heh. :smallannoyed:


A very important interviewing skill is to be able unobtrusively to shift focus from your deficiencies to your strengths. Not an easy thing to do, but something like "I don't know Python, but I have solved a similar problem in Java before, and ..." would be a good start.

I was able to do this in one or two limited cases on the general programming concepts. He asked a number of questions in C/C++ which I solved in C++, but provided more elegant solutions using Python.

If he's asking me about development specific terminology though, there's absolutely no way I can shift focus from my deficiencies to strengths. Well, maybe, but I'm not seeing it. For instance, consider asking a Java developer (who knows absolutely nothing about Python) what PEP8 is. Without a computer at hand to look it up, I was pretty much dead in the water when I was asked about a Java development concept I was unfamiliar with.


1

And a quick update: I've scheduled my interview for November 12th, with said company that manufactures transparent openings in walls, outside Seattle. Whoo!

[Manga Shoggoth]

I like this approach. When you did interview, how many candidates actually admitted that they didn't know the answer?

Very few even got that far - most of them had trouble with the initial questions (which did not bode well when we specifically needed Replication experience). I did have one person who said he didn't know, and when he found out the answer his response was a dismissive "oh - that old chestnut". Actually, "Dismissive" was a good description of him.


I think there's a lot of pressure to give an answer, any answer so as to not stare awkwardly at the interviewer for half an hour in silence. I wouldn't stoop to lying about skills (and in a technical interview? really?!), but what would you suggest if I really don't know the answer?

If you don't know the answer, then the best approach is to say something like "Well, I don't know that, but this is how I would research it".



That's a good idea.

I also like asking questions that are deliberately missing something in the problem definition. I want to see if the interviewee will find the sense to ask clarification questions ("and this is supposed to be optimized for area or power?"), or maybe state his assumtions ("I'm going to assume optimization for area..."). I mean, in the real life, most problems are not 100% defined, and you have to communicate any issues you have.

Indeed. Mix them in with more "obvious" questions - so you have a string of questions which they "should know" to get their general skill level, followed by a twist in the last one to see how they take it - and you have a pretty bood bank of questions.

[Equinox]

If he's asking me about development specific terminology though, there's absolutely no way I can shift focus from my deficiencies to strengths. Well, maybe, but I'm not seeing it. For instance, consider asking a Java developer (who knows absolutely nothing about Python) what PEP8 is. Without a computer at hand to look it up, I was pretty much dead in the water when I was asked about a Java development concept I was unfamiliar with.

"I'm not sure, never used much Java, but isn't it similar to <fill in the blank> in Python?"

Worth a shot, anyway.

[Errata]

This seems interesting. How do you address interviews that are hard because of the interviewer?

I've been lucky enough not to run into these yet. I know it happens, but I feel like the companies I've interviewed with have been very reasonable. I like challenging interviews that I feel like could weed out some less skilled coworkers. I wouldn't like an interview where the interviewer makes it unpleasant because of their unprofessional style, as I don't think that would actually help select the right people. If anything it might turn away some good people.

The closest I've come to that was an interview that was just confusing for me, where he was almost lecturing me on his own ideas and asking only a few very vague questions. I couldn't figure out what he was trying to accomplish or what the point was, but I did my best. I couldn't tell if I'd bombed that, but I did get a very enthusiastic job offer from them somehow. There were multiple people interviewing me on different topics, and I felt more confident about the other interviews, so I still have no way of knowing for sure how I did on the confusing part.

[valadil]

How do you address interviews that are hard because of the interviewer?

I suck it up and tell myself that's not a job I would have wanted anyway. If the interviewer asks rude questions because he likes watching you squirm, is that really someone you want to spend 40 hours a week with?

[Equinox]

I suck it up and tell myself that's not a job I would have wanted anyway. If the interviewer asks rude questions because he likes watching you squirm, is that really someone you want to spend 40 hours a week with?But often you're interviewed by more than 1 person. And some of them, you won't have to work with directly (I was interviewed by 5 people at my current workplace, and 3 of them, I barely see on my day-to-day job).

If you have a tough interviewer, I suggest trying to genuinely figure out what is it they want from you. Yes, it could be "just to see you squirm", but usually, it's not. If you realize it's not the kind of person you want to work with, you can always say no later.

[Jay R]

I suck it up and tell myself that's not a job I would have wanted anyway. If the interviewer asks rude questions because he likes watching you squirm, is that really someone you want to spend 40 hours a week with?

You won't have to. He's trying to make some people squirm so he can hire the ones who don't.

That's the purpose of an interview - to winnow people out.

[Neftren]

I suck it up and tell myself that's not a job I would have wanted anyway. If the interviewer asks rude questions because he likes watching you squirm, is that really someone you want to spend 40 hours a week with?

See, I don't really have that option right now. I need and will most likely take whatever I can get at this point. Quite honestly, I need the money, and I definitely could use the experience on my resume and portfolio. I'm not sure how I would convey that in an interview, if I would at all (I don't exactly want to come across as desperate -- or do I?).

[Equinox]

I'm not sure how I would convey that in an interviewYou don't. You pick one aspect of the job that you genuinely see as a positive (other than "it pays money") and do your best to convey your excitement about that. For example, "I'm excited to have a chance to work for such a well-known company", or "I'm excited to have a chance to put my Java skills to use".

If it's a job that absolutely has no positive aspects whatsoever beyond "it pays money", my condolences.

[valadil]

If it's a job that absolutely has no positive aspects whatsoever beyond "it pays money", my condolences.

Word. When I was young and naive (ok, young and more naive than I am now) I told an interviewer I was excited that the job was close enough to my apartment that I could walk there. The interview immediately soured. It's as if I was so unimpressed by everything else about the job that I had to use geography to prove my enthusiasm.

[Errata]

(I don't exactly want to come across as desperate -- or do I?).

No, you don't. If they think you don't have any other options, that's not going to have any positive consequences and it may have negative ones. Giving a job offer on the basis of who needs it most is never going to cross their minds. You want to present yourself as being in demand. If they think maybe you would have a higher probability of having other job offers that you might accept, that wouldn't stop them from making their own offer and leaving it up to you, so there is no reason to convey in advance that you will take whatever they offer.

Convey your enthusiasm for specific things that you like about the kind of work you'd be doing at that workplace. They should think that you will be a motivated coworker who don't drag everyone else down. The rest serves no productive purpose. Edit yourself, but don't make up a complete fabrication. Even if it's not your dream job, there should be things you can be positive about.

[anrique]

For Technical Interview, They are lot of ways such like as short-key, tactics, sticky notes. Learn as much as possible.

[pendell]

On the (very rare) occasions I have been asked to set up interviews, I usually run about 8 questions.

The first 7 questions are general problem solving ones around the work that needs to be done. I am not expecting a "right" answer - I am more interested in how they think and approach the problem.

On the other hand, the last question is specifically designed to see if the interviewee is prepared to say "I don't know". To me it is critical that the person can admit the limits of their knowledge, rather than blunder around making wild guesses.

This. I work in research and development. A lot of times there is no right answer ... we're trying to discover it. That's why it's research.

So if I were interviewing technically I would be deliberately looking to hit people with stuff they hadn't encountered before. To see how they think, to see how they reason. To see how they handle problems, what they do when they're under pressure, what they do when they don't know the answer.

Are you the kind of person who has carefully memorized a bunch of technical trivia and, when hit with something you didn't expect, gape at me like a landed fish?

Are you the kind of person who panics?

Do you admit the limits of your knowledge but nonetheless take the best swing at it you can?

Also, your emotional response. Do you get flustered? Are you easygoing? Do you get angry? Or are you able to remain cool?


Other companies may look for other things. I'm not interested so much in how much information you have memorized as in 1) Your problem solving technique. So you don't know. Do you know how to do the research and find out? 2) Your ability to work and remain calm under pressure. Are you able to handle curveballs?

Given these circumstances, I'd be more likely to take someone who scored 80% but was adaptable and friendly over someone who scored 100% but was rigid, inflexible, and unable to go beyond rote memorization. Rote memorization is of limited use in the IT world because the technology changes so quickly. You've got to be prepared to learn new languages, new architectures, new technologies very quickly. Memorizing all the features of oracle 7 (say) in 1995 cuts very little ice in 2013, even for an oracle job.

Therefore memorization and pat answers are a distinct second place to the ability to learn, to be flexible, and to continue to function in an uncertain environment.

That doesn't mean I'd accept someone who completely whiffed all aspects of the technical interview. It's not unknown for people with no IT background at all to try to bluff their way in even though their education is fictitious, by simply cramming and memorizing all the technical questions from the various sites on the internet. So the purpose of my questioning is threefold: 1) Do you have basic and specific knowledge of the subject? 2) Do you actually *know* the material, or have you just memorized a bunch of stuff off the internet? 3) How do you function under pressure?

That's the way I interview and what I, personally, am looking for. Some of the larger companies may require academic perfection.

Respectfully,

Brian P.

[GungHo]

I was first asked a variety of discrete math problems which I wasn't particularly apt at solving -- likely my fault, as I studied up on data structures and algorithm design over discrete math. Then the interviewer proceeded to ask me a variety of questions on general programming concepts, which I did reasonably well on. Then the huge curveball was when I started to get a ton of language specific concepts related to a language that isn't on my résumé. I'd also made it clear I wasn't very familiar with this language, but the questions persisted. :smallfurious: I get the feeling the interviewer hadn't even read my résumé, and was just told to "interview" me by the manager.
He's trying to figure out if/how you can solve problems when you are encountering something you've never encountered before. He's trying to figure out if you will try, lie, or give up. Give up is okay, but only if you have a fallback plan "I don't know, but I will find out/find a SME" and/or "well, if this is similar to something I've worked with <progam language I do know>, I would <program this>, but I'm not sure if that language has that feature, but do you know if that sort of approach would work?". What you cannot do is pretend the problem doesn't exist and pretend that you weren't asked to come up with a solution. And, if you lie, you will absolutely be found out and you will absolutely not get the job.

[Errata]

It's not unknown for people with no IT background at all to try to bluff their way in even though their education is fictitious, by simply cramming and memorizing all the technical questions from the various sites on the internet.

For us it's very common to have applicants with very real educations and computer science degrees from top universities who it turns out can't program their way out of a paper bag. The programming test is an indispensable part of the interview process, because there are often candidates with a great resume who do a great job talking the talk, but are useless. And some people who really are great programmers are not the smoothest interviewees. You need objective demonstrations.

[valadil]

For us it's very common to have applicants with very real educations and computer science degrees from top universities who it turns out can't program their way out of a paper bag. The programming test is an indispensable part of the interview process, because there are often candidates with a great resume who do a great job talking the talk. And some people who really are great programmers are not the smoothest interviewees. You need objective demonstrations.

What I've heard works well here is to start with a non-trivial code sample provided by the candidate. Ask them questions about. Basically you're determining if they actually wrote it or not.

I can't say I've tried it, but it seems like the best compromise between getting code from your interviewee and not wasting their time. I'll gladly send a potential employer to my github profile and since I'm doing open source work 40 hours a week, my github profile looks great. But I'm sure someone with more hiring experience would see some downsides to this approach.

[Errata]

I can't say I've tried it, but it seems like the best compromise between getting code from your interviewee and not wasting their time.

It could be a useful additional step during the screening process to save a few thousand bucks flying them out here only to have them go down in flames. But I would see it as a supplement rather than a replacement for a programming test, because even if they show some familiarity with the code, you don't know how much help they had, how long it took them, etc. And since the samples are all for such different problems, it will be tough to have a fair, apples to apples comparison with other candidates. And the interviewer will have to spend their own time studying that code, and will still be unfamiliar with it and thus it wouldn't be too hard to fool them, since they may not know exactly what they were looking for.

[valadil]

Errata, absolutely. It was meant as part of the phone screen. Instead of doing homework to get a phone screen you talk about your code sample.

As somebody with a full time job and a toddler, I don't have the free time to do homework to qualify for an interview, so I very much appreciate the chance to skip that step. I also think a code sample from my job is a more honest representation of a bit of homework that I tried not to google and swear I did in under 4 hours.