http://www.hanselman.com/blog/BuildingWebAppsWithASPNETJumpStart8HoursOfFREETrainingVideos.aspx
I do a LOT of interviewing here, and for a while we were hiring ASP.NET people. Here's some of the questions that I asked them. I came up with these questions because you'd "just know" this stuff if you spent time working on a REAL WORLD ASP.NET site - through design, development, debugging, production debugging, and deployment.
I do a LOT of interviewing here, and for a while we were hiring ASP.NET people. Here's some of the questions that I asked them. I came up with these questions because you'd "just know" this stuff if you spent time working on a REAL WORLD ASP.NET site - through design, development, debugging, production debugging, and deployment.
Do they suck? Did I miss any? How do you think people did?
- 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?
- What are ASHX files? What are HttpHandlers? Where can they be configured?
- What is needed to configure a new extension for use in ASP.NET? For example, what if I wanted my system to serve ASPX files with a *.jsp extension?
- What events fire when binding data to a data grid? What are they good for?
- Explain how PostBacks work, on both the client-side and server-side. How do I chain my own JavaScript into the client side without losing PostBack functionality?
- How does ViewState work and why is it either useful or evil?
- What is the OO relationship between an ASPX page and its CS/VB code behind file in ASP.NET 1.1? in 2.0?
- What happens from the point an HTTP request is received on a TCP/IP port up until the Page fires the On_Load event?
- How does IIS communicate at runtime with ASP.NET? Where is ASP.NET at runtime in IIS5? IIS6?
- What is an assembly binding redirect? Where are the places an administrator or developer can affect how assembly binding policy is applied?
- Compare and contrast LoadLibrary(), CoCreateInstance(), CreateObject() and Assembly.Load().
The guy before me basicly answered my main question, but I was also wondering at what level would you consider a person who knew all the information for thier given classification?
Kris Gray
Geez, Scott. I guess I should quit now. This is depressing. ;)
I'd consider someone very senior if they knew all of these questions.
I'm looking forward to the followup post with the answers. :o)
My first take is, this is a much better list than the last one. (read: less trivialities.) It's reasonable stuff you should have encountered if you work in that area of the framework.
OK, if this list is what a real employer is looking for, why is it that the MS Certs require you to know almost none of these questions?
I would move "What is this? Can this be used within a static method?" to "Everyone who writes code". If you don't *get* objects, you can appear to write good code but sooner or later it will all fall on your head.
I'm still trying to decide if I'm going to ask any of these sorts of questions in the interviews I'll be starting soon for a senior ASP.NET dev. I know I'm going to ask candidates to write code. I think I will end up asking a few of these as well. As usual Scott, you rock and you're just-in-time, too!
Kate
I'm still trying to decide if I'm going to ask any of these sorts of questions in the interviews I'll be starting soon for a senior ASP.NET dev. I know I'm going to ask candidates to write code. I think I will end up asking a few of these as well. As usual Scott, you rock and you're just-in-time, too!
Kate
Even though I don't know half the answers to these questions I think it's a pretty good list for .NET Interview questions. Let's face it, if someone gets all these correct then you'd probably want to hire them! ;-) I'm going to take this on board and work through the ones I don't know the answers to -- and learn something. Thanks for the list Scott. Nice one!
I think a great .NET developer should also know proper grammar (ref title of post). ;)
These lists are a nice way to gauge technical experience, but they lack any way to discover if a developer is truly a great developer. A truly great developer knows how to work well in a team. You ever have a developer who knew the answer to all these questions but would trash talk and degrade anyone who didn't (I've met one)? A truly great developer understands that construction is only a small portion of a project lifecycle.
These lists are a nice way to gauge technical experience, but they lack any way to discover if a developer is truly a great developer. A truly great developer knows how to work well in a team. You ever have a developer who knew the answer to all these questions but would trash talk and degrade anyone who didn't (I've met one)? A truly great developer understands that construction is only a small portion of a project lifecycle.
I think haacked is right!
Perhaps you'll meet someone who never had any opportunity to work at great projects and could never prove he could be a great developer. Those people might be(come) great developers, but until then they just were great at home. At home, you can do great things, that are totally worthless for the business. They might've created great software, which isn't divided into layers, etc, etc. I hope you get my point, I cannot express myself currently that good in English ;)
I still think it's a great list though. Peolpe who DO know these questions, can be considered great developers. You'll still have to figure out if they're great for your company and/or team. But when hiring them, you can start with a good salary. The other can prove himself later on and earn his big paycheck then.
Perhaps you'll meet someone who never had any opportunity to work at great projects and could never prove he could be a great developer. Those people might be(come) great developers, but until then they just were great at home. At home, you can do great things, that are totally worthless for the business. They might've created great software, which isn't divided into layers, etc, etc. I hope you get my point, I cannot express myself currently that good in English ;)
I still think it's a great list though. Peolpe who DO know these questions, can be considered great developers. You'll still have to figure out if they're great for your company and/or team. But when hiring them, you can start with a good salary. The other can prove himself later on and earn his big paycheck then.
Ya, I know the title is all goofed now, but if I change the title, the permalink will change. :(
I can see that changing in the next version of Dasblog. :)
You can indeed Tim...I suspect I'll have to include a LIST of permalinks (a journal) for each title. Had I noticed it earlier it wouldn't have been a big deal.
Very complete list, and quite challenging !
I would move some question into another category, though.
For example:
Into "Everyone who writes code" category:
What is the difference between Dispose() and Finalize()
What is boxing ?
Is string a value or a reference type ?
Explain the use of virtual, sealed, abstract, override.
Explain the difference between public, private, protected and internal modifiers.
What is this ? Can it be used within static methods ?
Into "Mid-level developer":
What does this do? gacutil /l | find /i "Corillian"
Why is catch(Exception) almost always a bad idea?
Explain what’s happening in the first constructor: public class c{ public c(string a) : this() {;}; public c() {;} } How is this construct useful?
Into "Senior developer":
When would using Assembly.LoadFrom or Assembly.LoadFile be appropriate?
Moreover, I think some questions cannot be easily assigned to one of the developer-level categories.
For example, you can ask:
What is the difference between OOP and SOA ?
-- or --
Contrast the use of an abstract base class against an interface.
to all kind of developers, and the answer you'll get will be very different according to the developer's knowledge.
I personally think that a senior developer will prove its deep knowledge of the .NET technology if he can provide a good answer to the two questions above, rather than if he knows what sn- t foo.dll does :-)
However, thanks for the good list, I'm going to study/review a few topics after I relized I could not provide a good answer to some of your questions !
Claudio
I would move some question into another category, though.
For example:
Into "Everyone who writes code" category:
What is the difference between Dispose() and Finalize()
What is boxing ?
Is string a value or a reference type ?
Explain the use of virtual, sealed, abstract, override.
Explain the difference between public, private, protected and internal modifiers.
What is this ? Can it be used within static methods ?
Into "Mid-level developer":
What does this do? gacutil /l | find /i "Corillian"
Why is catch(Exception) almost always a bad idea?
Explain what’s happening in the first constructor: public class c{ public c(string a) : this() {;}; public c() {;} } How is this construct useful?
Into "Senior developer":
When would using Assembly.LoadFrom or Assembly.LoadFile be appropriate?
Moreover, I think some questions cannot be easily assigned to one of the developer-level categories.
For example, you can ask:
What is the difference between OOP and SOA ?
-- or --
Contrast the use of an abstract base class against an interface.
to all kind of developers, and the answer you'll get will be very different according to the developer's knowledge.
I personally think that a senior developer will prove its deep knowledge of the .NET technology if he can provide a good answer to the two questions above, rather than if he knows what sn- t foo.dll does :-)
However, thanks for the good list, I'm going to study/review a few topics after I relized I could not provide a good answer to some of your questions !
Claudio
Scott,
The list is interesting, but I don't agree with your levels.
For example, "Can DateTimes be null?" or "Is string a value type or a reference type?" are things EVERYONE should know, because they are important to write code from day 0.
Also, I've been working for 3 years in .NET and never heard of Corillian. And, while I know what PIDs are, I don't think everybody needs them.
There are a lot of examples, but I think these ones are representative enough.
The list is interesting, but I don't agree with your levels.
For example, "Can DateTimes be null?" or "Is string a value type or a reference type?" are things EVERYONE should know, because they are important to write code from day 0.
Also, I've been working for 3 years in .NET and never heard of Corillian. And, while I know what PIDs are, I don't think everybody needs them.
There are a lot of examples, but I think these ones are representative enough.
Getting to the point here - Okay so, if someone does know all the answers, how much $ can he ask for?
The list is challenging for sure. However I think that the mode of
thinking in using such lists lets talent slip through the cracks.
Einstein said to never memorize anything you can look up, so knowing
what gacutil /l | find /i "Corillian" does would, for me, start with
gacutil /?. I would guess that it would list all of Corillian's
assemblies in the gac, but I've never used gacutil before. Granted
I'm not a "great" .Net developer, just one learning to hopefully be
great one day.
Often times in the NFL quarter backs change teams and/or have to work
with new offensive cooridinators who have totally different offenses
than what the quarterback knows. If they brought in the quarterback
for an interview and started quizzing him on plays from their playbook
that he hadn't seen before, he could end looking terrible. However,
does he have the fundamental skills required by an NFL quarterback?
If so then he can probably quickly learn the new offense and be a
great player for the team.
Having said all of that, I'm going to learn everything on the list ;)
thinking in using such lists lets talent slip through the cracks.
Einstein said to never memorize anything you can look up, so knowing
what gacutil /l | find /i "Corillian" does would, for me, start with
gacutil /?. I would guess that it would list all of Corillian's
assemblies in the gac, but I've never used gacutil before. Granted
I'm not a "great" .Net developer, just one learning to hopefully be
great one day.
Often times in the NFL quarter backs change teams and/or have to work
with new offensive cooridinators who have totally different offenses
than what the quarterback knows. If they brought in the quarterback
for an interview and started quizzing him on plays from their playbook
that he hadn't seen before, he could end looking terrible. However,
does he have the fundamental skills required by an NFL quarterback?
If so then he can probably quickly learn the new offense and be a
great player for the team.
Having said all of that, I'm going to learn everything on the list ;)
Jamin Guy
Haacked: " A truly great developer understands that construction is only a small portion of a project lifecycle."
Hard to overemphasize this point. One question I always ask in interviews goes something like this: "You've been told by the project sponser that the project absolutely has to be done in two months - commitments to major clients have been made, etc. etc. You know that's impossible, and that a minimum of six months will be needed. What do you do?"
There are several reasonable answers to this, depending on circumstances. But the tone and quality of the answer will tell you a lot about this person's understanding of the software development process.
Or if I were choosing between:
A) a young, motivated developer who can't answer the list very well, but has a great attitude and seems to have a good potential to learn
B) a whiz kid who knows all the answers but has the people skills of a snapping turtle and can give you a thousand reasons why everything that's ever gone wrong in his projects are "somebody else's fault"
I'm picking A every time.
Hard to overemphasize this point. One question I always ask in interviews goes something like this: "You've been told by the project sponser that the project absolutely has to be done in two months - commitments to major clients have been made, etc. etc. You know that's impossible, and that a minimum of six months will be needed. What do you do?"
There are several reasonable answers to this, depending on circumstances. But the tone and quality of the answer will tell you a lot about this person's understanding of the software development process.
Or if I were choosing between:
A) a young, motivated developer who can't answer the list very well, but has a great attitude and seems to have a good potential to learn
B) a whiz kid who knows all the answers but has the people skills of a snapping turtle and can give you a thousand reasons why everything that's ever gone wrong in his projects are "somebody else's fault"
I'm picking A every time.
> Getting to the point here - Okay so, if someone does know all the answers, how much $ can he ask for?
It's more like "how many years until all the developers in India memorize this list"?
What you should be asking is, "can I come up with a list like this?" Being able to answer all the questions is a red herring-- it won't save your job. People with the ability to *CREATE* the lists are the ones who will keep their jobs.
It's more like "how many years until all the developers in India memorize this list"?
What you should be asking is, "can I come up with a list like this?" Being able to answer all the questions is a red herring-- it won't save your job. People with the ability to *CREATE* the lists are the ones who will keep their jobs.
Billy, there are many correct answers to your question such as...
#1 I tell the project sponsor "No Problem!" and then quit the day before it's due to be delivered to QA."
#2 I tell the project sponsor "No problem. I've fortunately have the ability to bend space and time to conform to your warped sense of reality."
#3 I tell the sponsor to perform an anatomically impossible act and start verbally abusing the sales team.
#4 From that day forth, I would only speak in a long dead language like Aramaic and point fingers at my coworkers.
Be sure to give one of these answers in your next interview.
#1 I tell the project sponsor "No Problem!" and then quit the day before it's due to be delivered to QA."
#2 I tell the project sponsor "No problem. I've fortunately have the ability to bend space and time to conform to your warped sense of reality."
#3 I tell the sponsor to perform an anatomically impossible act and start verbally abusing the sales team.
#4 From that day forth, I would only speak in a long dead language like Aramaic and point fingers at my coworkers.
Be sure to give one of these answers in your next interview.
Haacked, interestingly enough, I recommended answer #1 in my first book when I discussed dysfunctional development environments. It's certainly true that sometimes circumstances put you in a situation in which you cannot succeed. And leaving is an honorable way out (presuming you are not breaking other existing commitments by doing so).
But some don't have as many options as others, and some may not be ready to write off an otherwise good position for one impossible demand. While we may gain some satisfaction using the flip answers #2 and #3 among ourselves, we have to face the fact that those outside the process simply lack the perspective to understand the limitations of software development. So attempts at education, while not succeeding as often as I'd like, are not totally pointless.
But I think we're probably close together in general concept, and here's a test to see. About three years ago, I ran across a book in a bookstore entitled "How to Survive a Death March Project". I started to pick it up, thinking, "I might get some interesting tips out of this." Then I came to my senses and put it down, realizing that I am NEVER going to allow myself to be involved in such a project again. Life's too short for such nonsense. In that in line with your thinking?
But some don't have as many options as others, and some may not be ready to write off an otherwise good position for one impossible demand. While we may gain some satisfaction using the flip answers #2 and #3 among ourselves, we have to face the fact that those outside the process simply lack the perspective to understand the limitations of software development. So attempts at education, while not succeeding as often as I'd like, are not totally pointless.
But I think we're probably close together in general concept, and here's a test to see. About three years ago, I ran across a book in a bookstore entitled "How to Survive a Death March Project". I started to pick it up, thinking, "I might get some interesting tips out of this." Then I came to my senses and put it down, realizing that I am NEVER going to allow myself to be involved in such a project again. Life's too short for such nonsense. In that in line with your thinking?
One of the headings: C# Component (HI, TP) Developers needs to be unbulleted so it pulls out like the ASP heading...
Chris Kinsman
Will you be posting the answers for those of us less fortunate of having the knowledge to complete your list?
phuturekrew
Scott (and everyone else), I want to thank you for reminding me that I still have TONS to learn! I've cancelled digital cable at my house and brought all my computer books upstairs. I've got a stack as tall as I am to read!
http://www.devcow.com/weblogs/PermaLink,guid,bf5f8170-969d-4e73-b2d2-86139ae8efed.aspx
http://www.devcow.com/weblogs/PermaLink,guid,bf5f8170-969d-4e73-b2d2-86139ae8efed.aspx
I didn't expect this, but this fellow posted a bunch of the answers!
http://www.ayende.com/Blog/PermaLink,guid,b6e3e8ce-4a6e-4cf0-af70-d360be9e8c76.aspx
http://www.ayende.com/Blog/PermaLink,guid,b6e3e8ce-4a6e-4cf0-af70-d360be9e8c76.aspx
I don't see what all the flak is (especially when you did this last time). They seem like standard questions fo rme in knowledge of the areas.
I agree with several of the voices on this thread that you can't judge an applicant's competancy simply by her ability to answer a set of fact based questions any more than you can judge a person's intelligence by her ability to win on "Jeopardy!". Simply put, an individual's knowledge of facts is only one aspect of her ability to solve problems, it does not address the more important factors that go into making a good employee in general like:
1. How does she solve problems (as opposed to how does she regurgitate facts)?
2. How does she interact with others?
3. How does she deal with adverse situations?
4. How well does she communicate?
5. How well does she perform under pressure?
etc.
There are numerous factors that outweigh an individual's ability to memorize. Of course, knowing the answers to a set of questinos is useful since it *could* indicate experience in the topic area, but it is by no means a gauranteed method of finding a well rounded developer.
1. How does she solve problems (as opposed to how does she regurgitate facts)?
2. How does she interact with others?
3. How does she deal with adverse situations?
4. How well does she communicate?
5. How well does she perform under pressure?
etc.
There are numerous factors that outweigh an individual's ability to memorize. Of course, knowing the answers to a set of questinos is useful since it *could* indicate experience in the topic area, but it is by no means a gauranteed method of finding a well rounded developer.
Hmm, the only three I couldn't answer are the ones listed below, and I'm talking about detailed insightful answers. In the XML, I couldn't provide the same level of insights but I gave reasonable answers.
* Can attributes be placed on specific parameters to a method? Why is this useful?
* What is cyclomatic complexity and why is it important?
* What does this do? gacutil /l | find /i "Corillian"
------------------
I have a question of my own that I've asked many sr. developers and friends and coworkers and architects but thus far, I haven't recieved the correct answer. If you look this up or try it out before you answer than you've cheated < giggles >.
In C#, what is the difference between passing an object by ref and by value? (Yes, there is an important difference, a difference that has caused days of debugging because of pre-disposed assumptions we have about it).
... No cheating. Whats the answer? ... Scott? Anyone? I'll post the answer in my next post.
* Can attributes be placed on specific parameters to a method? Why is this useful?
* What is cyclomatic complexity and why is it important?
* What does this do? gacutil /l | find /i "Corillian"
------------------
I have a question of my own that I've asked many sr. developers and friends and coworkers and architects but thus far, I haven't recieved the correct answer. If you look this up or try it out before you answer than you've cheated < giggles >.
In C#, what is the difference between passing an object by ref and by value? (Yes, there is an important difference, a difference that has caused days of debugging because of pre-disposed assumptions we have about it).
... No cheating. Whats the answer? ... Scott? Anyone? I'll post the answer in my next post.
Okay,
First, Charles Chen sums up my sentiments quite well. I like to measure technical ability but teamwork is very important. Sometimes I have to compromise because good developers with a good attitude are very difficult to find, but for higher level positions its a requirement and there is no compromise.
I recently went to a new company (2 months ago) to be an archict and the Software Direct I reported to started when I started, but he had a very demeaning attitude and lots of micromanagement. When confronted about being micromanaged, he said if I don't like it I can leave. Well, I left and returned to my previous company (which I started at yesterday). He's been programming for 30 years. I've been doing it for only 15 (8 professionally, I don't could C-64/Apple IIe hacking professional).
When I interview, I put much less emphasis on what they know than I do on how they present themselves and how they solve problems and interact with other members of the team. Of course, I've not hired people before because I couldn't guage how they were technically because there is a certain minimum competance I expect. I don't want cowboys that will come in and do things their way or no way and re-write all the code because its not what they are used ito.
Anyway... the answer to my question above:
In C#, if you pass an object byval and set it to null, you are setting a copy of the pointer to null and not the object itself (being passed in). If you pass as ref, then set it to null in the function, then you are setting the actual pointer to null and everything else that points to it. In both cases your are passing a pointer into the function, but in one case you are passing the pointer itself, or a copy of the pointer. I don't think this is the same behavior in VB.NET but I haven't tested it.
First, Charles Chen sums up my sentiments quite well. I like to measure technical ability but teamwork is very important. Sometimes I have to compromise because good developers with a good attitude are very difficult to find, but for higher level positions its a requirement and there is no compromise.
I recently went to a new company (2 months ago) to be an archict and the Software Direct I reported to started when I started, but he had a very demeaning attitude and lots of micromanagement. When confronted about being micromanaged, he said if I don't like it I can leave. Well, I left and returned to my previous company (which I started at yesterday). He's been programming for 30 years. I've been doing it for only 15 (8 professionally, I don't could C-64/Apple IIe hacking professional).
When I interview, I put much less emphasis on what they know than I do on how they present themselves and how they solve problems and interact with other members of the team. Of course, I've not hired people before because I couldn't guage how they were technically because there is a certain minimum competance I expect. I don't want cowboys that will come in and do things their way or no way and re-write all the code because its not what they are used ito.
Anyway... the answer to my question above:
In C#, if you pass an object byval and set it to null, you are setting a copy of the pointer to null and not the object itself (being passed in). If you pass as ref, then set it to null in the function, then you are setting the actual pointer to null and everything else that points to it. In both cases your are passing a pointer into the function, but in one case you are passing the pointer itself, or a copy of the pointer. I don't think this is the same behavior in VB.NET but I haven't tested it.
Not to nit pick Shawn, but they are "References" not "Pointers." They refer-to rather than point-to. I personally don't like hearing C# programmers use the term "pointer" in an interview (outside the unsafe context), and if they do, I want to better understand what they are thinking.
The question you asked is a mid-level to everyone-should-know question. VB.NET has similar semantics.
The question you asked is a mid-level to everyone-should-know question. VB.NET has similar semantics.
Scott Hanselman
This list is bullshit.
For starters, if someone did actually know the answers I WOULD NOT hire them. They would probably be a total wet noodle book worm with no interpersonal skills and creativity.
Also, there is nothing that would relate to real-world problem.
Also, most companies would not hire such a person that knew all the answers. He/she would probably want more money than what the job paid. He/she should work for MSFT or just write arcane books.
Oh, and BTW, most of these questions are trival information to make the author sound smart.
For starters, if someone did actually know the answers I WOULD NOT hire them. They would probably be a total wet noodle book worm with no interpersonal skills and creativity.
Also, there is nothing that would relate to real-world problem.
Also, most companies would not hire such a person that knew all the answers. He/she would probably want more money than what the job paid. He/she should work for MSFT or just write arcane books.
Oh, and BTW, most of these questions are trival information to make the author sound smart.
Good stuff Ed. Nice to not leave your email address, full name, or website. It adds credibility.
I'm glad the list makes me sound smart. It wasn't the intent, but a nice side effect according to you.
Thanks also for indicating the triviality of the list - I look forward to your follow-up posting of the answers.
I'm glad the list makes me sound smart. It wasn't the intent, but a nice side effect according to you.
Thanks also for indicating the triviality of the list - I look forward to your follow-up posting of the answers.
Scott,
While I'll agree, the question isn't very advanced, but I've asked more people than I can count (I've guestimate) 50 or so over the last year and not one person has correctly answered the question. You didn't even answer it. And the terminology "pointer" I'll concurr is incorrect, old habbits die hard. Nonetheless, most people answer the question (in fact, I've even seen it in an MCSD study guide in the past this way too) that when you pass an object it passes a reference to the object (which is correct). But it never makes the distinction that if you pass an object as ref and set it to null in the method that you are actually setting the object to null everywhere (even outside the method) and if you pass it by value then you are only setting the local copy to null.
While everyone should know it, I've yet to encounter someone who has answered it correctly. You might be the exception (not being synical here) but everyone in person I've asked (which isn't many I'll admit) hasn't gotten it (even some prominant people in the community).
While I'll agree, the question isn't very advanced, but I've asked more people than I can count (I've guestimate) 50 or so over the last year and not one person has correctly answered the question. You didn't even answer it. And the terminology "pointer" I'll concurr is incorrect, old habbits die hard. Nonetheless, most people answer the question (in fact, I've even seen it in an MCSD study guide in the past this way too) that when you pass an object it passes a reference to the object (which is correct). But it never makes the distinction that if you pass an object as ref and set it to null in the method that you are actually setting the object to null everywhere (even outside the method) and if you pass it by value then you are only setting the local copy to null.
While everyone should know it, I've yet to encounter someone who has answered it correctly. You might be the exception (not being synical here) but everyone in person I've asked (which isn't many I'll admit) hasn't gotten it (even some prominant people in the community).
Scott, I think this is a good list, much improved over the previous. It is thought provoking. No matter how much you *I* think you *I* know I found myself second-guessing when my answers were correct. I looked at the list just now of answers in the link provided, I have more detailed explainations perhaps I'll post. It is a fun excercise anyway, I like guaging my readiness. Anyway, thanks for posting these and the others.
Concerning Ed., I'm glad to know you wouldn't hire me because I probably wouldn't want to work for you (or someone with the attitude your project in your post). I could answer them and I guarantee I'm not being paid anymore than I'm worth but I won't accept a Jr. developers wage, either... I'm well beyond Jr. and can demonstrate very quickly.
I don't view these questions as a end-all-be-all for determining anything in an interview. But just because someone can answer them doesn't mean they have no interpersonal skills. When I interview, I dig deeper into the personality and teamwork skills than I do technical, unless they are applying for a technical position (Architect?). I expect people to know there stuff, I guage that by a mix of questions (like these posted) and problem solving and hands on troubleshooting.
Concerning Ed., I'm glad to know you wouldn't hire me because I probably wouldn't want to work for you (or someone with the attitude your project in your post). I could answer them and I guarantee I'm not being paid anymore than I'm worth but I won't accept a Jr. developers wage, either... I'm well beyond Jr. and can demonstrate very quickly.
I don't view these questions as a end-all-be-all for determining anything in an interview. But just because someone can answer them doesn't mean they have no interpersonal skills. When I interview, I dig deeper into the personality and teamwork skills than I do technical, unless they are applying for a technical position (Architect?). I expect people to know there stuff, I guage that by a mix of questions (like these posted) and problem solving and hands on troubleshooting.
All,
While I disagree with the idea of this kind of list, I don't think that Scott is using this as his only criteria during an interview. At least I hope not. The big problem I have with these types of lists is that they are just facts devoid of context and don't provide any insight into a persons thought process (how hippie-esque of me to want insight into someones thought process).
I don't think it's nit-picky to correct someone who says "pointers" instead of "references" wrt .NET variables. ESPECIALLY if that someone had plastered ".NET Expert" on their resume as it's sitting in front of me. It's like calling your wife "my girlfriend". Although the two titles are similar, there is a WORLD of difference between the two. :)
While I disagree with the idea of this kind of list, I don't think that Scott is using this as his only criteria during an interview. At least I hope not. The big problem I have with these types of lists is that they are just facts devoid of context and don't provide any insight into a persons thought process (how hippie-esque of me to want insight into someones thought process).
I don't think it's nit-picky to correct someone who says "pointers" instead of "references" wrt .NET variables. ESPECIALLY if that someone had plastered ".NET Expert" on their resume as it's sitting in front of me. It's like calling your wife "my girlfriend". Although the two titles are similar, there is a WORLD of difference between the two. :)
Unfortunately, someone who can answer all of these questions correctly would quite possibly be a terrible hire. You can't tell the difference between someone who knows all the answers to these questions because they've paid their dues in the trenches versus someone who has a great memory and has read a couple of C#/.NET books.
For a truly useful hiring guide, check out http://www.joelonsoftware.com/articles/fog0000000073.html
I also disagree with the basic premise that a great .NET developer ought to know these things. I'd rather have a problem solver than a Jeopardy! champ on my team any day.
For a truly useful hiring guide, check out http://www.joelonsoftware.com/articles/fog0000000073.html
I also disagree with the basic premise that a great .NET developer ought to know these things. I'd rather have a problem solver than a Jeopardy! champ on my team any day.
James Osbone
> I also disagree with the basic premise that a great .NET developer ought to know these things. I'd rather have a problem solver than a Jeopardy! champ on my team any day.
You guys miss the point (and you didn't see Scott's PREVIOUS list, which was FAR more Jeopardy-like, but I digress).
I don't think Scott is saying that every .NET developer should know the answer to *all* these questions.
A .NET developer working in these areas should have run into the topics covered by these questions, enough to at least understand the question and provide a reasonable response. That implies that they're thinking about what they are doing and asking "why does it work this way?" and "what other ways could I do this?"-- and that's much more useful. Those are the people you want to hire.
I talk more about this here:
http://www.codinghorror.com/blog/archives/000220.html
You guys miss the point (and you didn't see Scott's PREVIOUS list, which was FAR more Jeopardy-like, but I digress).
I don't think Scott is saying that every .NET developer should know the answer to *all* these questions.
A .NET developer working in these areas should have run into the topics covered by these questions, enough to at least understand the question and provide a reasonable response. That implies that they're thinking about what they are doing and asking "why does it work this way?" and "what other ways could I do this?"-- and that's much more useful. Those are the people you want to hire.
I talk more about this here:
http://www.codinghorror.com/blog/archives/000220.html
What you don't get out of these questions are any of the intangibles. I have worked with people who could answer all of those questions who have the attention span of a gnat. So they run around with large egos doing what I think is the most fun (and hence often easiest because it is fun) 60-75% of development but leave the last part of actually *finishing* a software product to others (which I think is 95% of the work).
Ring a bell?
Ring a bell?
jack
I think it is possible for people to know the answers to all these questions especially if they are a consultant who at one point or another has been confronted with the need to know these answers. I'm sure Scott knows the answers as he wrote the questions. I know I was able to answer all but 3 of the questions but that is because I spend every waking hour of my life in a never ending quest to know more more more more and how and why things work.
The kinds of people who are likely to know the answer to more of these questions that the average joe are likely to be the kinds of people who have to constantly know how things work at a deep level, people who don't just do it because its a job, but rather a passion. I can't speak for everyone on that so don't take it as an over-generalization. I realize good people can be swamped.
I guess my point is that I wouldn't be scared if someone knew all the answers. But really, what is more important than anyone who can answer the questions, is how well they work on a team, their attitude, and how they approach problem solving (especially complicated problems). However, whether they read the answers in a book or learned it by experience, is somewhat minor. Some of what I know I read in books and trade magazines and online. Much of what I know I learned by experience. At some point, what I've learned will connect with what I'm actually doing. In many cases, what I've learned by reading but not doing, I've been able to assist other people in their problem solving.
What's important is that they understand conceptually (with regards to answering a list of questions) and not by fact-memorization otherwise indeed, the knowledge would be mostly useless.
But with all interviews questions, they shouldn't be the reason for hiring/not hiring, but only as a guide. There are so many more aspects to measure in a candidate than technical ability. I would even hire someone who couldn't answer most of these questions, if they were an otherwise motivated, good-attitide person, and want to achieve more than they can imagine. After all, that sounds a lot like me and I've accomplished some amazing things. And some of those things I accomplished while not being able to answer any of these questions. At some point we need to learn, and we are always learning because no one knows it all.
The kinds of people who are likely to know the answer to more of these questions that the average joe are likely to be the kinds of people who have to constantly know how things work at a deep level, people who don't just do it because its a job, but rather a passion. I can't speak for everyone on that so don't take it as an over-generalization. I realize good people can be swamped.
I guess my point is that I wouldn't be scared if someone knew all the answers. But really, what is more important than anyone who can answer the questions, is how well they work on a team, their attitude, and how they approach problem solving (especially complicated problems). However, whether they read the answers in a book or learned it by experience, is somewhat minor. Some of what I know I read in books and trade magazines and online. Much of what I know I learned by experience. At some point, what I've learned will connect with what I'm actually doing. In many cases, what I've learned by reading but not doing, I've been able to assist other people in their problem solving.
What's important is that they understand conceptually (with regards to answering a list of questions) and not by fact-memorization otherwise indeed, the knowledge would be mostly useless.
But with all interviews questions, they shouldn't be the reason for hiring/not hiring, but only as a guide. There are so many more aspects to measure in a candidate than technical ability. I would even hire someone who couldn't answer most of these questions, if they were an otherwise motivated, good-attitide person, and want to achieve more than they can imagine. After all, that sounds a lot like me and I've accomplished some amazing things. And some of those things I accomplished while not being able to answer any of these questions. At some point we need to learn, and we are always learning because no one knows it all.
Those who object to the questions are missing a point. Did Scott say that people who couldn't answer the questions would not be hired? Take for example the person who posted some answers to them... for one he wrote "What does this do? sn -t foo.dll
Does something to the strong name of the dll, probably show you the details of it, don't recall sn's CUI in my head. " This is a GREAT answer. It shows that you at least know what sn is for, and that backs up your claim that you're an enterprise .NET developer (well if you had no idea what sn was, or couldn't show me that you did, should I hire you?) If the person went on to say "I can fire up a dos box and go sn ? to see the options" then that shows me the person has actually used sn at least once (knows it runs at a command prompt) and knows how to look stuff up. That's actually different than someone who says they would Google for it.
Hire for attitude, train for skills... but the attitudes I want include "fast learner", "excited by our technologies", "knows where to look stuff up" and "remembers a lot of details." These questions serve as an opportunity to illustrate those attitudes.
Here's another example: during a code review of an ASP.NET system, you discover that a number of different pages are storing unrelated values in viewstate under the key "id". For example one page puts the customer is in viewstate("id"), another the employee id, and so on. What would you recommend be done?
How a candidate answers this will reveal technical experience as well as team dynamics and what kinds of process they like.
Does something to the strong name of the dll, probably show you the details of it, don't recall sn's CUI in my head. " This is a GREAT answer. It shows that you at least know what sn is for, and that backs up your claim that you're an enterprise .NET developer (well if you had no idea what sn was, or couldn't show me that you did, should I hire you?) If the person went on to say "I can fire up a dos box and go sn ? to see the options" then that shows me the person has actually used sn at least once (knows it runs at a command prompt) and knows how to look stuff up. That's actually different than someone who says they would Google for it.
Hire for attitude, train for skills... but the attitudes I want include "fast learner", "excited by our technologies", "knows where to look stuff up" and "remembers a lot of details." These questions serve as an opportunity to illustrate those attitudes.
Here's another example: during a code review of an ASP.NET system, you discover that a number of different pages are storing unrelated values in viewstate under the key "id". For example one page puts the customer is in viewstate("id"), another the employee id, and so on. What would you recommend be done?
How a candidate answers this will reveal technical experience as well as team dynamics and what kinds of process they like.
Heck, I don't even know what CUI stands for. Had to Google it.
<-- will never get hired by Scott H now. ;)
<-- will never get hired by Scott H now. ;)
Good questions, Scott. I totally agree with someone who posted a comment here that the people who can come up with the questions like these are the real skillful ones. That being said, I translated your questions for everyone into Japanese and answered them.
I picked two basic questions from your blog yesterday and asked them of an interviewee at my company. I asked him the difference between a process and a thread. He went, "Well, you know... there are so many classes in .NET Framework..." As you can tell by now, the guy didn't get the job. Of course, that's not the only reason why we didn't hire him, but I didn't like the fact that he didn't even attempt to answer the question. And it seems to be a very basic question to me if you have a B.S. degree in computer science, which his resume stated. (I have B.A. degree in education...)
I picked two basic questions from your blog yesterday and asked them of an interviewee at my company. I asked him the difference between a process and a thread. He went, "Well, you know... there are so many classes in .NET Framework..." As you can tell by now, the guy didn't get the job. Of course, that's not the only reason why we didn't hire him, but I didn't like the fact that he didn't even attempt to answer the question. And it seems to be a very basic question to me if you have a B.S. degree in computer science, which his resume stated. (I have B.A. degree in education...)
Good questions, Scott. I totally agree with someone who posted a comment here that the people who can come up with the questions like these are the real skillful ones. That being said, I translated your questions for everyone into Japanese and answered them.
I picked two basic questions from your blog yesterday and asked them of an interviewee at my company. I asked him the difference between a process and a thread. He went, "Well, you know... there are so many classes in .NET Framework..." As you can tell by now, the guy didn't get the job. Of course, that's not the only reason why we didn't hire him, but I didn't like the fact that he didn't even attempt to answer the question. And it seems to be a very basic question to me if you have a B.S. degree in computer science, which his resume stated. (I have B.A. degree in education...)
I picked two basic questions from your blog yesterday and asked them of an interviewee at my company. I asked him the difference between a process and a thread. He went, "Well, you know... there are so many classes in .NET Framework..." As you can tell by now, the guy didn't get the job. Of course, that's not the only reason why we didn't hire him, but I didn't like the fact that he didn't even attempt to answer the question. And it seems to be a very basic question to me if you have a B.S. degree in computer science, which his resume stated. (I have B.A. degree in education...)
Sorry for the duplicate messange and here is the URL where I translated your questions into Japanese.
http://www.vbaspcoder.com/PermaLink,guid,dc1d767c-f102-4747-aaa6-6e09c3bf98be.aspx
http://www.vbaspcoder.com/PermaLink,guid,dc1d767c-f102-4747-aaa6-6e09c3bf98be.aspx
In my experience giving candidates strait quiz questions rarely finds good people. It only takes one or two of these questions to tell if someone lied on their CV asking many more is futile and tends to make candidates nervous and defensive.
You can usually teach people most of these technology skills anyway if they lack them, it is much harder to teach them general problem solving skills that stand the test of time.
Scott Berkun gives a different view of what to ask in this essay: http://www.scottberkun.com/essays/essay39.htm
Follow this and you are more likely to get at a candidates soft skills which are so important when building a team.
You can usually teach people most of these technology skills anyway if they lack them, it is much harder to teach them general problem solving skills that stand the test of time.
Scott Berkun gives a different view of what to ask in this essay: http://www.scottberkun.com/essays/essay39.htm
Follow this and you are more likely to get at a candidates soft skills which are so important when building a team.
Billy, yes, that is inline with my thinking. That's why I'm independent now. ;)
Way cool brain teasers.
Is there an answer key somewhere?
Is there an answer key somewhere?
This list confirms my expectations of .NET developers. It points to a culture where memorization of the minutia of a very poorly-designed API is considered a virtue, and elegance is simply unheard of.
Until your organization begins to select people on the basis of their ability to *invent*, and *imagine* a creative solution to an open-ended question, it will be more of the same old, same old.
Face it: "great .NET developer" is as much of an oxymoron as "Windows XP Security". Great developers don't tolerate the platform on which .NET runs.
Until your organization begins to select people on the basis of their ability to *invent*, and *imagine* a creative solution to an open-ended question, it will be more of the same old, same old.
Face it: "great .NET developer" is as much of an oxymoron as "Windows XP Security". Great developers don't tolerate the platform on which .NET runs.
J. Random Poster
OK, I give up... What is the difference between typeof(foo) and foo.GetType()?
Obviously typeof operates on types and .GetType() works for instances but is there anything else? Something more magical? I'm hoping typeof() is quicker because it *could* be evaluated at compile time or something?
Obviously typeof operates on types and .GetType() works for instances but is there anything else? Something more magical? I'm hoping typeof() is quicker because it *could* be evaluated at compile time or something?
Lists like this are pointless and are of no value to ANYONE. You can create a million lists like this and still be no closer to the end... such is the complexity of the framework.
Understanding processes and architectures are key, not specific questions on xml libraries for eg.... because they are always in flux.
Understanding processes and architectures are key, not specific questions on xml libraries for eg.... because they are always in flux.
Hi,
I have an interview next week. Can you please post some sample interview questions on .NET? I found a few sites below that have some questions, but need a few more samples to feel confident!
http://techinterviews.com
http://www.interviewboard.com
Thanks.
- Prashant
I have an interview next week. Can you please post some sample interview questions on .NET? I found a few sites below that have some questions, but need a few more samples to feel confident!
http://techinterviews.com
http://www.interviewboard.com
Thanks.
- Prashant
Prashant
Why is it, for being more of a mid-level developer (4 years), I know more answers to Senior-level questions than the mid-level ones? :0
Hey thanks scott :)
i have an interview next week..
let me ask u these questions (to clear my mind :) )
which one of these will u prefer as an answere from an interviewee:
1> Textual answere
2> Practical answere
3> Mixture of both
4> or a confident bluff (not always, but at some instances)
what impresses u most in an interviewee?
attitude( &/or confidence) or knowledge level
How was ur first interview? ( ;) )
(well , i cant think of anymore questions right now, i will be asking as soon as they come ;) )
i think the questions framed are good and covers most of the knowledge level one expects from a s/w developer (at their specific levels)
i have an interview next week..
let me ask u these questions (to clear my mind :) )
which one of these will u prefer as an answere from an interviewee:
1> Textual answere
2> Practical answere
3> Mixture of both
4> or a confident bluff (not always, but at some instances)
what impresses u most in an interviewee?
attitude( &/or confidence) or knowledge level
How was ur first interview? ( ;) )
(well , i cant think of anymore questions right now, i will be asking as soon as they come ;) )
i think the questions framed are good and covers most of the knowledge level one expects from a s/w developer (at their specific levels)
So, while such lists have value, an interviewer should not read too much into a person's lack of knowledge about one specific area. Heck, the reason I'm not working for Microsoft today is that a gearhead C++ guy didn't think I knew enough about the Windows API. (He asked a question about accessing an API function, and I told him I did that a couple of years back, wrapped it up in a VB function, and never thought about it again. That was evidently not the answer he wanted.)