888 Spectate Python Developer Interview Questions | Glassdoor

888 Spectate Python Developer Interview Questions

Interviews at 888 Spectate

2 Interview Reviews

Experience

Experience
0%
50%
50%

Getting an Interview

Getting an Interview
100%

Difficulty

3.5
Average

Difficulty

Hard
Average
Easy

 

Python Developer Interview

Anonymous Interview Candidate
No Offer
Neutral Experience
Average Interview

Application

I applied through a recruiter. I interviewed at 888 Spectate in February 2019.

Interview

A recruiter approached me on Linkedin and set up a call with BetBright team. There recruiter sent me some information about the company through email one day before the call. There were 3 people on the other side of the line and basically the technical day asked Python concepts right away.

Interview Questions

  • How to I declare anonymous function?
    What's the difference between list and tuples?
    what can be a key in a dictionary?   Answer Question

Other Interview Reviews for 888 Spectate

  1. Helpful (4)  

    Python Developer Interview

    Anonymous Interview Candidate
    No Offer
    Negative Experience
    Difficult Interview

    Application

    The process took 2 weeks. I interviewed at 888 Spectate.

    Interview

    I interviewed with Betbright a while ago and thought the interview format/process was absolutely terrible.

    The first stage is an online python test. This consisted, mainly, of very esoteric python questions which mainly seemed to be aimed at tripping people up, rather than assessing their working knowledge of the Python programming language on a day-to-day basis.

    Questions like, what is the difference between __getattr__ and __getattribute__, when the question didn't even reference what style classes you are using, in this case, unless you are regularly overloading class magic methods you would be forgiven for forgetting which one does which (I had actually googled this a couple of months ago before this interview as I needed it for something, and had simply forgotten, given how rarely I need this kind of information).

    I still managed to pass this test, the next one was a phone interview, which, again consisted of quick fire python questions which lasted ~20 minutes. No chance for me to ask about the role, or, if, the role would suit me at all.

    The next stage was a take home test. One of the tasks was to implement a LRU cache.

    I submitted, what I thought, was a decent solution, complete with unit-tests and documentation.

    However, this is where I failed and was told they would not be pursuing with my application. The feedback I received highlighted the following two issues with my code.

    1. Print statements in my solution. I had sent a summary of my solution outlying that, while I would never leave print statements in comitted code, I had left 2 print statements in my code to show the LRU cache working, so that in the integration test that I had provided they could see the cache doing what it is supposed to, as, it is difficult to genuinely see the cahce working without this. This was purely to help the reviewer see if my code was working properly, and, obviously, the reviewer hadn't even read the summary as he/she would have understood why I left them in there, I obviously, could have implemented a proper logging system, but is this really necessary for a take home test??? So basically, if the developer had read my summary, I feel that pointing out using a print statement was harsh as it was purely to help the reviewer and I had explained why I had done it. If the developer hadn't read my summary, it's even more harsh as I had put ~3hrs into this test the least the reviewer could have done was read my summary.

    2. I had used a try: except KeyError: statement in my code for control flow. The feedback for this is that you should never use a try/except clause to control flow in Python. The reviewer of my code may not be an experienced Python developer as, per the Python docs, this is a recommended way of controling flow in Python and follows the EAFP ("it's Easier to Ask for Forgiveness than Permission") vs the LBYL ("Look Before You Leap") paradigm. In general, it really depends on the use case for using if key in dict vs try: except KeyError:. But for a take home test, which is always going to be a bit conrtrived anyway, I felt this again was very harsh and even goes against recommended design patterns in Python.

    Overall, I felt, I had to comit a lot of time to the process and never got a chance to ask about the role to see if I would even have wanted to work there. The python developer who looked at my code must have been either lazy and/or inexpereiced for me to receive the feedback I did.

    I think it's just as well, as having heard about the technologies they use, it sounds like they are stuck in the past, still using Py2.7 and old technologies.

    Interview Questions

    888 Spectate Response

    Feb 20, 2018 – HR Manager

    Thank you for taking the time to leave a review for us, it is very much appreciated. We apologise for the negative experience you had in going through our recruitment process. We will take your feedback on board and endeavour to improve our process to ensure a more positive experience in future.


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