G-Research Senior Software Engineer Interview Questions | Glassdoor.co.uk

G-Research Senior Software Engineer Interview Questions

Interviews at G-Research

2 Interview Reviews

Experience

Experience
0%
50%
50%

Getting an Interview

Getting an Interview
100%

Difficulty

3.5
Average

Difficulty

Hard
Average
Easy

 

Senior Software Engineer Interview

Anonymous Interview Candidate
No Offer
Negative Experience
Difficult Interview

Application

I applied through a recruiter. I interviewed at G-Research in December 2015.

Interview

After an online test I was invited to interview in London. I had to pay for travel and accomodation, and after the first interview round was dismissed without any kind of feedback. I never had the chance to talk to anyone from G-Research before going to London. Overall, a rather disappointing experience.

Interview Questions

  • My interview round was based on coding puzzles. The exact question content is under NDA.   Answer Question

Other Interview Reviews for G-Research

  1. Helpful (4)  

    Senior Software Engineer Interview

    Anonymous Interview Candidate in London, England
    No Offer
    Neutral Experience
    Average Interview

    Application

    I applied through a recruiter. The process took 4+ weeks. I interviewed at G-Research (London, England) in November 2018.

    Interview

    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.

    Interview Questions


Don't Miss Out On a Job You Love
Upload a CV to easily apply to jobs from anywhere. It's simple to set up.