Weekender #2
ERRATA: JKK has been changed to CKK. Sorry for the typo.
I will try to continue these until there are two consecutive weekenders that nobody attempted.
As some of you might recall (all three of you I mean), I was planning on a word puzzle. I wrote it down on a piece of paper when we were waiting for food in an Ethiopian restaurant (we waited 50 min but the food was great.) Anyway, I lost that paper. I will try to find it tonight and maybe add to this, so watch this space for updates.
Two questions this week:
1. Find the word(s) that contain these sticky three-letter sequences.
The conditions:
a. These should not begin or end the word.
b. These must be together(sticky).
c. No plurals.
e.g. If the Sequence is T-R-E, You cannot answer TREe or CenTRE(rule a)
and sTRipEd is not a solution either (rule b). A good answer here would be sTREet.
Ofcourse, most sequences will have more than one solution, so have fun.
KET
ENC
OWA
RST
KEN
EGI
RGA
LCR
ERJ
CKK
2. This is a real world problem.. not a problem but something that we realized the other day when we were walking in downtown. The convention center next to our office has an elevator that moves between its two floors.
Along with the usual emergency buttons, it has buttons like "Floor 1", "Floor 1.5", "door close" and "door open". If we consider *just the current way* it is being used(no future expansion etc.), how can we make it more efficient? Should we rename the buttons? Can we get rid of any button/functionality and/or replace it with something else?
I will try to continue these until there are two consecutive weekenders that nobody attempted.
As some of you might recall (all three of you I mean), I was planning on a word puzzle. I wrote it down on a piece of paper when we were waiting for food in an Ethiopian restaurant (we waited 50 min but the food was great.) Anyway, I lost that paper. I will try to find it tonight and maybe add to this, so watch this space for updates.
Two questions this week:
1. Find the word(s) that contain these sticky three-letter sequences.
The conditions:
a. These should not begin or end the word.
b. These must be together(sticky).
c. No plurals.
e.g. If the Sequence is T-R-E, You cannot answer TREe or CenTRE(rule a)
and sTRipEd is not a solution either (rule b). A good answer here would be sTREet.
Ofcourse, most sequences will have more than one solution, so have fun.
KET
ENC
OWA
RST
KEN
EGI
RGA
LCR
ERJ
CKK
2. This is a real world problem.. not a problem but something that we realized the other day when we were walking in downtown. The convention center next to our office has an elevator that moves between its two floors.
Along with the usual emergency buttons, it has buttons like "Floor 1", "Floor 1.5", "door close" and "door open". If we consider *just the current way* it is being used(no future expansion etc.), how can we make it more efficient? Should we rename the buttons? Can we get rid of any button/functionality and/or replace it with something else?
posted by Nikhil at 1:39 AM
18 Comments:
KET - diskette
ENC - pencil
OWA - throwaway
RST - barstool
KEN - tokenism
EGI - collegian
RGA - organic
LCR - velcro, fulcrum
ERJ - perjury
CKK - jackknife
Q1.
Only posting the different ones from what heku posted.
KET - rickety
ENC - clench, trench, stench
OWA - coward
RST - thirsty
KEN - thickened
EGI - register
RGA - organ
Ob question: what are the smallest words (not necessarily unique) that contain these three-letter sequences? It obviously has at least 5 letters. From the above solutions, only "lcr" and "rga" have optimal solutions.
Q2.
I am not sure if I understood the question correctly...but here is what I think.
The three buttons: Floor 1, Floor 1.5, and Door close, can be replaced by a single button that implies "Close the door and go to the other floor".
an optimal solution (according to nemo's definition) for ENC would be "hence".
For EGI it would be "aegis".
actually, I counted the letters in velcro wrongly...so I have no idea whether it is optimal for "lcr".
ket - sketch
(smaller than the ones heku and nemo gave)
Q2: 2 buttons are needed. One to say "Receive Person" type of thing - this replaces "Door Open" (need to keep that door open for all those boxes!). The other button is "Deliver Person" type of thing, which combines "Close Door" & the action of moving to the other floor, and "Door Open"
Nice to see some new words in the posted solutions. I will post the words that I had thought of once the solutions die down. Shortest possible word is an interesting idea.
About the other problem, we have an excellent start by Nemo and Axe.
That is precisely how our original discussion progressed. We started with:
1. Do we need two buttons for floors? We can just have one that says "move".
2. We can combine the "Move" button with "Door Close".
3. So we used just one button as there were only two states and then combined it with another button in #2.
4. Even in a normal elevator, why do we have two buttons for door "open" and "close". We have only two states here too. We can also have just one button that means "Change the state of the door".
So we can have just one button that works like this.
4.1. If the door is closing, it opens the door for that person who is running towards the elevator to save 45 seconds.
4.2. If the door is open, it closes it and moves the elevator.
4.3 and yes, the elevator reaches the other floor, opens the door and keeps it open until someone enters and presses the door or someone calls it to the other floor. This reduces one possible extra door opening and closing.
Enter motion-sensors and timers and you can get rid of this button too.
Any possible problems with the solution in #4? The discussion is still open.
4.2.5 If the door is closed and/or the elevator is moving, the button has no functionality.
4. Even in a normal elevator, why do we have two buttons for door "open" and "close". We have only two states here too. We can also have just one button that means "Change the state of the door".
usability is an issue: this solution feels complicated...primarily because the same button means two exactly opposite things depending on the context. Further, accidental double-presses of the same button will result in a no-op...this can confuse many people. Also, practically speaking, is there a real issue here? Who will benefit by reducing the number of buttons in the lift?
usability is an issue: this solution feels complicated...
But is consistent with the desired line of thoughts..reducing the number of buttons. We are not worried about the usability as we know even making a "DoorClose and Move" button might not be considered in a real world.
Also, practically speaking, is there a real issue here? Who will benefit by reducing the number of buttons in the lift?
This problem is not given by the City Council or anything. It is just a puzzle type question that happens to have its origins in our Convention center. Have you come across a chip that had less Programmable IO pins than you would have liked to have? That is what made us think about it. We tend to think on those lines a lot of times. The question was to reduce the number of buttons and that is exactly #4 offers. We are not bothered about usability, we are programmers, we are offering a solution for reducing the buttons. :)
Microsoft used to ask logic questions like this one in their interviews. If they ask you how to drill a square hole, please don't answer that it is not an issue as nobody would want to drill a square hole. :)
Logically, it is a fine question. But as a programmer, you do need to worry about the usability of your program: otherwise, it is not too different from a pile of rubbish.
Reducing the buttons might be fine as a theoretical problem. (But, probably any optimization should keep overall benefit in mind.) My point was that it is similar to bringing the memory usage of a program from 80 bytes to 20 bytes...in most cases, that will be a pointless exercise.
As for questions in interviews in {evil_company_whose_name_shall_not_be_uttered}, I am not very surprised that they ask such Qs. Their software does lag quite a bit in terms of usability ;-)
As you said, let's forget about usability and focus on the problem more as a logical one. Btw, is there something still open?
I think logical (impractical sounding) problems are as important as playing games...they help in exercising the brain.
Logically, it is a fine question. But as a programmer, you do need to worry about the usability of your program: otherwise, it is not too different from a pile of rubbish.
Since I do not implement end-user UI, maybe I try to keep it separate. But even in this solution you can design a UI that does not make minimum use of PIO "a pile of rubbish." Maybe you can have two or three buttons connected to a single Input.
My point was that it is similar to bringing the memory usage of a program from 80 bytes to 20 bytes...in most cases, that will be a pointless exercise
[My best Ross Voice]I respectfully disagree.
If you are working mostly with windows, then you may be right but those are not "most cases" for many of us. And even if it is a pointless exercise, you will be a far better programmer if you just know how to do it. I will definitely select the programmer who knows how to do it rather than a guy who says "why bother, we have so much memory nowadays."
As for questions in interviews in {evil_company_whose_name_shall_not_be_uttered}, I am not very surprised that they ask such Qs. Their software does lag quite a bit in terms of usability ;-)
Another needless MS bashing. One thing that makes MS software so popular than say Linux is its ease of use. Even today, *for an average user*, it is still a lot easier to set up a Wireless Lan on a Windows desktop than a linux box.
You mistook me...I didn't say Linux is good. It is probably worse than Windows.
I am sure they have smart programmers, but smart doesn't necessarily mean good. Using an efficient data structure to reduce memory consumption is important and useful...I am sure it is very important in embedded systems.
However, if the end-goal of your project is the end-user experience, then a good programmer needs to strike the "right balance" between usability and memory consumption. I believe MS tries to do exactly this...they sacrifice memory for usability. But they still lag behind Apple's products in terms of usability.
Anyway, as you said, MS *used to* ask such questions. I don't believe they do so any more...probably because such questions have nothing to do with good programming :-)
Maybe you can have two or three buttons connected to a single Input.
As phrased, the original question is just a UI question. Also, as nemo pointed out, accidental double-presses are a problem...that will be more common than accidentally pressing two buttons at the same time.
Please guys/gals, stop this irrevelant discussion about MS, Linux, Apple etc.
I asked the question about usability purely from a curiosity perspective, whether the poser had thought about that. There is no need for a flame war. As I said in my last post, these puzzles serve as good exercises for the brain and are as important as any sport.
Anyway, as you said, MS *used to* ask such questions. I don't believe they do so any more...probably because such questions have nothing to do with good programming :-)
..or maybe they grew so big that they no longer can afford the luxury of hiring the best of the best. They relaxed the criteria probably :)
MS still lets you answer in the language of your choice as they rightly believe the syntax has nothing to do with your thought process and many of the "programming" problems are impractical.
As phrased, the original question is just a UI question.
Maybe that is because of the difference in definition of efficiency for a GUI programmer and for someone who does not have the luxury of working with seemingly unlimited resources.
Also, as nemo pointed out, accidental double-presses are a problem...that will be more common than accidentally pressing two buttons at the same time.
Ok, a valid doubt. But something that can be easily solved.
Firstly, accidental double press for those giant elevator buttons are rare.
Secondly, you can easily reduce or eliminate it by not acting on an input within few milliseconds of an input. (BTW, We record it as an input only when the user releases the button.)
That means we will give some indication of response before the second press (due to the time lag) and the user will know that it was a double-press and not a no-op.
The question was and is how to reduce the number of buttons. And even considering the UI, I believe that people can easily pick it up and it will be faster in the longer run.
If you considered the question purely from UI point of view, you should have said something like disable (gray out??) the current floor button, maybe with a visual indication. That will narrow down the choices to DoorOpen, DoorClose and TheOtherFloor. People have already suggested combining button2 and button3 and all I am saying is you have a use for #1 or #(2&3) at any instant of time (separated by a duration as mentioned earlier in this comment).
Next time I will put a footnote about the target users for you and the platform to be used (and maybe the memory available.)
And yes, I will say this again, bringing memory from 80 bytes to 20 bytes is not a worthless exercise. That hurt :). It can make a difference between winning and losing a customer.
Seems as if I ruffled a few feathers :-)
Post a Comment
<< Home