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.