I am in a very similar situation (outrageous exchange rates from by Canadian bank). Do you use TransferWise to transfer between your own accounts in a Canadian bank or from your US bank to your Canadian bank?
US Bank account to a Canadian bank account. Sort of.
Because I'm an idiot, I'm still with RBC. They have a US subsidiary bank called "rbcbank" with no physical locations. Same terrible RBC service, but in America. They opened an account there for me. They offer very fast transfers between the US account and Canada account, but at the stupid rates they offer.
Does one really need to do data analysis to see that it is simply natural for large tests to be more flaky? All else being equal large tests perform more operations. If on average the probability of any single operation to fail is constant (fair assumption given the large number of tests) than the test that performs more operations has higher probability to fail (and no it is not linear as shown in the article, it is asymptotic approaching probability of one).
The "analysis" of tool types are strange too. Webdriver tests are more flaky because of inherent nature of UI tests operating on less stable interface (compared to e.g. typical unit test which usually deals with a pretty stable contract).
I used to spend quite some time on test stability issues in my previous team and wrote a couple posts on the topic and how to successfully go from unstable to stable test suite:
It's not strange at all. I appreciate the article's analysis. As the founder of the Selenium project, I frequently hear people blame Selenium for their problems. Sure, Selenium isn't perfect, but it seems like it is so much easier for people to blame their tools instead of questioning other things. But I understand why people do it. For a typical software developer, without an obvious cause for flakiness, the apparent randomness of a flaky test tends to make it easier (and plausibly justifiable) to "shoot the messenger".
Thanks, although credit these days rightfully goes to the huge multi-company and org team effort. (In other words, at this point, there are tons of people to blame for those flaky tests!)
The reasoning behind why large and Webdriver tests ought to be more flakey is sound. However, I don't see why having empirical data and doing the analysis is "strange".
Doing studies and collecting data should be how any assumption, seemingly reasonable or not, is proven right or wrong.
My experience with large customers in my previous startup was that they do all those things: they want demos, they ask for large volume discounts, they wants custom features and a custom license agreement and a 24x7 phone support.
My solution was simple: just refuse to do all those things. To my surprise vast majority of them went ahead and still bought my product (some posed an "offended" stance initially).
I guess for that to work you really have to have the best product for their needs. :-)
Yes, being autonomous is one of the most important traits I look for when hiring for my team (Disclaimer: I lead a distributed engineering team of 22).
Whether you are can be a good fit or no depends on how frequently you need to ask your teammates a question.
If you need to do that say once a day, I would say that is fine. If you are part of a distributed who are in different timezones then to be productive you will have to learn how to remove the roadblocks yourself.
Now if you need to do that every 10 minutes then I would say it is a problem and not just a poor fit for remote work but a general problem that can be bad in a co-located team as well. Most of developers are going to dislike interruptions no matter how nicely you do that.
ezhome aims to become the #1 trusted provider of tech-enabled home services, starting by targeting the millions of consumers that use lawn care services. We provide an amazingly better home service experience using data science and software technology to dazzle customers and enable our service personnel to be more effective and efficient. We are pioneering the tech-enabled home services space with a full-stack approach.
-- Overview of the Role --
We are looking for a Senior Software Engineer to join our team and drive our Android mobile App development. You will report directly to the Director of Engineering and will be responsible for one or multiple mobile apps, including design, architecture, development and testing.
-- Must have --
* 3+ years of experience in Android development.
* 5+ years of experience in software development.
* Strong analytical and debugging skills.
* Have a working schedule that makes you available during the morning Pacific Time.
ezhome aims to become the #1 trusted provider of tech-enabled home services, starting by targeting the millions of consumers that use lawn care services. We provide an amazingly better home service experience using data science and software technology to dazzle customers and enable our service personnel to be more effective and efficient. We are pioneering the tech-enabled home services space with a full-stack approach.
-- Overview of the Role --
We are looking for a great python engineer to join our engineering team. Your primary focus will be the development of server-side logic, ensuring high performance and responsiveness to requests from the front-end.
-- Must have --
* Extensive Python knowledge.
* Experience with Django.
* Able to create database schemas that represent and support business processes.
* Strong unit test and debugging skills.
* Have a working schedule that makes you available during the morning Pacific Time.
* Comfortable working remotely.
* Good understanding of software architecture, especially RESTful design.
CLU was way ahead of most of the mainstream languages of 80s. I remember that coding the compiler for generics and Pascal-like unit system I added on top of the standard spec was quite fun! I was compiling generics to an intermediate language opcode and then generating the machine language during the linking phase. Oh, those good old days!
This reminded me the good old days when I was writing a CLU compiler based on the spec found in the russian translation of Liskov's Abstraction and Specification book. :-)
