How much can you infer about the programmers at a company based on the test/interview?

Question

I did an interview which was preceded by a test. The test was written with approximately 20 questions. A significant number of questions in the test were poor in that some of them had no correct answer, others asked things that couldn't be answered, and some were just pointless.

For example, one question asked how to post an aspx page to another aspx page, with three options, all being modifications of the form tag. To the best of my knowledge this can't be done. There was no 'None of the above' style answer either. Another question asked how to de-reference an object in C#. None of the answers mentioned unmanaged code.

Anyway, the point is, in the follow up interview I asked about the test citing the poor questions and was told that it was deliberate in order to weed out people who study for a test but don't really know the language.

Should I buy this?

Answer 1

Well, you can post from one ASPX page to another ASPX page by setting the "action" attribute of the form tag to the aspx page you want to post it to. I think in this and other cases, you may have been mistaken, and the question was actually valid.

It's hard for those that are hiring to make up test that are both hard enough so that they adequately test the skill of the programmer, and don't let bad programmers slip through, and also write tests that don't aren't so hard, that nobody could pass.

Answer 2

In situations like this I like to ask if I can come in a spend a couple hours talking to some of the people I would be working with (having lunch with them is good too). This will help you make sure that they are not a WTF shop. Any place that is serious about you will be open to this idea since it means you are really looking for a good fit and not just a pay check.

Answer 3

While that particular situation is something I can't comment on (not knowing C# or ASP), I can definitely state that asking questions that either have no correct answer, or supplying obviously incorrect answer, or are open-ended, is a very valid and useful interviewing tool.

They let the interviewer:

• Observe how the interviewee handles unusual situation under stress (people don't expect not-clear-cut questions) and their creativity.

• Observe whether the interviewee is sure of his knowledge (e.g. able to and not afraid call them on their BS answer) and on how he communicates in adversarial situation (e.g. POLITELY call them on their BS answer and explain why it's BS in clear manner).

• Allow them to observe how the interviewee thinks throw the problem, in case of no-clear-answer questions

• Allow good segues into discussions illuminating experience/knowledge that pre-canned Q/As do not.

However, if a vast majority of the questions was as poor as you indicate, it'd be somewhat wary about the technical expertise of the personnel and ask them questions yourself should you get an offer or follow-up interviews.

Answer 4

Sometimes it's management, not the current programmers.

Answer 5

It smells like they didn't quite have their reasoning straight since those are definitely not basic everyday problems.

The question in your example might have been a valid one though... Maybe they were looking for cross-page posting.

It goes a little something like this:

<asp:Button ID="Button1" 
            PostBackUrl="~/TargetPage.aspx"
            runat="server"
            Text="Submit" />

Note the PostBackUrl, which causes the postback to occur on a different page, in this case TargetPage.aspx

More details: http://msdn.microsoft.com/en-us/library/ms178139.aspx

...You could also do something like this by modifying the action attribute of the form tag.

Some people like the philosophy of presenting dev tests that are extremely esoteric and difficult, with the idea that everyone will fail to varying degrees. I do have to wonder if some of the other questions were more impractical than invalid.

My feeling is that folks shouldn't expect programmers to have this kind of knowledge in RAM at all times. I myself knew that cross-page posting existed, but I've never used it so it took a little googling to find the proper name.

I would have missed the question on the test.

Answer 6

When we recruited another programmer, we set them a simple test - in one hour, write a basic telephone directory system to handle at least 20 users allowing searches, updates and deletes. They could use any PHP framework they liked, any javascript library they liked, OOP or functional programming - plus we had no need for a telephone directory, and we didn't actually expect them to finish the task.

However, it filtered out a number of people who said they were PHP programmers, but couldn't even write a simple "display from MySQL database" script (they did have full access to the internet) - only two people completed the test in the time. We had one person use most of the hour to learn a new framework instead of just "getting things done".

The test gave us a good idea who could program and who couldn't, the programming and commenting styles and how they thought of the process (we had follow up questions such as "if this had to be scaled to cover the entire UK, how would you change the program/database" to see how they thought about scalability issues). No necessarily "right" answers, but some "bad" answers came out.

Answer 7

My suggestion is to see if there is some BS to the test. Depending on how the test is administered there may be ways to communicate that, "Excuse me, but I don't think this is correct," kind of sentiment that may be what they are wanting to see. Some managers may be testing to see if would go "out of the box" or "off script" in answering something, though some may see this as deceptive as I'm saying that while there may be four possible answers to choose from there really are other answers and you just have to put that in somehow.

To be more specific about what to ask, the key is to state that some of the questions appear to be trick questions or questions where the person that created the test didn't know about, blah blah blah that makes the question no longer have a correct answer. If you get to talk to a manager or other developer there, just ask the question flat out. Being upfront and honest may give you a surprising result in the end.