Joe
1.23.2008
9:35 PM

I think there something to it being a little bit of a numbers game.A PhD in the page life-cycle doesn't necessarily translate toany kind of practical skill. Acing a technical interview is also worthless if the person's people skills suck, if he has a poor work ethic, horrific ego problems, etc -- and these are hard to spot in an interview when a person is much more likely to turn on the charm and tell you what he knows you want to hear.Also, if you want the cream you have to be able to pay for it which may not be an issue at a large consulting company, but often is in a corporate environment,

Dave Donaldson
1.23.2008
9:39 PM

I've spent *lots* of time interviewing developers and the accept-reject ratio is really, really low. Good developers are easy to find. It's the great ones that are extremely difficult to locate.As far as weedout-type questions go, I tend to focus on fundamentals, such as things like stack vs. heap, value types vs. reference types, static members vs. instance members... stuff that's not necessarily .NET-specific, but must be known for software development in general. Depending on how questions are answered, I'll see how low the candidate can go with things like the garbage collector, IL (JIT, ngen), AppDomains, etc. And of course there's some language specific things and then more stuff around design, architecture, etc.

dru
1.24.2008
11:34 AM

I also like to ask:What are the benefits of Managed code.What are the differences between static and dynamically typed langugages.Refactor a switch statement into polymorphism....other refactoringsAnd i like google questions:- find an area they are weak in and give them 10 minutes to find the answer via google.

bennyb
1.24.2008
1:14 PM

I always try to stay focus on the core principle of OOD - inheritance, interfaces,simple research questions which require only common sense to deduce and if they understand separation of concerns. I have seen many good programmers waste too much time on UI(LAF) rather than first complete the Domain in question.For example, in my apps, I use an MVC approach (kind of like MyXAML) which means nobody ever has to add an asp:Control tag (e.g. asp:DataGrid) or edit any UI (.aspx page). Everything is handled by the views. But understanding the difference between Sessions & Cache is crucial.

Jason
1.24.2008
2:38 PM

This falls under the "quiz show" interview anti-pattern that I just made up.Basically if you ask fact questions (how does ViewState work), expect that you're turning down talented developers.One way to avoid this is to put the questions through a few general tests- Did I know this fact before I started working here?- Were you a bad hire because you didn't know this fact?- How long did it take me to internalize this information?Putting your ViewState question through this little test at your first ASP.Net job probably goes something like this- No I didn't know about ViewState- No I wasn't a bad hire- It took seconds to learn and fully internalize the factSo what are good questions?- Programming challenge questions - how would you write a web page that does xyz with combo boxes- Design questions - write a Monopoly game (from Joel on Software), design the software for a gas station pump (harder than it sounds)- Refactor questions as another responder wrote

Arrington
1.24.2008
4:28 PM

It’s not any easy undertaking in any form. Our weed out process consists of a real world test.Our dev team came up with 3 exams that we feel would give us the best indication of who should get a formal interview.It works beautifully.We spent roughly 2 hours up front coming up with the exams and around 2 minutes resetting the exams between candidates.The exams are setup as real work as possible.(Documentation gaps, malformed data sources, IDE problems. etc..)The exam is as much about he person as it is about the tech/dev knowledge they may or may not posses.We fully expect no one to finish the exam in the time allowed.We want to see how the candidate goes about getting the problems solved.I fully agree with Joel Spolsky’s #1 cardinal criteria for getting hired– “Smart and Gets Things Done.” www.joelonsoftware.com/.../fog0000000073.h

Jason
1.24.2008
6:17 PM

Thanks for the response.I agree that there is nothing wrong with verifying understanding.I just want to stress that fact-only questions do less to demonstrate understanding and more to demonstrate knowledge.Consider giving the candidates an overview of ViewState and then asking the same questions.My experience has been that most will still whiff on it but the talented ones will instantly get the concept and may be a better hire than it seemed at first.In fact if they can synthesize the information that quickly they may be smarter than the candidate who knew it already.But your talk of "filler words" reminds me of some anecdotes I thought I'd shareWhen I asked a candidate to design a Monopoly game I actually one candidate tell me "get a user story and reverse engineer the process space."Meaningless.I typically ask warm up questions like what got the candidate get interested in computer programming and had answers like - "My mom made me" (this just happened yesterday, seriously) - "I put the data in the table." (Huh?)- "Money" (worst possible reason)- "I got my masters in it" (This is really common - and shows that the candidate is just not listening)I've asked people about the scale of the databases they've worked on also as a warm up question and had answers like "TWO mega gigabytes"."Really?Two mega gigabytes?Are you sure?" "Oh two megabytes, megabytes I mean."A two megabyte database.Wow.Thanks for your time.

Sri
1.25.2008
11:41 AM

Guess in the process of interview you have to kiss a lot of frogs.

Adam Hopkins
1.25.2008
6:38 PM

Hey Ben,I try to mimic my own interviews where I actually got the job (I would hire me, right?). I don't know who interviewed you for SARK, but Gary M. interviewed me, and he basically asked me a very consultant-y question along the lines of "pretend I'm a client and I want x" and handed me a dry erase marker and pointed at the board in his office. So, there I am in my tie drawing web service diagrams (the cloud is the internet) and he starts throwing questions at me to see when I would switch my approach. I don't remember the details, but I do remember feeling pretty stressed but getting the offer shortly after. My worst interviews have been fact based, boilerplate interviews. I sincerely believe I've been weeded out of interviews by interviewers who did not know the answers to the questions they were asking me, only reading scripted questions.

TomP
1.26.2008
6:17 PM

I suppose it depends somewhat on what type of development you want the prospective programmer to do. If the skills you need are specialized and you can ask specific questions about technical details, that's going to help determine what your prospect can do.An open ended question such as "Tell about toughest project you've ever been on." is apt to yeild insights into work ethic, teamwork, problem solving, and ego.I think the "Design the software for a gas pump" is a good question because it can yeild insight into the candidates problem solving style.Also, I think it's a good idea to have a few questions you ask each candidate. These become internalized and simplify the interviewing process (for the interviewer). Microsoft became notorious for asking "Why are manhole covers round?"

Justice~!
1.28.2008
3:14 PM

This gives me a wonderful post idea...thanks dude.I owe you one!

Bacardi
2.08.2008
12:56 AM

First off, I agree wholly with Toms' input. If a project calls for a specific technology and/or level of experience, then by all means more indept questions are in order. However, in general, I am interested in a candidates' problem solving skills and overall aptitude.A smart person can learn a new concept with relative ease. So the lack of exposure to a concept, by a candidate, is not an adequate measure of skill or aptitude. That is, as long as experience is not a requirement for the project.I have been on projects with developers who spend six months implementing a *framework*, but had no substantial UI, and could not yet read/write data. Now I won't argue right or wrong from a technical point-of-view, because the point appears trivial to the client who wants something now. I have worked at both large companies that appreciate the development life-cycle, and the smaller companies where the stakeholders get that glossy look in their eyes when you begin to talk about framework/architecture. At the latter point, they usually want to know, "how fast can it just work".Hard topic to condense, but I'll stop here.

Stephen Nimmo
2.18.2008
10:49 AM

I've been doing technical screens for a couple of years now and I basically look at their work history and ask them to explain what they did and why they did it. What patterns were used? What development methodologies were used? What did you like about your project? I'll throw some jabs in there about a certain technology or ask them to explain some configuration, but mostly, I just feed them the rope and see if they hang themselves. My frustrations: The language barriers for phone interviews. About 50% of my technical interviews are severely hampered by the inability to understand each other. Vague answers and/or google answers. They can explain the entire project but fail to explain what THEY did on the project. Or when you ask them about something on their resume (such as Spring) and you ask a simple IOC question and can hear them googling the answer.