SumUp | Android, Full-Stack and many more Engineering positions | Berlin / São Paulo / Cologne / Sofia / Copenhagen | https://sumup.com
SumUp is a leading financial technology company, serving millions of merchants across 35 markets. We empower business owners by enabling them to accept card payments in-store, in-app and online, in a simple, secure and cost-effective way.
While there are many roles open, I would like to specifically mention two for teams that I personally work closely with:
Senior Android Engineer [Berlin or Cologne, Germany / São Paulo, Brazil]
In SumUp's highly motivated and engineering-driven Identity team, we are working on providing best-in-class authentication experiences and account protection for millions of users globally.
We are looking for a Senior Android Engineer with a passion for security to join us!
We are hiring for a Backend-focused Fullstack developer to help build out our internal backoffice. This role focuses on building a platform for internal teams to build out backoffice components focused on their business while also supporting internal employees in optimizing their workflows through consistent design patterns, and streamlined flows.
The role stack will require working on ReactJS, NextJs, Typescript and Golang, but we none of the tools are a hard requirement, as we are eager to work with people who are willing to dive in head-first and learn something new.
Many many more roles (Data Analytics, Data Engineering, Backend Engineers (mostly Go [golang] or Kotlin/Java), iOS and Android, as well as many non-engineering roles): https://www.sumup.com/careers/positions/
That should be rather easily doable but finding a company obviously depends on what you're looking for. Most likely you're in Software Engineering? If so, with which preferences and specialities?
Here at SumUp we're hiring fully remotely across the EU and most teams are very flexible regarding the working hours. A 4-day week should be easily doable and I've personally done that before.
Contact me via my email address in my profile and I'm happy to connect you with the best matching team.
SumUp | Multiple Software Engineering and DevOps positions | Berlin / Cologne / Sofia / Paris / Barcelona / Warsaw / Copenhagen / REMOTE (Germany or EU) | VISA | https://sumup.com
SumUp is a leading financial technology company, serving millions of merchants across 32 markets. We empower business owners by enabling them to accept card payments in-store, in-app and online, in a simple, secure and cost-effective way. We're already 3000+ SumUppers around the globe and growing fast!
For me personally the top reason to work for SumUp is probably our engineering and team culture. We invest heavily into our DevOps capabilities and work in small autonomous and cross-functional teams.
We offer bi-weekly Hack Days for projects of your choice, as well as annual Hack Weeks (in May we're all going to Portugal), a generous learning and development budget and plenty of perks.
I'm mostly looking for new colleagues to join us building our first consumer-facing solutions and help our millions of existing merchants to connect with their customers to turn payment transactions into relationships:
• Backend Engineers: Go (golang) / PostgreSQL / k8s / AWS stack. You should bring some backend experience, but Go knowledge is a bonus, not a must. We're happy to train you https://grnh.se/49a869762us
At least for atomic access, I still believe that using wrapper types that prevent non-atomic access are the better idea: e.g. https://github.com/julienschmidt/atom (or uber/atomic).
That already ensures safe access at dev / compile-time. One explicitly states on declaration that the variable is accessed atomically by using the wrapper type.
A linter could then simply check that sync/atomic isn't used directly anywhere.
I really appreciate the work that is done to improve the database/sql package. It is still rather young and not as mature as for example JDBC. I would rather thank the people who work on it for the work they do, than to point fingers for anything that is not done. The original design of database/sql was sometimes a bit too simplistic and will probably require some more ugly changes or workarounds in the future.
This specific change was a bit unfortunate. It tried to fix another bug caused by the introduction of Context cancellation support, but it unfortunately caused some other major bugs due to the changed semantics. Like the very same comment already indicates, other drivers also required changes. In retro-perspective I think it would have been better to try to handle the original issue entirely in database/sql, instead of changing the "contract" with the drivers.
Go MySQL Driver was, and I believe still is, developed mostly by some random programmers in their free time (I originally started it as a side-project during high school and until now was never paid for any work on it). It probably makes anyone who worked on it proud that now some major companies, not just GitHub, employ it. But like many such projects, it is not a perfect or finished product. If you use community-driven open source software at work, try to convince your management to set some work hours aside for actually contributing back to those, like GitHub did.
It took until December of the same year until we got the first bug report and figured out what was going on. While the semantic change might look subtle, it was certainly not from our (driver maintainer's) perspective.
We were quite disappointed that such a change was made 1) without informing the driver maintainers 2) making sure the changes were in place before this change made it into a Go release.
We regularly test against Go's master (now using a Travis CI cron job), but that only helps if the existing tests fail. We don't have the time to constantly monitor all changes in the Go repo.
If there is a need to make such changes (not just in database/sql and not just in Go), PLEASE actively communicate early with the community / the direct users.
I feel like this should require the user's explicit permission, just like audio, camera, location or Flash and Java Applets at the end of their life.
WebGPU is a great innovation, but we have both privacy and security concerns here. It should be available where and when the user wants it, not silently in the background.
We do something similar, although not through a REST API. We handle all this cert management centralized on one server, which publishes the DNS records for DNS verification etc.
On our other servers is then just a simple script that periodically checks if the certs on the machine are near the expiry date and if so pulls a new one from the central system.
ACME is an open protocol (and very soon it will be an IETF Internet Standard too). There are many alternative implementations. Just find one you trust.
We actually did our own DNS-based implementation for our infrastructure.
This blog post doesn't answer likely the biggest of all questions: Will there be breaking changes?
If so, how will those be handled?
"As a rule of thumb, we should aim to help at least ten times as many developers as we hurt with a given change" sounds like there might be breaking changes, but on the other hand Robert still talks about including new features in the Go 1 compatibility guarantee.
I'd love if the compiler would stay backwards compatible and packages / modules could be pinned to a certain version, either during import or in the package / module itself. Then one could write Go 2 code but still use packages which are not yet updated to Go 2.
Personally I think that making breaking changes is a good idea, as it allows to clean up previous mistakes. However, Go should at all cost avoid incompatibilities like between Python 2 and 3.
That's just BS. (IETF) QUIC was developed from scratch by an IETF working group. Google submitted its (Google) QUIC version as input, however the IETF version is not directly based on it.
AFAIK the proposal for HTTP-over-QUIC was to race with a TCP connection. Similar to Happy Eyeballs for IPv4/IPv6 dual stacks (meaning we could end up with 4 connections attempts?).
microG is certainly not perfect and I wouldn't recommend it to the average user. Expect some things to not work or even certain apps to crash. It's a techie-solution for people who value their privacy highly.
Android (the Android Open Source Project) itself is not the Problem. It's the lock-in ecosystem that Google tries to establish with the Google Services Framework, Play Store and the like. What is missing, is an open and privacy-friendly alternative to GSF. Without GSF we don't have efficient push notifications (Firebase Cloud Messaging), a geolocation provider, a maps API etc.
Personally, I have been using microG (https://microg.org/) instead of GSF on my phone for many years now. However, that is still just a partial solution. While it does its best to be privacy-friendly and does not have any integrated tracking / analytics like GSF, it still has to use Google's servers for push notifications, thus tracking is still possible to some degree.
But I agree, before Uber left the Chinese market, there was more pressure to be customer friendly. And the regular promos (with ridiculous amounts of free rides) where also nice from a customer perspective.
Lower connection establishment latency:
SCTP over UDP using DTLS requires 4 roundtrips (that's worse than standard TCP) while QUIC (which includes DTLS like encryption) only requires 1 roundtrip for the first connection and 0 RT for subsequent connections, when it cached some information.
After Google presented the protocol to the IETF several months ago, a working group was formed: https://datatracker.ietf.org/wg/quic/about/ / https://quicwg.github.io/
There will soon be a standardized version of QUIC with a fixed specification, probably by the end of next year.
I guess Google will still continue to experiment, but then probably based on the standardized version.
It is unlikely that it would be blocked in China since eavesdropping is easily possible.
(Vanilla) OpenVPN is blocked in China, likewise is IPsec and L2TP. SSTP can also easily be detected via Active Probing but I'm not sure if the GFW currently does that.
SumUp is a leading financial technology company, serving millions of merchants across 35 markets. We empower business owners by enabling them to accept card payments in-store, in-app and online, in a simple, secure and cost-effective way.
While there are many roles open, I would like to specifically mention two for teams that I personally work closely with:
Senior Android Engineer [Berlin or Cologne, Germany / São Paulo, Brazil]
In SumUp's highly motivated and engineering-driven Identity team, we are working on providing best-in-class authentication experiences and account protection for millions of users globally. We are looking for a Senior Android Engineer with a passion for security to join us!
Berlin/Cologne: https://www.sumup.com/careers/positions/berlin-germany/mobil... São Paulo: https://www.sumup.com/careers/positions/são-paulo-brazil/mob...
Senior Fullstack Engineer (Backoffice) [Berlin, Germany]
We are hiring for a Backend-focused Fullstack developer to help build out our internal backoffice. This role focuses on building a platform for internal teams to build out backoffice components focused on their business while also supporting internal employees in optimizing their workflows through consistent design patterns, and streamlined flows. The role stack will require working on ReactJS, NextJs, Typescript and Golang, but we none of the tools are a hard requirement, as we are eager to work with people who are willing to dive in head-first and learn something new.
https://www.sumup.com/careers/positions/berlin-germany/fulls...
Many many more roles (Data Analytics, Data Engineering, Backend Engineers (mostly Go [golang] or Kotlin/Java), iOS and Android, as well as many non-engineering roles): https://www.sumup.com/careers/positions/