lyricalpanda

This won't affect it because it's a merchant setting. What you can do though is complain to management and let them know. They can easily turn of tipping or lower the pre-set tip amounts.

2.6% + 10c with no contract fees, no cancellation fees, no minimum amount of purchases per month. It actually comes out to not be as expensive as most people think.

The first statement is a bit unfair. Square is pretty generic now, but of course a one size fits all solution isn't going to cut it for every case. I don't think that is a negative thing to ignore smaller markets that aren't as profitable if they dedicate tens/hundreds of millions of dollars towards these niche markets.

You misunderstand what strengths Square and Stripe both have. Stripe is a pure API/SDK that integrates with third-parties for everything other than payments.

Square has all those "third-parties" services bundled in to make it a much smoother experience for merchants. Payroll? Analytics? Dashboard? Everything is right there for you at Square. Stripe? They just link you to a bunch of third party sources.

Ultimately it boils down to: Stripe is geared towards more tech-savvy customers or those who can afford development costs for all these custom integrations + working with 3rd parties. Square is geared towards people who want it all in one ecosystem and don't need a lot of customization.

Stripe won't "eat" Square's lunch when it comes down to the base use-case of a simple merchant wanting an easy onboarding experience and taking payments. Stripe is anything but that. And for larger merchants you have to worry about what third-party services you integrate with Stripe - what if one of them goes under? Switching third-party services might be a huge pain. You don't have to worry about that with Square. Not to mention that first-party services always are better than third-party services. Square can always come up with better services to offer its customers because it has access to all the data. Third-party services are limited to what they can get via an API.

And as of right now, Square is actually beating Stripe on the SDK game with the release of ReaderSDK.

This is essentially what TripleByte is doing. It doesn't have a certification, but they put you through a general software engineering interview (with multiple parts). If you pass it, then they work with their partner companies to by-pass the initial screens and straight to the on-site.

Your argument is flawed and represents what's wrong with our industry's interviewing process. Respectfully, of course.

For most developers we don't need to even consider these trade-offs. It really depends what stack you're working with. Are you a front-end engineer? Then this doesn't even make sense because you wouldn't be putting that much into storage anyways that O() is going to matter.

I'm an iOS developer and quite frankly you shouldn't be doing that much business logic on the phone. We implemented an algorithm that had a O(n^4) runtime without optimizing it because the dataset was so small it wasn't worth the time to over optimize.

You're looking for an extremely rare case and discrediting 95-99% of the time we're programming. Sure we can do speed-ups but do you really have to filter every single developer for those criteria? You really don't. Guess what? Unicorns are built off the backs of medicore developers. The codebases once they start expanding are highly unoptimized. Slack was built from contractors. Twitch apparently is still having growing pains on their iOS app because the original developer wasn't very skilled. I was turned down from thumbtack even though I knew more about iOS than the iOS team lead that interviewed me because they valued CTCI more. The iOS team lead was taking advice from me about system design. What would you rather have? Someone that knows system design or someone that memorized how to serialize an n-ary tree? What is actually going to make you the bazillion dollars? A functioning app that can scale, or someone maybe helping you serialize a data structure (with a very known solution) on an iOS app which is completely useless?

It's simply an illusion that you need to have developers who have memorized useless problems in the case that they may one day possibly might see an issue they could optimize 1% better by introducing more complicated code.

I have a feeling that you don't really know much about SV startups.

Stick to vanilla iOS for now. I think it's telling enough that FB doesn't have all of their apps on RN. I don't think there will ever be a real replacement for Native. It's just a matter of how close a framework could get to copying it.