Three problems, algorithm-centric, each solvable with (some intelligent thought and) a few lines of (say) Python. Unsurprisingly, the payoff is "we're hiring; please send us your resume".
ReadyForZero appears to be a company that helps people get out of credit card debt by tracking what you owe to whom and recommending what to pay off in what order. They just got Series A funding.
The most difficult part was figuring out unspecified things in the problems. Generally I had to use my intuition about "otherwise this would be either impossible or too easy" to get the right answer.
The first problem should be more explicit about the nature of the difference: a "typo" or non-shared could reasonably be an omission of a character, which would mean that the position of the unknown character does not matter. This weaker problem has more than one correct answer for the given input data. Better to call it a "corrupted byte" or somesuch.
It should be explicitly stated that the tree is balanced in the second problem. It should also state that each node contains exactly one character or that all nodes have nonempty payload (you can figure out either of those pieces of information from the other one).
The third problem should specify that it's looking for a strict partition. Contiguous is not a strong enough requirement. As written, I can have as many "contiguous subsequences" of zero elements as I want located anywhere in the string.
I particularly like the third as a teaching problem, and I might have to use it sometime. It's pretty simple, not overly reliant on programming concepts, and the "clever" solution is both faster and easier to implement than the brute-force try-everything solution.
Given that the point of this is to have fun and also tease out people worth hiring, having ambiguity in the problems is a good thing I think. Rarely is a real technical problem so clearly and obviously defined. So requiring a bit of thought and intuition might prove to be a good filter :)
You are looking for a sequence of 5 characters that differ by one character, but are otherwise identical (order matters). For example, an answer would be something like '89^hf' and '8z^hf'
That was a fun before-breakfast warmup; the input was always short enough that a simple, brute-force approach would usually work. The problem statements could have been made a little bit clearer though.
And what's up with the green-on-black Mac screen?!
My solutions: https://gist.github.com/1026309
Didn't really stop and think on the first one for too long, so it's a bit messy.
Overall it's quite easy but not trivial. Knowing the length of the challege at the beginnig wold be nice though.
Hello could someone help me with problem 2? I believe I am splitting the string correctly, 1 2 4 8 16 ... 512 = 1023 total chars/nodes, but when I add the integers of the last line (aka the leaves) I get the wrong result.
Fun challenge, but not too difficult. The largest challenge was making the intuitive leaps to discover the missing information in the questions, especially for problem two. A bit of trial and error, and a few lines of Python made for quick testing of those assumptions.
I am either misreading the third problem's description, or I have a bug I can't for the life of me see, because the answer my program puts out is not accepted.
The third problem is looking to partition the entire sequence of numbers into contiguous subsequences, all of which add up to the same sum. In other words, if the list were 23415, you subsequences could be 23, 41 and 5, all equaling 5. But the subsequences have to use up the entire string and they can't overlap.
They can't overlap! I don't think the problem specifies that?
You have to interpret "break up" to mean "non-overlapping" to claim that the problem means what you're saying it means; I found 341 "contiguous subsequences such that the sums of each of the subsequences are equal", but they overlap.
(If you had said "partition" I suspect I would have got what you meant)
You didn't need 3 guesses. The sum of each partition has to be a factor of the number. In particular the sum of the first partition has to be a factor. Then the second. That already gives you the answer I think.
It's possible if RAM isn't a constraint, using a bitset of all possible five-letter strings. The bitset would take up 4G of RAM (128G for extended ASCII, more for unicode).
In practice, that would actually be slower on this input, because of the cost of initializing the bitset. But that is not dependent on the input, so computational complexity is unaffected.
edit: Removed description. Yes, you're right, you can't even look at the whole input in constant time.
Wasn't hard. The problems could be better explained, for example in the second one they should clarify that the binary tree is balanced and that each node is one character.
> binary tree is balanced and that each node is one character
I found that pretty intuitive given they tell us it is a tree with 2^n-1 nodes, and that this is then umber of characters in the text file.
What I'm wondering about is what the '=' pad character means in the context of non-valid base64 (i.e. isn't it the same as the 'A' character - a null?)
Any comment in regard to my question above? At present, question 2 has serious ambiguity as to how one should interpret the data. Clearly each character represents one node, but again, there is no clear procedure for converting values. Padding makes no sense in this context.
I still don't follow. Digit value rather than ASCII code... you mean Base64 digit value? If so, do you just ignore the pad char? (I mean... by "non-digit leaves" you are referring to the leaves represented by '=' and only those?)
EDIT: I understand now... jeez that was a run-around! Ascii encoded decimal! Thanks for the clarifying replies all over.
I think it's literally one ASCII code (byte) per each of the 1023 nodes in the tree. Any time there's a non-digit in one of the leaf positions you ignore it.
One quickly realises that you must mean a balanced tree, since otherwise there would be no unique solution, but it would still be nice if it was explicit in the text.
Thanks for pointing that out. Yes, we could have checked every single corner case, but our job is to build financial software, not programming challenges, so we did it quick and dirty :)
ReadyForZero appears to be a company that helps people get out of credit card debt by tracking what you owe to whom and recommending what to pay off in what order. They just got Series A funding.