Scott Hanselman

The only one I didn't get is the last...

I'm going to assume that LoadLibrary is a C Win32 thing, CoCreateInstance i think is a COM thing, and the fog of memory seems to recall that CreateObject is a VB/VBScript thing.

What do these have to do with asp.net? Do you really think a dev would "just know" the minutae ( or heck, even what they are ) of these functions after developing a real world asp.net app?

Now, some might say that somebody who doesn't know this stuff isn't worth hiring... and obviously it's fine to have your opinion on that, but to say that it's indicative of your competency for developing asp.net apps... seems dubious.

That said, I think the rest were solid asp.net questions. Sorry if the last comment came off harsh...

Great questions, Scott. Despite working with ASP.NET for a while now, it doesnt look like I'd pass your interview! Does anyone fancy publishing the answers, or is that an excercise left to the reader? ;-)

No worries, Andy, I know what you meant. I think the LoadLibrary stuff is like understanding WWII and being able to put Vietnam in historical context. If you understand LoadLibrary, etc, then you may be more able to debug issues around Assembly Loading and versioning, understand the GAC, etc. Not a requirement, but I just like it when folks have a DEEP historical perspective. Ideally from Managed Code to Microcode. But that's just me.

Olly...which ones didn't you get?

WOW! I may have gotten 2 or 3. I am fairly new to ASP.NET (I hope that explains it), but I consider myself well versed in IIS/VBScript/ASP. Until recently most of my day-job work was still ASP, so I've only had a chance to play around with side projects in ASP.NET. I too hope you will post answers, if not I guess I will hunt them down (which I guess will be a nice exercise in and of itself). Guess I still have a lot to learn.

I am not a ASP.NET developer but I could hit most of your questions just by virtue of the fact that I read Fritz Onion's Essential ASP.NET book. I guess that means you are on the right track?

The last question threw me off just like Andy. Not that I couldn't answer it (actually I couldn't.. convincingly... :-)) -- just can't see the relevance to ASP.NET. Plus your historical perspective goal is laudable but regular 9.00-5.00 programmers hardly get into that frame of mind IMHO.

cheers!

Huh, I was able to answer half, and then one of them just partially. Do you really want someone to know off of the top of their head the 16 (or so) events that the DataGrid fires? What if someone recently came from a position where they used the Infragistics grid exclusively? Maybe they have not touched the basic DataGrid in a year. And HttpHandlers, what if someone really had no use for them in their work on a production system? I do think your number 1, 5, 6, and 7 are general enough that most everyone should have some knowledge about them if they have used ASP.NET for a decent period of time, but the others I am not sure about. I have been using ASP.NET for over a year and a half (not full-time though) and don't know, off of the top of my head, all of the details on the others. But then, my personal opinion is that it is good to ask questions with the intent to 'stump' the candidate, simply to see if they can admit to not knowing something. That in itself can be a valuable trait to have in an employee.

How did most people fare?

Most people get about half. The ones that are really important are 1,3,5,6. The last two are more Lead Developer questions - it's nice to ship an app, but then try shipping a PATCH that doesn't require a recompile. If you have a versioning strategy, those come up.

Good thought about the stump the candidate...that's not the intent, but the IDon'tKnow issue comes up a lot. I hate it when folks don't say I don't know. I say it FIRST just to get it out of the way :)

I think these are all valid questions, except for the last. I understand your explanation for including it, it would paint a better picture of the prospect's history, but I don't think it is necessary knowledge to prove your experience with ASP.NET. I'd think of it as a "bonus question".

The only other caveat I might add would be to the first question... I know the events exist, and I know how/when/why I would use them, and I know where to look if I want the complete list, but I could not list them all off the top of my head.

http://www.techinterviews.com/index.php?cat=9

I'm gonna concur with the rest that the last question isn't really an ASP.NET question. I feel pretty competent with ASP.NET but I'm no Win32 developer so I wouldn't have gotten that one.

The rest are pretty good. I've asked a couple of those. I might also ask about the various places you can store data (cache, session, viewstate, etc.) and the different pros/cons about them. You'd be surprised at the number of people whose experience ends with the word "cookie."

I've also asked: Say you have a class in your ASP.NET app with a static numeric variable. Could you, or could you not, use the variable as a page hit counter, and why?

Do you really want to hire someone? Or are you out to haze the poor slob who came through your door after reading couple of books and implementing his friend's site and threw in a web service for good measure..
Sorry, i am being facetitious (sp?).

No, I really want someone who:

* Is more than just a "File|New Website" and "Page_Load" person!
* Cares about technology and digs to learn how it works
* Has a sense of history, which will make them a better and deeper debugger

I don't care if the guy has MSDN in his head, I want to know how much of a problem solver he/she is.

When I worked in ASP2/VB6/COM+ world I used to be pretty evil with my questions, I would dig into the minute detail of the workings of com objects and how they work and how it was relevant to the vb6 coder and generally ensure the interviewee knew Ted Pattisons vb6 com book backwards.

I've been doing asp.net for 2 ish years now and I couldnt answer most of the questions off the top of my head, but I know why you are asking each one and the problems areas they cover, i just stopped trying to learn everything off the top of my head. What I do now is learn where the issues are and where the answers are when I need them. Although thanks to teched I know the answers to the versioning one backwards.

Considering the size of .NET, even if you are specializing in ASP.NET Im not sure this type of questioning will find you a problem solver, it will find you someone who can remember stuff, not necesarily be able to do anything with it.

How's it worked out for you so far ? Did you find the dev your looking for? If so perhaps I'll ask a couple of these myself (I do tend to ask the page lifecycle one quite a lot though).

Scott, alas i would rate it a weak set of interview questions. Too much dependency on generic MSDN knowledge, too little of real problem solving questions. Postback and Viewstate questions are good since its fundamental ASP.NET concepts, the rest is so-so next to just bad.

Any questions you ask really should just give you the binary result - "hire / no hire". http://www.joelonsoftware.com/articles/fog0000000073.html
is it hire or no hire if person doesn't know where ASP.NET is hosted on IIS5? no clue! is it hire or no hire if he never used ASHX files before? no clue. "F1" questions won't help you determine that at all.

I would structure it
1) Couple ASP.NET fundamental questions (like viewstate)
2) Couple general fundamental questions (what is design pattern? difference between type and interface? design by contract?)
3) couple puzzle questions: http://discuss.fogcreek.com/techinterview/

Then determine: is he smart? does he understand fundamentials? HIRE! (he will learn all the ASP.NET MSDN details in few days anyway) otherwise: NO HIRE.

I can answer 1,3,5,6 and 7. The others are aspects of Asp.Net I have just never dealt with before. I would expect that most interviewees with 1+ years of experience in a good development environment for a real application would be able to answer half easily. 2 or 3 others they would know where and how to get the answer quickly, such as the datagrid events (seriously, who remebers all the datagrid events?) 2 or 3 questions I would expect them not to have a clue, and that would be perfectly acceptable, such as 8 9 10 11, which 8 and 9 you shouldn't even be asking a developer. Those are architect, system analyst, sysadmin whoever questions, not something a developer should have to know. Even number 10, you question even states "administrator" in the question. Having said that, on the other side of the coin, I would expect the Team Lead/Project Lead to know the answers to those questions. The still have to be concerned with versioning, the config files, the different binding policies (how many are there, administrator, publisher, application, host?). But for most developers who are just developers, I think the latter questions don't apply.

Lets be honest, you don't even have to know half of these to be able to build a great ASP.net application. Only a few of these are ones I would say that even intermediate developers should know. Are you trying to hire someone to write an ASP.net book or something? What irritates me is when I go into an interview, and they expect me to know the answer to every advanced feature of a technology. People like that already have expectations that are unreasonable. In my opinion, you need to know that the person has worked with the technology before, what kind of applications they built, exactly what their function was on the team, and most important, do they know how to find the answer to almost any problem fast(not to mention non-technical aspects of the person, which can be just as important). If somebody forgets one of the class-level accessibility levels for C#, do you decide not to hire them because of it? You can find the answer to it in about ten seconds using help. Page events...ten seconds in help. Do you have to know about custom Http handlers? Nope...although they're very cool, I haven't had the need to use a single one yet...but anyway, Google for it in ten seconds. "Assembly binding redirect"...never even heard of it, and doubt I will ever need to know what it is. People need to stop asking tiny detail questions in tech interviews. If you're a good interviewer, you should be able to find great developers without even asking a single "technical detail" question at all. Of course, if you're looking for someone to help you write your next ASP.net book, or as a lead developer of a large team, then you do have to delve deeper. Another annoyance when going to an interview is when they ask you to do a written or computer-based technical exam, which I find offensive after six years of development experience....but that's another interview-related topic. I really hope you didn't decide to not hire people just because they didn't know these questions. Not everyone knows all that you do, Scott! It's why we read your blog. ;)

Incidentally... where do you find documentation for ASHX, just could never seem to find it in MSDN. And typing it into the filters doesn't give me anything.

Nice questions, but I'd ask more general technical questions as well. For example, what is the difference between HTTP and HTTPS? What are some types of authentication commonly used in an HTTP application? Write some code to add a CustomValidator to an ASP.Net TextBox...etc.

BTW, would you hire someone who only has a BSEE instead of a CS degree? My contracting company was not able to present me to your company b/c of my degree. Just wondering...

Personally, as someone who took 11 years to finish my BS, I'm not too worried about the degree thing. Send me your resume and I'll find out who made that "filtering" decision.

Marauderz: MSDN article on HttpHandlers.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/httphandl.asp

"I don't care if the guy has MSDN in his head, I want to know how much of a problem solver he/she is. "

But you're not asking problem solving questions, you're asking factoid questions. I ran into this a lot in college, specifically in the science classes I took. If you want to know about a persons problem solving skills and gauge their knowledge at the same time, you should create questions that use specific pieces of knowledge, "factoids", when solving a problem. Take these two questions.

"How does ViewState work and why is it either useful or evil?"

and

"From constructor to destructor (taking into consideration Dispose() and the concept of non-deterministic finalization), what the are events fired as part of the ASP.NET System.Web.UI.Page lifecycle. Why are they important? What interesting things can you do at each?"

Anyone can memorize those questions and regurgitate them upon demand. What you're looking for is someone who can apply that knowledge. Why not ask a question like "If you wanted to handle the storage of data to the viewstate on a page, how would you do it? Can you think of any reasons why you might have to do this?".

Your list reads like a college professors exam. ;)

Michael S:

Do you really believe that one can be an effective developer without knowing half of these questions? Don't you think it's important to have a deep understanding of the underlying platform?

Everyone, tell me this: what is filling the developer's brain, if not details like these?

Do you think your doctor knows EXACTLY how your body works before he/she prescribes you a drug or therapy regime or do you think they have a better-than-a-laypersons understanding of the underlying platform and can make well educated guesses at what might be wrong and what might fix the problem based in large part on past experience?

The question is, do you want someone who could pass a test or do you want to see how someone uses the knowledge they have? Sure you can weed out some people by asking them specific factoids. "Oh I see you put down you are a COM expert, how would you use CoCreateInstance?". You could study up on HttpHandlers right before the interview and pass your quiz without ever having written one!

Again, I don't feel that asking a candidate these questions is really interviewing them. You are just testing them and asking them to regurgitate information. You're quizzing them. That's just my take on it. I'm sure your interview is more than just a pop quiz. I'm assuming that you only posted the ASP.NET related questions because there are a TON of other questions related to information architecture, UI design, HTML and DHTML that I would ask a prospective ASP.NET developer. If the person can't write a RegExp in Javascript and s/he's applying for an ASP.NET position, I don't care if s/he can write a COM server. I don't want to have to spend all my time tutoring someone in HTML and Javascript or correcting layout.

P.S. The ASP.NET page lifecycle events are on page 49 of Fritz Onion's "Essential ASP.NET" book which is right beside my desk. If you know where to look up the factoids, do you need to memorize them? EVentually with experience you'll learn them all. That's the one thing I did get from my college degree, knowledge comes from experience and use your resources.

That's two things and I'm dumb. ;)

It is very important to know the underlying platform. But, sad fact of the matter is that Microsoft has made sure that .NET is vast enough that there is no way one person can learn them all unless he/she is writing a book or is teaching in DM or some such training place.
Here is what I think the problem is. As a developer, you learn a boatload of stuff about .NET. But, not necessarily just ASP.NET. For e.g., I have been working with ASP.NET off and on for the past couple of years. My main line work was still in VB6,Java and classic ASP.
Now, considering that, I have worked with C#, ASP.NET, ADO.NET, web services, VB.NET and XML (extensively). Now, with that in mind, do you really think that I will be able to actually get to the bowels of these systems individually? I love knowing the nitty gritty. So, I read up on IL. But, beyond that, most of what I learnt was to make sure I got my job done. If my job description was "ASP.NET developer only, dont bother with build (NAnt), test (NUnit), deploy (MSI/Installshield), Database (ADO.NET),s ervices ([WebService])", probably, I could have learnt everything that is possibly there about ASP.NET.
But, Given the state of technology flood we have with .NET 1.0, 1.1 and 2.0, it would be impossible for one person to be an "expert" in one technology. Most of us are usually "jack of all trades".

Of course, its just my opinion and I could be wrong.

--------
Do you really believe that one can be an effective developer without knowing half of these questions?
--------
I do, as well as many other people posting comments here. I liked what 'girish' had to say...to be a web developer, there are so many technologies you have to know, that it is near impossible to learn everything about every one of the technologies today. An effective developer just has to have a good overall understanding of them all, then know how to find the answer to any problem fast (search, help, newsgroups, magazines, MSDN, etc.). As you gain experience, you do begin to master various pieces of web development. Does it require mastery to be an "effective" developer though...not in my opinion.

--------
Don't you think it's important to have a deep understanding of the underlying platform?
--------
That's a good question. It really depends on the level of developer you are looking to hire, and it depends on the type of applications that the person will be building. Certainly, the more you know about your profession, the more valuable you become to an employer. Still, if you are looking for a senior ASP.net person, you won't even be considering people under a certain number of years of experience. Nobody works years in web development and does not pick up tricks and workings of parts of the underlying systems. Maybe it comes down to how you determine the value of a candidate that you know nothing about. I believe that a great interviewer can tell in a short time whether a candidate is intelligent and clever-enough to be able to handle the given position, without even asking a single technical question.

I hire a lot of ASP.NET programmers - they are experienced programmers who write good code - I'd venture to say that few of them could answer all these questions lucidly.

When I was younger and more hubristic, I used to ask stuff like this but as most commenters have noted - the minutiae is irrelevant. The ability for an applicant to solve complex problems is more interesting to than if they've memorized the page events.

As the old saying goes - tests are difficult for any man because even the greatest fool can ask questions the wisest man can't answer. ;-)

I think that some of these questions are outside the scope of a typical daily ASP.NET developer. For example: "How does IIS communicate at runtime with ASP.NET?" My answer for a dev is that it doesn't matter. In OO thinking, ASP.NET code is encapsulated and protected safely within the ASP.NET engine. We could really care less how the inputs and outputs are actually being dealt with by IIS. This question seems more suited to a systems administrator.

Max S.'s comment above stated it best, quote:
"Too much dependency on generic MSDN knowledge, too little of real problem solving questions. Postback and Viewstate questions are good since its fundamental ASP.NET concepts, the rest is so-so next to just bad."

No pattern questions? How about this: Describe how Web Forms relate to the MVC design pattern?

Gang of Four: What is Singleton, Factory? Compare object composition to inheritance, which is better (maybe neither)?

Where are the OO questions? Example: open-close principle, fragile base class problem, law of demeter,etc.

If they knew all the technicalities of .NET that you're looking for but none of these other questions I'd be scared to hire them. After all, I'd want someone that knows how to *design* software, not simply hack it.

Great ideas with the pattern questions. You sure tickled my brain with the Law of Demeter...I wonder how many people remember THAT one!

That's funny because the guy who started off LoD is actually the VP of research in my company.

Of course, the best interview question of all:

"Have you ever seen a grown man naked?"

Alternately, from the book "Showstopper" (about the development of NT ~ 1990), an interview question asked of candidates for Dave Cutler's secretary:

"How do you feel about the word 'F**k'?"

oh, I forgot the 'winning' answer; this candidate got the job.

"It's my favorite word."

Brilliant :)

Besides architecture, a good developer should also have infrastructure knowledge. Take for example J2EE developers, which i use to be in a former life. They can design the hell out of a system, but rarely does it scale well.

I also agree with what Jeff K said above. Having been a consultant all my adult life, the best developers I've worked with haven't been the MSDN savant's - but developers who had strong fundamental development skills, excellent problem solving skills, and the nerve to admit early that they dont understand an issue.

I wouldn't ask them asp.net 2.0 questions yet? 1.1 is so vast, many people don't know 50% of it.


I would concentrate my question on real life production work.

- Questions on security like how to stop sql injections and cross site scripting, trust levels, encryption ...etc
- Questions in performance and optimization like caching, round trips, select statements..etc

Plus some general troubleshooting ones like what do you do when such and such happens.

Abdu

Your typical stupid interview questions. What classes, events, etc you use in .NET totally depend on the project at hand. There might be a kick-ass programmer who has created scalable enterprise applications without ever needing ashx files. Ask more questions about design/architecture. You can teach a monkey about ashx files and other ASP.NET intrinsics in a few minutes but design/architecture takes years of experience and learning.

I suppose I would *not* bring in the person that could answer all these trivia questions. I am not looking for highly specialized geeks, but rather someone who can develop solutions and solve problems, is a good team player, knows what a good UI looks like, and is confident with SQL and databases.

I would be looking for a much broader set of skills: design/architecture, performance tuning, some UML, some patterns, data modeling, db transactions, security, problem solving, state management, load balancing, IIS, deployment, social skills, C#/VB.NET, on and on. Ideally the candidate will have a history of successful products/projects. Having an MCSD for .NET also helps: it shows initiative and interest in learning. My 2 cents.

Ok, I'm willing to say they are fair questions in the sense they may give you an idea of your candidate's depth. I couldn't answer several of them, but I don't function primarily as an ASP.NET developer. That said, I'm a helluva problem solver. I can't see how any of these questions probe problem solving ability which you claim is a primary goal of your technique.

I'm willing to take a leap here and say that while this kind of knowledge is probably important, we all know that the coding is a small part of the software development process. I'd take a coder new to ASP.NET that understood how to elicit and document requirements, verify and validate those requirements against a specification and had a track record of success before I'd take an ASP.NET academic who could answer the above questions but couldn't answer questions about software lifecycle.

As far as problem solving goes, I advocate a challenge within the domain the candidate is being considered for. "Write me an ASP.NET page that pulls from this database and displays this data. Allow a user to edit it. Make sure you validate this data against these rules. Then send we your solution by next Monday."

Good talkers and memorizers can fool you. Someone forced to DO something has a higher probability of producing results on which a good decision can be made.

"Do you really believe that one can be an effective developer without knowing half of these questions?"

Yes. I am an effective developer, in ASP .NET I might add, and I don't know the answer to half your questions off the top of my head.

"Don't you think it's important to have a deep understanding of the underlying platform?"
Yes and No. Yes it's important to understand that ASP .NET is a web environment, but no it's not important to have all the details of how the underlying infrastructure works. That might be useful information in some contexts, but for the applications I've worked on, it's been irrelevant. Of course, on some level I'm making use of all that information, but the beauty of OOP is that I don't have to know how all of the components I use work internally. The beauty of ASP .NET is that in most cases (at least the cases I've worked on) the complexities of the underlying architecture are hidden from me, leaving me free to create the solution. If I'm a System Admin then it's a different ballgame, but not as the developer.

"Everyone, tell me this: what is filling the developer's brain, if not details like these?"
I can't speak for everyone else, but my head is filled with strategies and approaches. I spend my time designing strategies to solve problems. I don't worry too much about the details because I can look those up as needed in any of hundreds of books. On rare occasion a detail makes me rethink some part of my development strategy, but on a fundamental level my designs remain intact.

Great blog btw.

Hi Scott,

are you realy think, that candidat should know this:
- J# (LoadLibrary())
- Win32 API (CoCreateInstance())
and
- ASP.NET 2.0

I find these questions as little over... ;)

Or your mean old Win API LoadLibrary()?

I would say these are definitely good questions. Makes us wonder how much deeper the rabbit hole goes. ASP .Net and the .NET Framework is really a wonder land and it is really vast. No one developer would know all the questions. May be the questions above help more in debugging than anything else. They may also be good in programming. But ASP .NET is not rocket science. Through experience anyone can get comfortable with developing applications. If you get stuck, ask the world ... the Internet is always there. What is the big deal? Even the interviewer won't know all of the answers to all the nuts and bolts of .NET. I could dig up 10 questions as good as the ones above and make sure that the interviewer is not able to answer even half of them. So where do we draw the line?

This is just trivia. I've been working with asp.net for 1 1/2 years and
was able to answer them all. I do a lot of msdn reading, there's no
problem solving skills involved in any.

I think being careful to understand that candidates come from projects that may be heavily specific or specialized in a few areas of application development. In the time it takes for the average sized corporate dev project to complete, the technology can change a couple times.

I used to work a lot in firmware - our products may ship one year with a particular MPU, the next with a different set of PIO's and the next a completely changed architecture. I didn't care so much that a developer knew the language jargon, or the specific language library, or could recite the complete mnemonic instruction set...I was more interested in their problem solving skills.

How do they approach a difficult problem? Are they resourceful? Can they find the information and apply it to the situation effectively?

Perhaps this is why so many IT departments have such a high turn over - because they have managers who may know their product well, but are actually shallow in their overall IT strengths and rely heavily on jargon and product centric minutiae.

..just a thought :)

has 300 plus interview questions for .NET it rocks
http://www.geocities.com/dotnetinterviews/