Similarly I didn't see any mention of intermediate evolutionary stages being found for either a case 1 or 2? If someone sees a paper that does that, it'd be cool
162 karma · joined November 23, 2017
Similarly I didn't see any mention of intermediate evolutionary stages being found for either a case 1 or 2? If someone sees a paper that does that, it'd be cool
Left to Tell - Immaculée Ilibagiza's life, story of survival of the Rwandan Genocide and a tale of how to live on after such tragedy and how to forgive the unforgiveable.
Longitude - essentially a biography of John Harrison, the man who solved the longitude problem (and probably thereby made the success of the British Empire)
X, Y & Z - a brilliant biography of all the French, English and Polish codebreakers of WW2
Agent Zigzag - the story of the man who betrayed everyone and could possibly have killed Hitler if he was allowed
William Pitt the Younger (Robin Reilly) - possibly one of the most difficult periods in British History saw one of the best British Prime Ministers to date
Kukuczka - the story of how he became one of the world's most impressive climbers despite communist oppression
The Galileo Affair: A Documentary History - a highly interesting book that brings the necessary documents to the table to help understand a topic that is often treated in a very facile way
Ivan III and the Unification of Russia - a great book for understanding the basis on which Russia was built
Xenophon's Anabasis - what a load of fun. How to lead a failed army back home and gorge on mad honey
As a londoner, if you wanted a timetable more based on truth, it would look more like the attached graphic on the page - an analysis of the spread of waiting times.
Agreed that things can always improve.
The assumption you seem to be making is that anyone with a whiteboard is also an evil villain that wants to interrogate you violently you and pick on any mistakes that you might make. In reality, it is a higher level check to see if you can communicate at all.
We ask the candidate to describe a system they have recently built. Therefore they should have product context, they are not being tested on inventing whatsoever (unless they are actually doing an impressive con, in which case, they'll have to be extra skillfull). As mentioned below, we give candidates the benefit of the doubt, but quite a lot of candidates are unable to give even a simple explanation of what they've worked on.
As for the amount of pressure - all of the pressure is circumstantial. We try as hard as possible to put candidates at ease. Obviously it's not entirely possible, but we try our best. Secondly, scenarios like that happen all the time. Maybe I won't get fired, but if there is a pressing issue, for example, I often need to draw diagrams to explain what is happening to a part of a distributed system. It is impossible to do without diagrams. And communicating these issues clearly and concisely often leads to quicker resolution times and happier clients/stakeholders
Your first paragraph also goes directly against what you are trying to prove. If their success relies on good hiring, then they would pick the best methods. If they haven't, they wouldn't be successful and would be replaced.
What a load of twaddle .
You would be surprised at how poor some of the candidates are at this. Candidates who are unable to draw a few squares on a board to describe the last thing they worked on, and candidates who have never questioned any of the work they were assigned or don't understand that there are often multiple options for a solution, each with pros and cons.
If someone can't even draw a simple diagram on a board, I don't want to have to plan and come up with highly complex solutions over whole months with them.
The interviews have made me realise that countless candidates are unable to:
1. Give a high level overview of a product
2. Critique design choices and suggest improvements
3. Communicate well as to what the value of components are to the broader business.
Many of the developers can explain a particular piece of logic very well, others can't even do that. But in an enterprise scenario, we need excellent communicators.
The US spends a lot of money exporting its media, so it can't be surprising that everyone follows its movies and songs or that in London we occasionally have to endure a temporary hysteria about hand-egg (american football)
I think we currently don't have any functions in time-sensitive streams (they're rather new, so they are used for new features such as Oyster automated refunds, which can be applied a few days later if need be), so when I say we haven't had any performance issues with them, it has to be taken with a pinch of salt.
I think if we were using microservices, they would have substantially more logic in them than the individual functions have, so they would have a lower network overhead. They wouldn't scale automatically, so we'd have to have quite a few machines on all the time, which would cost a bit more.
The main benefit we enjoy from functions is the ability to change code with zero downtime, low risk and minimum disruptions to the whole service.
We've found the interfaces in Azure also to be great - we can write end-to-end tests that can poll service bus to check when all messages are delivered to assert against any final case.
A substantial part of a few of our systems use Azure Functions.
We've actually found them excellent to work with, fairly cheap and scaling very efficiently.
The main issues we've had are internal disagreements about how to pass app settings in efficiently. Originally we put all the app settings in the ARM templates used to deploy them. Then we put them as variables in VSTS. And then finally we decided to put them inti variable groups, which are within task groups, which are used by releases. It's a bit of a weird chain of dependencies, but now all of our parameters are located in one place