Programming challenges leading to a job?

[Romeo Colacitti]

If you live in toronto/kitchener/waterloo/hamilton area of Ontario,
Canada, and you are a good C programmer, take a look at this:

http://www.sentex.net/~mwandel/careers/sample_problem.html

 

[Tom St Denis]

If you live in toronto/kitchener/waterloo/hamilton area of Ontario,
Canada, and you are a good C programmer, take a look at this:

http://www.sentex.net/~mwandel/careers/sample_problem.html

Off topic...

I've actually met Mathias once. My impression was he was very
impressed by the collection of puzzles he has to throw at candidates
but really doesn't have a big picture of things. Like, people maybe be
good at things OTHER THAN solving geometric puzzles.

Good luck if you pursue that course. Best bet is to just apply through
HR though.

Tom

 

[Richard Heathfield]

Romeo Colacitti said:

If you live in toronto/kitchener/waterloo/hamilton area of Ontario,
Canada, and you are a good C programmer, take a look at this:

http://www.sentex.net/~mwandel/careers/sample_problem.html

If you're a good C programmer and you decide to take this job, you should do
so only on the understanding that whoever writes the specs should be fired,
or moved over to the marketing department. They obviously aren't up to the
job of writing specs.

 

[Romeo Colacitti]

Romeo Colacitti said:


If you're a good C programmer and you decide to take this job, you should do
so only on the understanding that whoever writes the specs should be fired,
or moved over to the marketing department. They obviously aren't up to the
job of writing specs.

Hmmm. He even gives an example of what he is expecting, so I don't see
where the confusion "could" come from.

 

[Andrew Poelstra]

Hmmm. He even gives an example of what he is expecting, so I don't see
where the confusion "could" come from.

To be honest, I had no idea what needed to be done until I saw the example,
which suggests that the preamble where he explains it was completely ill-
written and useless.

 

[Walter Roberson]

To be honest, I had no idea what needed to be done until I saw the example,
which suggests that the preamble where he explains it was completely ill-
written and useless.

I understood the question immediately... but on the other hand,
there is one of those punch locks directly across the hall from me.

The question is not an uncommon one; I've seen it before (right down
to the 8 key limit). Probably the code is easily googleable.

 

[Thad Smith]

Hmmm. He even gives an example of what he is expecting, so I don't see
where the confusion "could" come from.

Let's start with the title: "The Combo Button Lock quiz problem".
Is it a quiz or a problem? Normal parsing would be that it is a problem
of "the combo button quiz". That is inaccurate. It could be called a
problem or challenge (not a quiz), but not a quiz problem.

Examples should illustrate and confirm the specification that has
already been made. In several instances, new rules are apparently
defined in the examples:
1. [can't] use a button more than once
2. does not use ANY buttons [isn't allowed]
3. must not push more than two buttons at once

In the following example, two rules-from-examples contradict one another:
1-2 3-4 (any number of buttons together)[are allowed]
and
1-2-3 4 (must not push more than two buttons at once)

The use of the term "combinations" is wrong, mathematically, for
enumerating possible sequences, but is passable in context because of
the colloquial "lock combination" used to mean a sequence of numbers,
not just a mathematical combination.

 

[spibou]

Hmmm. He even gives an example of what he is expecting, so I don't see
where the confusion "could" come from.

In the following example, two rules-from-examples contradict one another:
1-2 3-4 (any number of buttons together)[are allowed]
and
1-2-3 4 (must not push more than two buttons at once)

1-2-3 4 falls under the heading "invalid pairings" while 1-2 3-4
under "valid pairings" so there's no contradiction.

I found that the examples give an adequate description of what the
programme requires. His description may not count as formal
specifications but I doubt that it was meant as such. Many programming
projects start their life as informal ideas of what needs to be
accomplished
accompanied perhaps by a few concrete examples. Starting from such
material and arriving at a complete description is part of the art of
programming. So his challenge is probably meant to test for that as
well.

What I'm not sure about is the stipulation that the number of buttons
can be no more than 8. Does this make the problem easier ? I don't
see how.

Spiros Bousbouras

 

[Walter Roberson]

What I'm not sure about is the stipulation that the number of buttons
can be no more than 8. Does this make the problem easier ? I don't
see how.

Not sure; there are 109600 single-press solutions for 8 buttons,
and 986409 for 9 buttons. However, these solutions can be broken up
into a pair of counters, one recording the number of buttons
at a time and the other one the solution index within that. If one
does that, then for 8 buttons, the maximum solution index for a
fixed number of buttons is 8! which is 40320 which fits within an
unsigned int even on systems with 16 bit int. For 9 buttons, the
maximum solution index for a fixed number of buttons would be 9!
which is 362880 which would require more than 16 unsigned bits.

As the "quiz" has been around for rather some time, I suspect that
this 16 bit arithmetic limit was considered important at the time.

 

[Thad Smith]

Richard Heathfield wrote:
Romeo Colacitti said:

If you live in toronto/kitchener/waterloo/hamilton area of Ontario,
Canada, and you are a good C programmer, take a look at this:

http://www.sentex.net/~mwandel/careers/sample_problem.html

>>>>They obviously aren't up to the job of writing specs.

Hmmm. He even gives an example of what he is expecting, so I don't see
where the confusion "could" come from.

In the following example, two rules-from-examples contradict one another:
1-2 3-4 (any number of buttons together)[are allowed]
and
1-2-3 4 (must not push more than two buttons at once)

1-2-3 4 falls under the heading "invalid pairings" while 1-2 3-4
under "valid pairings" so there's no contradiction.

The contradiction is in the words, not the specific examples. The first
says that any of buttons may be pressed at the same time. The next
entry says that you must not push more than two buttons at the same
time. That is a contradiction.

 

[Robert Latest]

On Mon, 26 Jun 2006 22:13:27 +0000,

If you're a good C programmer and you decide to take this job, you should do
so only on the understanding that whoever writes the specs should be fired,
or moved over to the marketing department. They obviously aren't up to the
job of writing specs.

But look at the wooden marble machines he has built. I like those. And
the 3D ascii art pentomino puzzle solver in C.

robert

 

[spibou]

Romeo Colacitti wrote:
Richard Heathfield wrote:
Romeo Colacitti said:

If you live in toronto/kitchener/waterloo/hamilton area of Ontario,
Canada, and you are a good C programmer, take a look at this:

http://www.sentex.net/~mwandel/careers/sample_problem.html

They obviously aren't up to the job of writing specs.

Hmmm. He even gives an example of what he is expecting, so I don't see
where the confusion "could" come from.

In the following example, two rules-from-examples contradict one another:
1-2 3-4 (any number of buttons together)[are allowed]
and
1-2-3 4 (must not push more than two buttons at once)

1-2-3 4 falls under the heading "invalid pairings" while 1-2 3-4
under "valid pairings" so there's no contradiction.

The contradiction is in the words, not the specific examples. The first
says that any of buttons may be pressed at the same time. The next
entry says that you must not push more than two buttons at the same
time. That is a contradiction.

The first says "any number of buttons together". This doesn't
necessarily
mean at the same time. It could mean in the same combination. So he is
ambiguous but not contradictory. Of course if you also take the
examples
into account the ambiguity disappears.