G-Research interview questions

Contacted by their HR department and asked to take a technical sit-down exam consisting of quite difficult mathematical, statistical and algorithmic questions. Signed NDA, so not allowed to disclose specifics on the questions. However, there are previous exams on their website to use for preparation. Their staff is really accommodating and helpful.

I wasn’t asked to sign an NDA therefore I have no qualms broadcasting my opinion here. Nonetheless, I won't reveal specifics about exercises/questions out of respect for a uniform process. Format: a short 35-minute telephone screen followed by a 4-hour 3 stage interview on site. During the screening I was asked a couple of language/data structure questions a mid-level developer ought to be able to answer. I had different interviewers for each stage. The afternoon felt *slightly* disorganised and adhoc because they were running late. There's no guarantee GR will follow the same order or structure in the future. Stage 1 - TDD/pair programming exercise File->New style TDD/pair programming assignment on a laptop (provided). The interviewer confirmed that you weren't expected to complete the entire assignment as it could easily have been a day long exercise. The exercise was a good skills demo, and my interviewer was both friendly and passionate. Our off-topic conversation showed that my experience was complementary (GetHashCode and null members catches everyone eventually; I’ve looked up Parquet row groups for my own needs - thank you!). Stage 2 - algorithm session The interviewer I met for the second algorithm stage was cold and dismissive from the get-go. We had no rapport. My CV lists some C++11 work in 2013/4. After confirming I was comfortable answering any questions about my CV, I found myself facing a code problem in C++... on paper. I haven't written code on paper since my first year of University and I'd forgotten enough C++ I couldn’t answer the question on paper convincingly. The gravity of my mistake left me numb and I should have respectfully left the interview at this stage. I felt and answered like an idiot impostor. I was asked questions from Cracking the Coding Interview - I recognised the first from a computer geometry class circa 2004 but I was unprepared to code 50+ lines on paper. Unlike white-boarding, which I do frequently, my written code wasn't up to scratch. Talking about my approach to the solution wasn't acceptable as the interviewer would only accept code on paper. I was asked another question from McDowell's book - either you know it, or you don't. I felt like the second stage was a hazing ritual. GR would receive better signals by quizzing candidates on the works of HP Lovecraft – either you’ve read him or you haven’t. Stage 3 - algorithm + architecture session The final session was with two developers. The first part was another paper algorithm question that I could answer in 5 lines of chicken scratchings followed by a system design question. Somewhere in between I was asked a question that I said was suitably solved by a top Eric Lippert answer on Stack Overflow but wasn't given the opportunity to demonstrate the pros and cons of that approach without access to a computer. It felt like the interviewers were fishing for specific answers to specific problems, perhaps ones that validate an existing design. Candidates should be offered to use the tools they'd be allowed to use if hired - i.e. Google and Stack Overflow - as anything less is an evaluation of the interview process rather than the employed value of the candidate. I was unconvincing in my system design. The ambiguity of my responses – there are multiple async models, repeating the word ‘async’ all the time didn’t help - ultimately led to confusion. Given that I design similar systems for a living, I should have been clearer. In summary, I expected a different style of interview for a six-figure senior role that demands years of relevant niche industry experience. At a bare minim you should ask the candidate about their current role and try to understand the strength/value they offer. I've had the pleasure of interviewing candidates for several years now. If you want to test coding ability, give them a problem, a computer and ask them to solve it in their favourite language. GR’s process, as it stands, only measures whether a candidate has memorised Cracking the Coding Interview or used the same libraries/patterns – there’s a lot more to software development than this. On the plus side I’ve got some offline goals: read the 'Mum Test' and practice paper coding.