|
ASP.NET developer interview questions
I am interviewing some candidates for a ASP.NET developer position next week and would like to ask them a couple of code questions. I was thinking of giving them 3 questions and get them to do as much or as little as they can in 15 minutes (I would setup a computer with Visual Studio.NET etc).
Has anyone got some suggestions for good questions? Most of the work they would be doing is typical ASP.NET applications with a lot of data access, so I was thinking of having one question asking them to get some data and display it on a plain page - would be useful to see if they used SqlDataReader/DataSet and DataGrid/Repeater and why. But would a question like this be too long for 15 minutes? Should I give them some code and get them to finish it?
Any other suggestions?
Ben R
Friday, January 9, 2004
It might be too long, it's a worth while endeavor but you might want to allocate more time, because more time will give them the chance to put in the touch they would normally like. That way you can see their skills level and maturity. But not so much time that they end up twiddling their thumbs or adding useless tricks. From a more high level inspection, if you have 15 - 30 minutes, you might want to ask something else that's useful with that time, besides a trivial test like that. The kind of discussion or more general computer-related problem solving puzzles (without having to code) discussion might get you a feel you otherwise won't get on paper.
Li-fan Chen
Friday, January 9, 2004
I would attempt to probe a bit at how they would handle database access. Would they try to build a business objects layer and keep database access centralized there?
How would they handle exceptions?
Do they call the Close and Dispose methods on their data access components, or do they just wait for the Garbage Collector to pick them up, thusly chewing up database resources?
Do they know anything about programming to the ADO.NET interfaces so that they can keep the database interface generic, but yet still take advantage of each database's provider?
Some of those are more architecture focused than developer focused, but any time you start dealing with database side of things, the architecture becomes a big issue.
Mark Hoffman
Friday, January 9, 2004
If you give them time, you'll turn the terse high school pop quiz answer into a style+programmer exploration.
* You'll find out who adds error handling properly, who's not.
* Who makes way for the next guy to code by clearly naming functions, properly sources snarf and barfs, who documents, or is afraid to blaze their trails or make suggestions to current style guidelines (some people won't speak up when they see immature or bad coding practices, they'll even make do and emulate the bad coding practices because they are afraid to offend team members at the expense of project excellence)
* Who uses advanced features, who shys away from them?
* Who's interested in future optimizations?
* Who can budget their time well? Did they leave the function undone?
* Who knows how to find out more if they can't implement the solution at first glance? Do they carry a knowledge base cheat sheet (ahem, ofcourse, one that doesn't belong to a previous employer) on a business card cd--or do they just search aimlessly on google? Can they find stuff on google or MSDN?
Etc etc...
So if you have 15-30 minutes to spare, properly conducted quizzes will give you revelations that otherwise wont' be uncovered until after you sign them on.
Li-fan Chen
Friday, January 9, 2004
What Mark said :-)
Li-fan Chen
Friday, January 9, 2004
I know nothing about ASP.NET, but I think your idea is a bad one because it creates an unnecessarily high pressure environment with a billion chances to blow up (DB access screwed, user uncomfortable with IDE, etc.
If what you really you want to know whether they should use XXXReader or YYYReader, why don't you ask (though posing the question that way is borderline IMO)? And more importantly, listen to their reasons for their answer. That's far more instructive anyway. And who knows, you might even learn something.
Trying to catch errors by looking over his shoulder and seeing if he does something the way you think it should be done doesn't accomplish as much as understanding why he does things the way he does and if he's a good thinker.
Crimson
Friday, January 9, 2004
I'd agree with Crimson. It's like a university admissions department weighing SAT scores over cumulative high school grades and extracurricular activities.
Look at past projects, ask how they accomplished certain tasks, etc.
My two-cents' worth....
Chi Lambda
Friday, January 9, 2004
"some people won't speak up when they see immature or bad coding practices, they'll even make do and emulate the bad coding practices because they are afraid to offend team members at the expense of project excellence"
You know, it's my continuing inability not to just shut up and cope with the substandard behaviour that keeps losing me jobs. Sometimes in the sense of "I have to leave before I kill people."
It is scarely surprising that an ability to "make do and emulate bad practices" is such a common attribute. The business environment is perfectly set up to encourage it.
Something akin to evolution means that the ones who don't fit that profile work somewhere else. Big companies don't like noise. They like conformers.
Katie
Friday, January 9, 2004
I'd say that some level of probing into their technical background is necessary. Just asking about their past two projects isn't enough to let you know whether they'd make a good hire.
I've had candidates that have come in telling me about their projects and that they have been OOP programmers coding in Java for 7 years. They tell me all about their projects, etc. It all sounds good, interesting projects that they had an interesting part in.
So I decide to poke a little bit. 7 years of doing OOP and their past two projects have both used it heavily.
So I ask them to explain to me what the word Polymorphism means to them. They say that they aren't really familliar with the word. Fair enough. I explain to them what polymorphism is, and ask them if they've ever used these concepts in programming. I get a blank stare followed by a response, maybe, I think I might have.
Okay, so maybe in 7 years of programming OOP they've never stumbled across Polymorphism. So I'll bake up a step. I ask them to explain to me the concept of Inheritance. This should be an easy one. I usually get responses describing function overloading. Close, but no cigar.
So, benefit of the doubt again, they've been programming in C for the 17 years of their life before doing OOP programming. 17 years is a long time, so I figure a simple function to reverse each word in a string should be easy. Well they don't remember C syntax. I'm not looking for that so I explain they can just use psedo-code to explain the steps they would take to solve the problem.
A good candidate in this case (at least one having 17 years experience in functional programming) should easily see that this is a two dimensional program, thus two loops are going to be needed. If they are exceptional, they'll do it in one pass, but I'd just like to see that they know where to start with the problem.
Absolutely no clue. They talked it up about all the projects they've done, and it sounded real good. With a bit of probing and prodding though, it all collapses.
When you're interviewing some one to be your sales manager, talk is what counts. When you're interviewing someone that is supposed to be the technical lead for a project, they need to have the knowledge so that junior programmers can go to them for help and direction. Make sure that the knowledge is there to be given, or you're not only serving an injustice to that one position, but to all of the positions and that depend on it/them.
Elephant
Friday, January 9, 2004
And I agree with the point I think you're making, Elephant, that it comes out of the conversation, not so much a quiz as a discussion that probes.
Simon Lucy
Friday, January 9, 2004
If you're going to ask them for actual code, I like te idea of having an actual computer there instead of having them write code down on paper, like some interviewers apparently do.
Proud owner of several Model-M keyboards
Friday, January 9, 2004
If you're going to get someone to write code in an interview, please have the courtesy to leave the room and let them work in peace while they do it. Or at the least, do something else rather than hover over the interviewee.
I'm sure I'm not the only one who finds it hard to work when it feels like there's someone looking over my shoulder.
Unless of course you do pair programming where you work. In that case, may god help your soul. ;)
Sum Dum Gai
Friday, January 9, 2004
That's something that to be honest never occurred to me. I've never had any problem with someone watching me code. I learned to program that way, so I guess it doesn't bother me. The only problem I have (when coding on a computer) is I feel I can never type quite fast enough.
I think I'll present them with the option of being left alone to code, or keeping me around to point them in the right direction if they get stuck.
I perfer to watch them code, because of the issue that this discussion has raised (yet again on JOS) that it's more of a discussion than the ability to code on the spot with tremendous pressure that counts (although I advocate that being able to do so does speak volumes, but the contrary has no direct correlation).
Elephant
Friday, January 9, 2004
i just got a new job as a PHP developer. start next week.
anyway, in the first interview i had to "code in conversation". "how would you do this?...what does this mean to you?"...etc.
in the second interview, they gave me a fairly simple take-home project. they said there was no rush, don't kill myself....but i spent a fair bit of time on it. i suppose i could have faked it, had someone else do it, copied it, etc... but that stuff could probably be spotted pretty easily.
what's interesting is i hosted the app on my own server, and the company actually used it. what if i didn't get the job?! i shoulda charged them for usage.
josheli
Friday, January 9, 2004
--
so I figure a simple function to reverse each word in a string should be easy
--
I like that question. No 'ah-ha!' parts to it, but complex enough that you need to think about it for a second before diving in. I just coded it up here all the while thinking 'what would I think if I were an interviewer watching this'.
I might have to use that if I ever interview people. Of course I'd make sure they have a computer, since I had 2 minor bugs in my implementation that were immediately obvious once I ran it.
Andrew Hurst
Friday, January 9, 2004
Like I said, I'm more concerned about aproach to the problem, not that they code up a bug free solution either on a computer or on paper, although extra points are given if you do -- just no penalties for not.
The second half of the question is to write another function that reverses the words in a string, and the final part is to write a function that does both.
i.e.
String: This is the string.
Part1: sihT si eht .gnirts
Part2: string. the is This
Part3: .gnirts eht si sihT
Nested loops is easiest for parts 1 and 2, although single pass O(n) solutions are not much more difficult. Part 3 is Part's 1 and 2 called in either order, although, the most efficent solution is to just reverse the entire string. That's the only aha part of it that I know of. . .
Elephant
Friday, January 9, 2004
Elephant's example is a good one, particularly if you're looking for general programming skills -- understanding algorithms, breaking problems down into parts, etc.
When I ask questions like that I try to also include some non-technical aspect as well. I often ask questions about date manipulation, because dates are something that everyone thinks they understand, but require very careful attention to detail to get right. "Is this code correct? What does it do on the first day of British Summer Time? In South America?" etc, etc.
To answer the more specific question -- what do you ask ASP.NET developers? -- something I like to do is put a bunch of broken server-side code on my whiteboard. Maybe ten lines of code which works in the sense that it gets the job done, but with bad error handling, no localization, a few security holes, some potentially bad performance, etc. Can the candidate find the flaws? Can they fix them?
Remember, many devs DO NOT spend most of their time writing new code! They spend most of their time maintaining existing code -- so test that skill.
Eric Lippert
Friday, January 9, 2004
Interesting, I think the natural way to think about Part II is actually Part I composed with Part III (especially if you are trying to do them in-place.)
MugsGame
Friday, January 9, 2004
Ok, here's the problem in using the 'here's a bunch of code that almost works but doesn't have all this other junk that would make it really nice'; you're setting the candidate up to fail.
They may get a great many of them, they may only get a few, they may think that on the whole its ok. Because its not a system its a bunch of lines on a whiteboard. You see the test as one thing, the candidate sees it as something else.
Now as for the reversing strings and words question if a candidate wrote out something like...
For all input
write_output(reverse(getword))
endfor
I'd probably be pretty happy with that, but is that what you expect? You might ask, "so how do you reverse a word"? And you might get a stony glance as the candidate laboriously pointed out the number of ways you can reverse an arbitrary number of characters and he wonders why you want first semester algorithms.
Or do you want to put someone through the grief of writing code to a clock?
If you use these kinds of questions then you have to ask all the candidates for the same job the same thing. At the end of the process you have to ask yourself 'did this help me in making the decision'? Apart from a few cases, and in those cases I'd probably argue that the first few minutes already told you they couldn't cope with it, 'passing' this kind of questions gave you really no information in differentiating candidates that could do the job.
Simon Lucy
Friday, January 9, 2004
Maybe it didn't help me in differentiating between candidates that could do the task, but it does help me in removing candidates that are unfamiliar with first semester algorithms, which is more than you might think. I just revert to my previous example. And if a candidated did present me with your code snipet with for each find_word in string example, I'd be happy. They were able to break down a very simple problem. It's the type of thing that should take 5 minutes, but for unacceptable candidates monopolizes the entire interview. For the successful candidate, I would then spend the rest of the interview getting to know the candidate, what their development philosophys are, good types of JOS discussions. If they illustrate basic programming skills, and can talk intelligently about programming topics, and they've got the necessary skills to boot, hire.
switching gears. . .
I would agree in regards to your comments on cleaning code. That's definately a setup to fail. On the other hand, if there was code that didn't work (bugged), and you explained the correct behavior, I think that could show whether or not they have basic debugging skills.
I think all this is way off topic from the original post though. . . We should move this elsewhere if it's necessary.
Elephant
Friday, January 9, 2004
Just to clarify, I certainly don't expect any candidate to find every flaw in a piece of code, and I certainly would not "no hire" someone because they didn't spout off the list of flaws I have in my head.
What I'm looking for are the _thought patterns_ that the candidate uses to try and find flaws. I'm looking for their ability to come up with solutions to existing problems. And I'm looking for their ability to take an ambiguous situation and clarify it.
I've had multiple candidates who, looking at a piece of server code (written in C), say "Hey, this code casts a pointer to a 32 bit integer. But that always works because _all_ web servers _always_ use 32 bit operating systems. Obviously that isn't one of the problems you're asking me about." And then they kind of pat themselves on the back for being clever. No joke!
I've also had candidates who say "hey, this code casts a pointer to a 32 bit integer. At a minimum, we must put a compile-time check into this code so that the recompilation will fail on a 64 bit server. But that's pretty weak. We probably want to maintain both the uniqueness and the 32-bit-ness of that integer, so let's build a hash table that maps arbitrary pointers to integers. You haven't told me how many of these pointer-integer pairs are going to be "live" at once, so I'll need to know some more information before I design that hash table..."
I really don't care whether the candidate can come up with all the flaws or not. I care about whether they can read code, understand it, figure out what some of the problems are, clarify those problems, come up with a variety of solutions, and give me some idea of the developer costs and user impacts of the various options. That's what new devs do all day around here, so they'd better be good at it!
Eric Lippert
Friday, January 9, 2004
> if a candidate wrote out something like...
> For all input
> write_output(reverse(getword))
> is that what you expect?
If the candidate went on to actually implement those things when I asked them to then I'd be thrilled. (And any candidate who is grumpy about being asked to write "easy" code obviously hasn't interviewed many people themselves!)
You might be surprised at the number of people who have "fluent in C" on their resume who nevertheless get deeply confused by the relationships between the * . -> [] operators when it actually comes time to walk a string.
I'm flashing back to one of my interviews (which I suspect was a "no hire"...) all those years ago. The task was "reverse a linked list, in C++". Being that this was C++, not C, I assumed that we had a linked list stack ADT and wrote
while(!oldList.empty()) newList.push(oldList.pop());
The interviewer was NOT happy with that. Not a single box with arrows, not a single pointer. But if he'd wanted a C solution, he should have asked for one. Sometimes interviewers get really inflexible, particularly interviewers who rely on old chestnuts.
Eric Lippert
Friday, January 9, 2004
josheli, JOS has threads in the past regarding this issue of employers literally using the interview process to get code coded for free... I don't have any professional opinions to add to this topic, but if you do a search, you might find some.
Li-fan Chen
Saturday, January 10, 2004
Thanks for the input guys. I just had the first interview. I gave them a printout of some simple sample code that accessed the database and displayed it on a page, gave them some time to read through the code and understand what was happening.
We then discussed the code and talked about any changes they would have made, different ways it could have been coded etc. I found it very useful in finding out their knowledge of the code and the concepts behind it.
Ben R
Sunday, January 11, 2004
I can remember a rather humiliating botch I made once when applying for an ASP position - at a time when I'd just delivered an ASP application at another job that I was particularly proud of (still am, really), and was thus at a high point in confidence:
The interview was going well, and in a very friendly manner, I was asked to debug a handful of very basic code - looping through a record set, playing with it a little, easy stuff. Yet, for the life of me, I could not fathom what the hell was wrong with it. I examined each line in meticulous detail, desperately trying to figure out what was clearly an incredibly obscure error - I tried some answers relating to performance etc, and while my observations were correct, they were really quite trivial, and obviously not what was wanted. Finally, I simply had to concede defeat.
At which point the interviewer revealed the code scrap was missing a recordset.movenext at the end of the loop. D'oh! While this was a consequence of me spending the previous two years religiously casting my recordsets into arrays and then disposing of them, it showed me up as not remembering the very basics. Not good.
So some advice for anyone *taking* such interviews - brush up on the real basics, just in case you've internalised your own habits and optimisations to the point that you've forgotten something anyone in first-semester web programming knows by heart ;)
(of course, I didn't get the job. I doubt it was solely because of that little slip - but I'm sure it didn't help).
Mediocre ASP Monkey
Tuesday, January 13, 2004
Bull Shit
David
Saturday, January 17, 2004
 Recent Topics
Fog Creek Home
|
