On the first of November, when I was doing a Google search, the search page animated suspiciously to reveal a hidden challenge.
 |
| Click image to view larger |
After verifying that this was not some malware, I proceeded to find out what this was all about.
 |
| Click image to view larger |
So it turns out, this is Google's secret way of gamifying the process of recruiting people. It has been around for a couple of years at least. Various articles speak of getting the invitation, and there are mentions on the internet about how to get the invitation by performing a pattern of Google searches. Google's foobar website says it's only by invitation. So congratulations if you received an invite!
You get the following options to navigate the shell.
There are five challenges to solve, and by the time people finished the third challenge, I hear they are offered a chance to submit their details to a Google recruiter, who then decides whether to invite the person for an interview or not.
The challenges are like the Machine Graded Programming Tests I passed at C-DAC. So since it was a holiday, I decided to try the first challenge.
Re-ID
=====
There's some unrest in the minion ranks: minions with ID numbers like "1", "42", and other "good" numbers have been lording it over the poor minions who are stuck with more boring IDs. To quell the unrest, Commander Lambda has tasked you with reassigning everyone new random IDs based on a Completely Foolproof Scheme.
Commander Lambda has concatenated the prime numbers in a single long string: "2357111317192329...". Now every minion must draw a number from a hat. That number is the starting index in that string of primes, and the minion's new ID number will be the next five digits in the string. So if a minion draws "3", their ID number will be "71113".
Help the Commander assign these IDs by writing a function solution(n) which takes in the starting index n of Lambda's string of all primes, and returns the next five digits in the string. Commander Lambda has a lot of minions, so the value of n will always be between 0 and 10000.
Languages
=========
To provide a Java solution, edit Solution.java
To provide a Python solution, edit solution.py
Test cases
==========
Your code should pass the following test cases.
Note that it may also be run against hidden test cases not shown here.
-- Java cases --
Input:
Solution.solution(0)
Output:
23571
Input:
Solution.solution(3)
Output:
71113
-- Python cases --
Input:
solution.solution(0)
Output:
23571
Input:
solution.solution(3)
This was a simple one. I solved it in the very first attempt. An animated bunny was shown hopping around the screen.
The second challenge was a bit trickier.
Gearing Up for Destruction
==========================
As Commander Lambda's personal assistant, you've been assigned the task of configuring the LAMBCHOP doomsday device's axial orientation gears. It should be pretty simple -- just add gears to create the appropriate rotation ratio. But the problem is, due to the layout of the LAMBCHOP and the complicated system of beams and pipes supporting it, the pegs that will support the gears are fixed in place.
The LAMBCHOP's engineers have given you lists identifying the placement of groups of pegs along various support beams. You need to place a gear on each peg (otherwise the gears will collide with unoccupied pegs). The engineers have plenty of gears in all different sizes stocked up, so you can choose gears of any size, from a radius of 1 on up. Your goal is to build a system where the last gear rotates at twice the rate (in revolutions per minute, or rpm) of the first gear, no matter the direction. Each gear (except the last) touches and turns the gear on the next peg to the right.
Given a list of distinct positive integers named pegs representing the location of each peg along the support beam, write a function solution(pegs) which, if there is a solution, returns a list of two positive integers a and b representing the numerator and denominator of the first gear's radius in its simplest form in order to achieve the goal above, such that radius = a/b. The ratio a/b should be greater than or equal to 1. Not all support configurations will necessarily be capable of creating the proper rotation ratio, so if the task is impossible, the function solution(pegs) should return the list [-1, -1].
For example, if the pegs are placed at [4, 30, 50], then the first gear could have a radius of 12, the second gear could have a radius of 14, and the last one a radius of 6. Thus, the last gear would rotate twice as fast as the first one. In this case, pegs would be [4, 30, 50] and solution(pegs) should return [12, 1].
The list pegs will be given sorted in ascending order and will contain at least 2 and no more than 20 distinct positive integers, all between 1 and 10000 inclusive.
I requested the Google team to provide a clearer explanation of why the radius was a/b, but they didn't reply. There were many solutions and explanations listed on the internet. I'll be honest. This is the kind of problem I'd typically take some time to research, deduce and solve. I just didn't want to put in more time to solve this. Solving it just for the sake of solving it, and solving math problems in school just for the sake of solving them, always reminded me of this amusing story by Mr. R K Narayan. Here's an excerpt:
"...Rama has ten mangoes with which he wants to earn fifteen annas. Krishna wants only four mangoes. How much will Krishna have to pay?"... Swaminathan felt an unaccountable sympathy for Krishna.
'Have you done the sum?' father asked, looking over the newspaper he was reading.
'Father, will you tell me if the mangoes were ripe?'
Father regarded him for a while and smothering a smile remarked: 'Do the sum first. I will tell you whether the fruits were ripe or not, afterwards.'
Swaminathan felt utterly helpless. If only father would tell him whether
Rama was trying to sell ripe fruits or unripe ones! Of what avail would it be to tell him afterwards? He felt strongly that the answer to this question contained the key to the whole problem. It would be scandalous to expect fifteen annas for ten unripe mangoes...What was the matter with father? Swaminathan kept blinking. Where was the urgency to know its price? Anyway, if father wanted so badly to know, instead of harassing him, let him go to the market and find it out.
If Swaminathan was first given some pocket-money and introduced to a situation where he actually had to buy something and figure out the best way to spend his money, he'd have appreciated and solved the math problem more willingly. Instead, what our school books and these coding interviews do, is present a problem to us which we know is pointless to solve. There are better ways of evaluating skill.
Dr. Stuart Woolley wrote a nice article on "Why You Should Never Consent to a Coding Test in an Interview". He observes similar points that I've noted about conducting such tests as a monkey-see-monkey-do of what some other company does for its interviews.
Some things that should be changed
- Interruption: I was busy with some work. Why not contact me formally and schedule a time for the interview?
- Time limits: The foobar challenge needs you to login when they present the challenge. Even after logging in, there's a time limit. If you exceed it, you forfeit your chance. A friend received the invite while he was at work. Even he told me he didn't like the interruption and the fact that he was expected to login to his personal Google account while he was using his employer's computer. People may have various emergencies or problems in life they are going through. The time limit is unhelpful.
- Lack of clarity: When presenting this kind of a challenge, it's necessary to look it at from the point of view of the reader, and ensure that the question is explained well. Level 2's question was neither explained properly, nor did they explain it when I requested. Yes, I know that people solved it anyway. Even I eventually figured out on my own, what the a/b was. My point is, that it's the recruiter's responsibility to put in some effort to explain it well (or at least respond when the candidate asks questions).
- Solutions available: Various people have publicly posted answers to the foobar challenges. Solving it does not really evaluate a candidate's critical thinking and problem solving capability.
- Time wasted: This process wastes time. Even if one spends many hours solving these problems, there's no guarantee of getting interviewed, or of getting the job. Think of how much time is lost in doing coding challenges of multiple companies.
 |
| The amount of time candidates lose when the time-consuming coding round is conducted as one of the later rounds, versus when it is conducted as the very first round |
I know the recruitment process is complex. I know this is Google's way of finding candidates who like solving challenges in this way and want to join the company. I know that candidates should be grateful for being given a chance. However, in my humble opinion, this is a poor way of evaluating people. It follows a similar metric that schools and colleges use, where fishes are evaluated based on how quickly they can climb a tree.
Understand talent
An old management book I once read, had a page where the experienced author noted that even a mediocre but well-coordinated team can beat a highly skilled team. This is something that many companies need to understand. There are plenty of intelligent people out there who have varied skillsets which may not be math-specific. They may take time to understand concepts. They may not be able to memorize a lot of information. But when they are given the necessary time, support, trust, respect and encouragement, they can use their creativity and skills to deliver better results than anyone else.
So companies, try this:
- Candidate strengths: Re-design the hiring process to understand what people's interests and strengths are. Understand how individuals function and in what kind of environments they thrive.
- Submission simplicity: Re-design the application submission process to be simpler. Don't make candidates fill in long forms, where they basically type out the same things that are already there on their CV. Make use of the "Easy Apply" options on job sites, to allow them to submit their CV in one click.
- Software design maturity: Don't conduct coding tests in the first few rounds. Doing it in the later rounds is ok, but still, making experienced candidates do coding tests is silly. Evaluate candidates on their ability to design de-coupled software components. Evaluate them on how well they create maintainable software. Evaluate them on how they design usable software. Check how they refer various sources or reach out for help when stuck with problems. See how they write test cases and how they design their software to allow for dependency injection, which makes it easier to create test cases. Look at their past work for sparks of creativity and innovation.
As for work environments:
- Build a warm, cooperative and supportive work culture. Plan work well so that you don't have to overwork people.
- It isn't enough to tell someone they are valued. They have to feel it. You'll notice that what employees really want from their boss, is knowing that their boss respects them. So select your managers even more carefully than you select your programmers.
- Don't build an emotionally cold workplace. Frequent interaction and feedback are necessary. Especially in the first few years of employment. See the still-face experiment. The need for validation and encouragement applies just the same for adults too.
