Looking for practice programming problems

[antoan]

Hi,

I am looking for C# practice/interview programming problems and NOT
general framework explanatory questions.

The ones I've come across I find a wee bit easy. I'd like to find
material that tests not just technicality or knowledge of the language
but also one's problem solving abilities, though not the kind that takes
a day to implement a piece. I'd be grateful to ya'll for any
recommendations on books/link/resources that you might suggest.

Antoan

 

[Greg Young]

A few of the ones I like to use ...

1) Given an integer print out a string of 32 1's and 0's representing its
bits //very easy if you know bitwise oeprators or have a good framework
grasp, shouldn't take more than 1-2 minutes
2) Write some basic code that generates mazes ... make them write code to
solve a maze
3) Make them write code to find the optimum solution to a given maze
4) Give them bad/buggy code and make them philosophically debug it then
refactor it to be better code

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

 

[Peter Morris [Droopy eyes software]]

2) Write some basic code that generates mazes ... make them write code to

solve a maze
3) Make them write code to find the optimum solution to a given maze

I'd walk out of the interview if I saw questions like that

 

[Greg Young]

I personally ask them how they would do it theoretically (and I should add
thats a question for a lower level developer ) not to actually do it.. I
never have them write code in an interview ..

Actually I should add another I ask alot for winforms people .. how would I
may a textbox print its text upside down.

I prefer in general to ask odd questions I know they have never had to do
but are simple if you understand whats going on.

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

 

[Mythran]

Actually I should add another I ask alot for winforms people .. how would

I may a textbox print its text upside down.

I'd turn the monitor upside down and prove that the text is, in fact, upside
down inside the textbox (which is also upside down)

Mythran

 

[Mark Wilden]

I'd walk out of the interview if I saw questions like that

Me too.

///ark

 

[Saad Rehmani]

I'd walk out of the interview if I saw questions like that

I'd stick around and flunk it

 

[antoan]

I'd turn the monitor upside down and prove that the text is, in fact,
upside down inside the textbox (which is also upside down)

Mythran

In this case it might be actually easier to implement an 'Alan Turing
test' self consciousness AI solution to simply visually look at it and
say weather the text box is really upside down without resourting to
neural networks pattern recognition : )

No, but really,

"I prefer in general to ask odd questions I know they have never had to
do but are simple if you understand whats going on."

as Greg mentions is the kind of stuff I'm looking for.


P.S Asking them to philosophically debug code, Greg? I find that beyond
hilarious : ) Can almost hear them saying: " U want me debug this method
my self? Define self!!" : )

Cheers,

Antoan

 

[antoan]

I'd walk out of the interview if I saw questions like that

No, just ask for a beer instead of another coffee and then walk out : )

 

[Saad Rehmani]

I personally ask them how they would do it theoretically (and I should
add thats a question for a lower level developer ) not to actually
do it.. I never have them write code in an interview ..

You might want to check out http://blogs.msdn.com/ironarchitect/archive/2006/05/01/586219.aspx
for those pesky abstract level developers

 

[Barry Kelly]

I'd walk out of the interview if I saw questions like that

Those are not difficult questions - relatively easy with a little
recursion, and they're the typical questions you'd see in a programming
contest. However, these two together would take an hour or so to write
and debug (probably longer if one had to read and write the mazes /
solutions to a particular data format), preferably in private and on a
computer with one's preferred setup available.

Talking through them, I don't think that's unreasonable. But it's still
basically a test of knowing when and how to apply recursion, and not
really a test of code reasoning.

I would prefer a coding sample that was actually simpler, but admitted
several approaches, each with varying tradeoffs. One could then discuss
the tradeoffs, and the varying approaches, starting from a high level,
and working down to a lower level, and considering each possibility with
its tradeoffs. In these cases, the simpler the problem the better,
because it takes less time to explain, but that are open-ended,
admitting more creativity.

An odd thing about (and IMHO one of the bigger problems with) the maze
problems above is that correct solutions are almost guaranteed to have a
certain algorithmic complexity (linear in the maze area assuming a
classical "children's pen & paper maze" fitted on a grid inside a
rectangle, for both problems).

-- Barry

 

[Kevin Spencer]

Perhaps you should look at your dilemma as a problem and solve it. After
all, you do want your students to do the same, do you not? Taken abstractly,
any task one is charged with, for which the methodology is not provided, can
be seen as and accomplished by seeing it as a problem to be solved. The same
problem-solving principles are applied, whether the task is one of writing
software, or, for example, teaching others how to write software. The
requirements are identified. The environmental conditions are analyzed.
Several different pathways to achieve the requirements are proposed. Each
pathway is critically analyzed and compared qualitatively with other
alternatives. The best possible pathway is decided upon, and executed.

Of course, your advice-seeking is a valid and useful aspect of the
analytical part of the problem-solving process, and I commend you for it.
This is merely my contribution to the thought pool.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

A lifetime is made up of
Lots of short moments.

 

[antoan]

Perhaps you should look at your dilemma as a problem and solve it. After
all, you do want your students to do the same, do you not? Taken abstractly,
any task one is charged with, for which the methodology is not provided, can
be seen as and accomplished by seeing it as a problem to be solved. The same
problem-solving principles are applied, whether the task is one of writing
software, or, for example, teaching others how to write software. The
requirements are identified. The environmental conditions are analyzed.
Several different pathways to achieve the requirements are proposed. Each
pathway is critically analyzed and compared qualitatively with other
alternatives. The best possible pathway is decided upon, and executed.

Of course, your advice-seeking is a valid and useful aspect of the
analytical part of the problem-solving process, and I commend you for it.
This is merely my contribution to the thought pool.

Kevin, I appreciate the thought,

however I am the student, the problems are for my self to practice with.

Antoan