Simple Form Sample for Interview?

Question

Help me out, please...

After a 9 month dry spell, I've finally gotten an interview for a C# Win forms position. Better yet, the job actually sounds exciting -- as opposed to, "I'll take anything to have a job again."

Now, the recruiter sent someone over before me. During that candidate's interview, the questioner asked him to create a blank Win form that switches between two background colors every 5 seconds. The first, "highly qualified" candidate, either couldn't, or wouldn't do it! Having learned about the problem, I've gone ahead and practiced that particular app, a few times. But, if it were me doing the interviewing, I sure as heck wouldn't present the same problem. So, my question: anybody have suggestions for similar mini-projects, of approximately same complexity, that I could build as practice?

I'm not asking for code, I just want the suggestion, in the same way you might ask me if you were interviewing me. I realize, of course, that the interviewer most likely will come up with something else, but I figure the more practice I get just whipping out little things like this, the better prepared I'll be to deal with whatever he throws at me.

OTOH, if you think I'm barking up the wrong tree, let me know.

Thanks!

Randy

Answer 1

Well, it's not really much of an answer, but "you either know it or you don't".

If you know it; demonstrate it.

If you don't; then don't pretend to sound like you know how to do it. You'll get caught very quickly. Be up front; and demonstrate how you would figure out how to solve it.

Nobody knows everything. The programmers that can figure stuff out with appropriate resources are the valuable ones.

Answer 2

A nice one from the MCTS certification:

1. Create a form which has a button.
2. Set the button caption to "Click Me".
3. Display the number of times the button has been clicked in the top left corner of the button by overriding its OnPaint method.

Answer 3

I agree with Jim B.

A confident candidate for a position that states I'm not specifically familiar with, but know how to research and resolve is WHY I should be considered. Too many people out there can talk, but only work by examples and don't have enough to thing for themselves on problem solving.

Answer 4

I'm a firm disbeliever of interview tests. I prefer to set a trial period for the candidate so that I can really see him working on the environment. If you can, always set that trial, too many candidates can fool you into thinking they're so great they can get the project done by themselves only to find they are not worth it.

I'd recommend to the Guerrilla Guide to interviewing by Joel Spolsky. For me is kind of a bible to interviewing (although I'm a little more relaxed than him when it comes to discarting a candidate)

The fact is... you should hire someone who will get the job done, if possible whatever job you get him.

With that said, don't forget to be pragmatic. An expert in Lisp would always be better for your Lisp project than a great "GetJobDoner" with no experience whatsoever in Lisp. Don't forget what you're hiring for, enthusiasm cannot replace experience when the schedule is short.

I used to disregard concrete "field questions" and look only for a guy which can learn whatever in a short period of time, and that's still what I do but I spent enough time in the interview process to look for both and if I don't have the time I go for solve my problem now, get the rest later.

Answer 5

I wonder if the concern of causing epliptic seizures was part of the answer that wasn't given that the interviewer was expecting. So that while the question may seem like a rather trivial thing to code, the fact that such a concern wasn't voiced is what killed the candidate's chances of getting the position.

I'd wonder what other similar minor changes could one make to a blank form that should cause similar questions in terms of why one wouldn't code something.