The test checks whether you have the skills and performance of a senior python backend developer and as you say, at the time of taking it, you didn't have the required proficiency.
You can apply 365 days after your last application, though please note that you have to be better than the last time.
This blog post shows how to absolutely TERRORIZE a core developer using:
1. Bussiness card of an FBI agent, with a "call me" text hand-written on it
2. A phone and 10 minutes of time
If you have a few business cards and an entire afternoon, you can nuke entire projects (?) Something is not right here!
If you hurt your leg, you go to a doctor and he fixes you up. There is no shame in going to a doctor. If a postcard and a phone call can ruin your life, you can ALSO go to a doctor, and guess what, he will fix you up in that case as well! Try it. Go for one session with an open mind and (unless you have a really horrible doctor) it will help tremendously.
What if all you got is an Ak47 and they have ships, tanks, air fighters and drones in the sky?
Please think what would happen if the tables were turned - your country is invaded by a much bigger nation with a technological advantage. Would you organize a peaceful protest for your enemy to ignore?
If non-CP images start being blocked by this system, some gallery author is going to notice it pretty quickly and report it to the website owner. This censorship problem is remarkably easy to destroy the trust of the CP filter and I doubt people at Microsoft would fail to predict this.
bust most importantly:
(c) don't write much of this self-less code that nobody will be able to understand, test or statically analyze (since many tools assume OOP)
Article suggests that a high performance framework is implemented where notification of a unavailability will be propagated "before real user tried to execute a request" (which would have 50% probability of happening if number of heartbeats per second would be equal to number of requests per second the service serves, ha ha). Also from the Article we can learn that sending a 304 with content does not work as expected (!?)
Not only that, but there should be only one connection to database, through all traffic will go. Pulling that up through a network switch connected to a server with multiple cables, or pushing all that through a single TCP connection, with a foot note that advises against rewriting it after a few years?
Also, everything explained there should run in a single thread, because surely it will be fast enough.
Good luck with that.
[if you find other funny stuff that I missed, leave them in the comment section below]
> Article suggests that a high performance framework is implemented
> where notification of a unavailability will be propagated "before
> real user tried to execute a request" (which would have 50% probability
> of happening if number of heartbeats per second would be equal to number
> of requests per second the service serves, ha ha).
Yes and no. Sometimes there is a dependency that is used only on 1% of requests, or even 0.1% of requests. And that's thing thats hard to track by 50x error codes, because they are really rare.
But anyway it's not "fully designed feature", just a vision of what potentially can be done. So it's not going to be a stumbling-block for implementation.
> Also from the Article we can learn that sending a 304 with content does not work as expected (!?)
Sending 304 works as expected. Passing arbitrary status code with arbitrary headers with arbitrary body from the application to a framework doesn't work as expected.
> Not only that, but there should be only one connection to database,
> through all traffic will go. Pulling that up through a network switch
> connected to a server with multiple cables, or pushing all that through
> a single TCP connection, with a foot note that advises against rewriting
> it after a few years?
Not sure I understand your question well. But note that I'm speaking about Python. We have many python processes on the box anyway. Each of them has it's own connections to the downstreams (i.e. a database).
Then if we start writing asynchronous Python code, we need to send requests from multiple asynchronous tasks from each of the python process. I argue that it's more efficient to send requests from all tasks of a single process through a single downstream connection.
> Also, everything explained there should run in a single thread,
> because surely it will be fast enough.
Sure, single I/O thread in C will outperform any python processing of that data. That's true for 99.9% use cases.
