views:

1077

answers:

17

I've been programming for a few years in C# and XML. I used only the basics of those languages and have survived on the web for info like arrays and text manipulations. But when I am get interview, the interviewers ask only advanced questions - I found the answers later in the Advanced sections in the books on the subject.

Why do the interviewers ask such advanced questions? The job looks almost the same as what I was previously doing, so there's need for advanced knowledge, like what class delegate is or XPath commands.

Questions are:

  1. What version of XSL does .NET 3.5 uses?
  2. What XPath command to use to get value in element X?
  3. What are class delegates in C#
  4. Does C# allows multiple interface inheritance?
  5. How do you access GAC in C#?
+11  A: 

Perhaps because they are trying to find programmers who know more than the basic stuff. If they are trying to distinguish between a field of candidates, it isn't helpful to ask questions that everyone knows the answer to - how do you select among those candidates? If you're going to hire only 1 or 2 out of a pool of candidates, you need to find some harder questions that only 1 or 2 out the pool can answer.

Larry Watanabe
+1  A: 

They probably want to see if you really know what you're talking about or if you're a novice programmer who gets along on the web using only what he has picked up through trial and error...

Jason
+34  A: 

There are two reasons that I ask them.

  1. To see a person actually say "I do not know the answer to that", as opposed to trying to BS through the question.
  2. To see what kind of logical problem solving skills a person has.

Usually a question will be of one or the other, but not both. Both are extremely valuable in screening a perspective employee, however.

Also, the question might not actually be "advanced" for the position. It is reasonable to assume that Senior-level and/or Architects can answer questions that a Junior to Mid-level might not.

joseph.ferris
I like this and also feel that a candidate needs to be strong enough to say that they would look that up or to just follow through the logic of the question.
SteveM
Exactly. I feel a lot of interviewers fail to realize that looking up the answer to a question is actually a skill, as well. It is great if someone knows how to look up the answer, then take that information and correctly apply it to the issue at hand. I don't care if someone can memorize the manual, the question at hand is whether or not they comprehend the manual.
joseph.ferris
A: 

I ask advanced questions to try see how people work through the problem. I like to ask questions that I don't know off the top of my head for that reason.

I want someone who is a critical thinker rather than just an academic who can recite text books to me.

AutomatedTester
+2  A: 

Likely they're just getting a gauge of where you are. They probably got stuck on this problem themselves and perhaps wanted to see if you could think of an answer on your feet.

I've experienced the same types of questions, and considering when I program I use excessive resources, this type of thing usually throws me off. Their loss.

scrot
A: 

They want to find someone with practical experience that extends beyond what is taught in beginner courses. When my company interviews candidates, we often find that most of the applicants cannot solve what we would consider to be very basic programming problems simply because they don't know the API or don't understand when to use various basic data structures.

If you want to impress an interviewer, work on your own programming projects outside of class. Learn a good chunk of the language API, and start learning about third-party libraries that can greatly simplify your work.

rob
+9  A: 

Getting the answer wrong is what I want from an applicant in some cases.

One of the reasons I like to ask a question that I think the applicant will get wrong is to see how they adjust to the situation. How they handle getting something wrong and handle someone telling them how they should have answered etc. If they are very defensive or rude when you tell them they are incorrect then it is a good indication of how they will work on a team when many times your ideas will be challenged.

If they take the solution or recommendation and realize they can learn from it or even add to it that is usually a sign of someone what is easy to work with and willing to work 'outside of their box'. If they just make excuses and dance around trying to say why they could be right or should be right (in cases where they are clearly not) then this tell me when the same issue arises in the future this applicant is going to cause headaches.

Not so worried about the answer, more interested in how they react to the question / solution.

Another reason would be to gauge their level when hiring as well. You might be hiring for a bunch of positions but not sure where this applicant fits. Hard questions that show problem solving and attention to detail can sometimes make it easier to categorize their skill set.

Kelsey
A: 

Another reason is to gauge your response to a question they really don't expect you to know the answer to. Problem solving skills are essential, so asking you questions you already know the answer to is not going to address that, is it?

There are even instances of companies asking odd, non-programming related questions just to see how you think your way through a problem. There is the classic "Why are manhole covers round" question, reportedly asked at Microsoft interviews.

More Microsoft interview questions

ScottSEA
A: 

I'm not meaning to offend you but maybe your understanding of the job is not deep enough and it in fact requires knowledge of advanced techniques.
Also, you can do a lot of things with basic methods but advanced methods might the better way to implement regarding complexity, time to implement or maintainability.

mxp
A: 

There are many possible reasons. They may:

  • actually use those techniques (delegates and XPath aren't particularly rare or obscure)
  • have a large pool of candidates and want to try to find the more knowlegable ones
  • want to see where the limits of your knowlege are, so they ask question up to the point where you start to be unable to answer well
  • want to see how you might approach areas that are unfamiliar to you - to see how you might adapt to new stuff
  • want to show off their own knowlege (probably not a legitimate reason, but it certainly happens)
Michael Burr
+6  A: 

I ask advanced questions for a few reasons:

  1. Some of my questions are advanced usage of things everyone should know (not a trivia question) -- I want to see you reason through the answer using knowledge you have, but in a way that isn't common.

  2. I want to see what happens when you don't know something -- do you give up?

  3. I want to hire people that are serious about what they do. People that really care about the technologies they use tend to want to know the advanced stuff.

  4. I want to see if there are gaps where you just don't know that an entire area of knowledge even exists. For example, in your XPath example -- I might be ok with: "I believe that XPath could be used to help solve this, but I don't know it well enough to write it out here" -- then I would show them a little XPath and see if they could apply it. If you don't even know that XPath exists, google isn't going to help you.

Lou Franco
+1  A: 

Because competency as a programmer involves both depth and breadth of knowledge.

Chris Ballance
+2  A: 

The interviewer is trying to devine your level of knowledge, and he is copping out by "borrowing" a question from the last chapter of that book.

Really, this is sloppy work on his part, relying on one question to guage your expertise level. You may have low programming skills, but recently come across the buzz-word, and are able to ace the interview.

I did get burned once in interviewing a candidate who professed high levels of C expertise. It turned out that he was reading "C for Dummies" and managed to BS through the interview process. I admit that I wasn't concentrating on his programming skills, but was looking for other aspects, which he also managed to BS through. Turns out his whole resume was a pack of lies.

Nowadays, I make sure the candidate has working knowlege of variable scope, persistance, pointer arithmetic, basic algorithms, structured programming, object-oriented programming, polymorphism, multitasking and inter-process communication. I will quiz him on his debugging skills, and zero in on details such as race-conditions, heisenbugs and security vulnerabilities.

Depending on the job, I will ask about experience in the target language - such as key=>value maps (arrays) in PHP, Swing programming in Java, event handling in C#, tables vs CSS in html -- you get the picture.

If the candidate passes the first part of the interview (I usually know within about 5 minutes), I will then give him a binder and send him into the coffee room (nice couch and table there) to prepare for 20 minutes for a code review on a selected module.

That's when I send in the troops - employees are instructed to use the coffee room normally, introduce themselves and make conversation for about a minute.

What I'm looking for is the ability to concentrate on a task (blatant ADHD), the ability to work under pressure, and interpersonal dynamics.

When the candidate returns, I have him act as main presenter and start our normal code review process. The first thing I look for is if he read the page titled "Code Review Process". I'm not looking for him to complete the review - about 10 minutes is enough. As a matter of fact, the fewer main lines processed, the better - within reason.

I haven't been burned by a new hire for a long time now.

dar7yl
A: 

I've heard these really aren't in use anymore, or at least not nearly as much as they used to be, but you might be interested in this. I picked up a pretty cool short book a few days ago that has to deal with the "Microsoft style" logic interview questions that are sometimes asked. I'm a few chapters in and it gives a neat little history of the tech field's interview style and has a ton of logic problems, complete with answers in the back.

It's called "How Would You Move Mount Fuji" and it's on amazon for pretty cheap.

http://www.amazon.com/gp/offer-listing/0316919160/ref=dp_olp_used?ie=UTF8&condition=used

Sean O'Hollaren
+2  A: 

Your username suggests you like coding (duh), but your question suggests you don't. If you really liked coding, then you should love to learn about it. Those questions that you listed are not that advanced.

Even if those questions were advanced, the interviewer is trying to gauge how much knowledge you have in the area that you say you have knowledge in. They are also trying to gauge how well you would fit into their group.

P.S. Not to be mean, but if you program using XML and don't know what XPath is, then you are a little far behind.

Martin
A: 

I've just completed a round of interviews, where I use a three or four stock 'simple' C# code fragments that the interviewee will look through and attempt to explain what the expected result will be. In each case the code sample is no more than ten lines of clearly-formatted code that utilises basic C# skills (inheritance, generics, anonymous delegates); also in each case there will be a 'gotcha' - but like others have stated, I don't put these in to be spiteful, they're there because I want to see how the candidate reacts when confronted with something that doesn't work as expected.

We had a candidate recently that had sailed through the first part of his interview; impressive CV, was apparently the Lead Developer of a team of 10 and had been developing code in C# since 1.0; yet apparently had no idea what "Console.WriteLine()" did (nor could he even hazard a guess), nor could he even begin to cope with the tiny anonymous delegate example.

Another candidate was self-effacing, and didn't know how to grade herself as a developer - she'd had less experience than the former candidate yet she sailed through the code samples, fell for a couple of the 'gotchas' but asked the right questions to get the correct conclusions and genuinely learnt from the experience. Needless to say, she was hired.

If you're claiming domain-specific knowledge (like XML) you should expect to be asked specific (and sometimes hard) questions about that domain; if I'm interviewing a senior ASP.NET developer and they've got no idea about HttpModules or HttpHandlers (like some recent interviewees) then alarm bells start to ring.

Ed Courtenay
+1  A: 

1.What version of XSL does .NET 3.5 uses?

Because they can't tell important things from non-important ones. Bad sign.

2.What XPath command to use to get value in element X?

Because they want to see if you know XPath. This can be either because they use it extensively and you need it to get they job done or because they think XPath knowledge == skill.

3.What are class delegates in C#

(I've never heard the term "class delegate" and a google search shows no definition, so I assume you mean just "delegate"). Delegates can hardly be considered an advanced topic.

4.Does C# allows multiple interface inheritance?

If they really asked about "interface implementation", it's part of the most basic concept so it's a valid question (although too simple to really mean anything). If they really asked about "interface inheritance", it's more of trivia, but I would still say acceptable. Bonus point for them if they asked what "interface inheritance" really means.

5.How do you access GAC in C#?

This is the kind of thing every team MUST have one person who knows. I'd say it's also a indication of seniority (which BTW, I don't care much about) since nobody reads about these things, the only way to find out is to be forced to solve a real-world problem.

erikkallen