So… You think you’re a web dev?

I've been spending the past couple of months trying very hard to hire some temporary (i.e.; contract) web development resources - it's been difficult and eye-opening. There is a huge disconnect between what a resume says and what a candidate is really capable of.

Now, I knew from the start not to place too much trust in resumes, so I begin all candidates with an email based screening process; just a few simple questions that they need to complete and send back. If they do well there, they can get a live interview (and sometimes "live" equates to a LiveMeeting session).

Either way, apparently 80% of candidates are experts in ASP.NET application development, and yet somehow cannot:

  • Write code to call a stored procedure and populate a dataset (and I'm not picky about syntax).

  • Come up with a simple search UI that can search on multiple fields.

I don’t yet have an explanation of how this happens. If you do, please share 🙂

Interestingly, even using very simple questions one can usually get a quick gut feel for the overall ability of a candidate. This was demonstrated by an interview I did recently, where in 20 minutes the candidate completed what takes the average candidate 60 minutes. Needless to say, that guy got an offer immediately.

Now, the interesting part... I will soon have an open permanent position to fill. I dread going through this process again - and to make it more difficult, I won't have the immense help of multiple vendor companies sourcing resumes for me. I'm going to have to find them myself.

So... You think you're a web dev? Seriously - not just on paper? Want to work at Microsoft?
Mail me: Avi.Pilosof at


P.S: The resume writing process should not be an exercise in listing every technology you've ever read about. Maybe a post on writing resumes is in order?

Comments (13)
  1. Rich says:

    Out of curiosity, under what conditions do you ask people to do these tests?  When I conducted tests, I always gave them a workstation with MS Studio on it and asked them to complete several tasks.

    I personally depend on intellisense to help me remember what order parameters go in, since I switch back and forth between so many languages.  That being said, I do know what objects need to be created and what needs to be done to do those tasks.

  2. MSDN Archive says:

    Good question, Rich.

    This is always a whiteboard exercise – and every single person has cursed intellisense during this 🙂

    But I don’t care about order parameters, or syntax specifics. I do care that you know what a SqlCommand is, and that you’d need to use a DataAdapter (for example).

    The truth is that most devs don’t do this on a regular basis, because they wrap their DB calls in a library (and they should). But a great dev should know the basics, if not the specifics.

    I have been considering giving the candidate a workstation, but the truth is that the good candidates don’t need it. Something to consider, though…

  3. Steve Perry says:

    I agree, I’ve found that I can’t hire "web" developer, I have to hire or C# developer that knows a little HTML. Most web developer are actually web designer, a lot of them know graphics and layout really well, but ask them to connect to a database……

  4. jeffyjones says:

    I rely on Intellisense too. I don’t think that makes me a poor coder, it just means I don’t burden my head with things the machine can do for me.

    I got asked about datasets in my last interview, but had to explain why I haven’t used them in four years. I still got an offer. The key thing is really that you have to test for functional knowledge, not dictionary knowledge. I can look up any class in the framework and use it, but don’t expect me to know them all.

  5. MSDN Archive says:

    Jeff, you’re right – not knowing argument orders and specific syntax doesn’t make you a bad coder. And I make it clear in the interview that I’m not too worried about that.

    But take for example the act of populating a dropdown list using databinding. I expect you to know how to set the datasource, bind the datasource, and at least realize that you need to define the textual member and the value member. Whether you remember the exact properties for that, I don’t care.


  6. Kevin says:

    I’d be wary of a programmer who KNEW how to create a connection, fill the paramters of a sqlcommand, and populate a dropdown and do all that repetitive legwork from memory.  If they can remember how to do this then they probably arent used to working with advanced toolkits.  Heck, its been 3 years or so since I opened a connection manually.  For me to fill a dropdown it looks like

    FillCombo(cboComboNamo, SP_NAME, Parameters(), SelectedValue)

    or better yet

    FillCombo(AppObject.ChildrenObjects, mSelectedChild)

    FillCombo and its equivalents do all that underlying work of opening connections, reading configuration information, trapping errors, opening a sqlcommand, setting the parameters, executing it, reading the results, clearing the combo items and adding the new items and setting the selectedIndex on matching ones, etc.

    If you’ve got a candidate that remembers how to do all that then they’ve probably been writing poor, unmodularized code.  

    Now, if you let them cut/paste from a past project… then that’s cool–they have a toolkit.

    The way I see it when I do my hiring, you’re not just hiring a carpenter who knows how to cut wood–you want to hire a carpenter who has a nice set of tools too…

  7. Pavan says:

    I agree with Kevin.

    Automation solutions that we build these days are actually quite complex. The only way these complex solutions can be built and maintained is by “breaking them down to smaller maintainable units”.

    A lot of times, when we are involved in building something of a larger scale, we plan and architect the solution into these so called units. Teams/developers then build up the units.

    A good architecture actually obviates the need for individual contributors to remember repetitive or mundane tasks. They should be able to devote time to coming up with creative solutions to those problems that are yet to be solved. That’s kinda what Microsoft’s development tools aim to do right?

    My family thinks I am computer geek. That’s because, whenever they have a “how to” question with a computer related task. I can spend a little time researching it and I am able to come through with a useful solution. The truth is I don’t have a database of questions and answers, nor do I use MS Excel or Word for a living. The skill involved here is the ability to analyze the problem, break it down, relate it to a problem that I have solved previously, know the right keywords to do an internet search and then the ability to implement that solution. This probably is the basic skill set of a good software engineer. And well, Microsoft’s products’ ease-of-use helps too! Yes. That is why, I so want to be a part of teams that actually produce these products.

    So, one of us might not quite remember how to call a JavaScript confirm on a submit button. Having not used it in over a year, that’s quite possible. But, if there is a requirement to actually implement that, most developers can complete it in a matter of minutes!

    The thing is that possibility did result in me missing out on an opportunity to be a part of a good team… For now, I can just hope to put a better foot forward if and when there is a next time.

  8. MSDN Archive says:

    As I said in the comments; it’s not about getting things exactly correct, because all good devs should be using libraries to do this kind of stuff.

    But to address Kevin’s comment specifically, are you telling me that given a dataset, you won’t remember how to bind a DropDownList to it, and at least know the concept of a "display/text member" and a "value member"?

    The truth is that when you watch someone try code *anything*, you get a very strong sense of their skills, and sometimes you can tell they are good even when they don’t get the exact right answer. They will describe the concept perfectly, mention that they forgot the exact syntax, and explain that they use libraries. No problem; they always shine in other areas.

    The candidate at the other end of the spectrum tries to stumble through various solutions, gives answers that aren’t even close to being syntactically correct, and then misses major concepts even when questioned about them (such as the text vs. value concept in a dropdown).

    And the candidate that falls in the middle… Those are by far the most difficult, because you *can’t* completely judge a dev based on such a short interview. But then you don’t have the luxury of a 5-hour interview loop for screening people.

    Overall, I’m sure that sooner or later I’m going to miss a gem, but consider the mitigating and limiting factors:

    1) Given 50-100 resumes and very little time, how do you screen them effectively? Every criteria is going to skew in some direction.

    2) Given two candidates, equal on all other criteria, one of who can code this up, and the other who shows no memory of it; what do you go with?


  9. Pavan says:

    Candidate Selection suggestions


    Short list last number of recieved resumes

    Timed Screening question via email:

    Eliminate all who donot complete in time

    First phone call: (30 min)

    Find out backgorund

    Ask conceptual questions, like OOP, algorithm analysis, RDBMS

    Eliminate candidates without strong fundamentals

    Call previous bosses

    The key here is, ask the candidate for references on specific projects that are relavent to the position.

    Talk to the reference and ask about performance and contribution in specific projects.

    The really good candidates leave behind siginificant contributions and good impressions.

    Eliminate those without good reviews here


    Give candidate a complete project to solve. Possibly from on-going work in the team. Let them come back after a day or two, with complete solution, including db installation, code etc.

    Live Meeting:

    Grill candidate on choices made in the project

    Ask candidate any other questions

    .. just trying to add 2 cents


    I am not an expert on hiring people; (yet)


  10. MSDN Archive says:

    Good stuff Pavan, let me try to respond to each item individually. But first, let me say that the methods you decribe have lots of merit – I’m just not sure they are suitable in my scenario because I’m hiring for a *contract position* and have to go through a huge number of people.

    > Short list last number of recieved resumes

    How do you make a short-list if you can’t trust the information in the resumes (experience shows you can’t)? How do I go from 50 people who claim to have 5 solid years of ASP.NET, to 5?

    > First phone call: (30 min)

    At this point, I’ve already used up about as much time as I want to on a candidate that doesn’t already hold some promise. Remember this is for a contract position, where I can’t afford to spend hours, as I do on a permanent position.

    > Ask conceptual questions, like OOP, algorithm analysis, RDBMS

    Do these reveal more about a good web programmer than a quick coding question?

    (Not saying they don’t – just saying you should consider it ;))

    > Call previous bosses

    This works really well if they’ve previously worked within MS. This is the first thing I do if that’s the case, because it takes about 1 minute. But externally, it’s a whole different thing:

    * It’s going to take time to get contact details.

    * Why should I trust the boss’s competence? Was he hired with my standards?

    * How do I know the boss is not a good friend of the candiidate?

    > Project: Give candidate a complete project to solve

    I would LOVE to do this, but it has some issues:

    * Time, as mentioned above. Imagine doing this for 50 candidates – Who will coordinate all this? (just reviewing their code can be a nightmare).

    * Trust: Are they relying on a friend to help, did they find some great online samples?

    * Time limit: I’ve found that a given project can be done in 2 weeks by a decent dev, and 3 days by a great one. What time limit do I set? Can I afford to wait that long?

    … So, many of your suggestions are perfectly good, but require a HUGE time investment. I would imagine that a full time recruiter would be required to handle every two open positions. And that recruiter would need to have a high level of programming expertise in order to analyze the answers. With the number of open positions that MS has at any time, we’d need thousands of recruiters, most of whom would need deep programming knowledge. If I could find those people, I’d hire them as coders 🙂

    As I mentioned above, this whole conversation applies to hiring someone who is expected to come in for a temporary contract, get the job done, and move on to another contract. It doesn’t apply to full time employee positions, which require a very different process, and take alot more effort.

    What do you think?


  11. MSDN Archive says:

    Oh, another thing I wanted to mention: You guys are making me think, and perhaps I’ll change one thing at least:

    I’ll start with the same style of question (eg; fill a dataset), but if the candidate suggests that it’s been a while since they wrote that code, I’ll ask them to do it using the libraries they’re used to, rather than the low level .NET ones.

    I actually tried this once, and the candidate didn’t do too well there either; but I think it’s worth a shot – if nothing else than to get a little more insight.



  12. Memmorium says:

         Good idea!

    P.S. A U realy girl?

Comments are closed.

Skip to main content