Tell us about your role!

I am a senior software engineer in the SDK squad. From a bird’s view perspective, this means that I spend my days minimizing the friction when a client, small or big, is trying to integrate any of our products into their existing platforms. In practice, this has meant that I have worked with a bunch of different things; stretching from developing and deploying Java services in Kubernetes to fixing the padding of some button in our headful SDK, Tink Link. In the engineering part of Tink’s, ownership and team autonomy is fundamental. Consequently, we are maintaining our own backend service, despite being frontend heavy, and also running our own on-call rotation. 

What do you love about your role?

It has to be the insight into what other teams are doing. Most products at Tink are developed in a way where an SDK is crucial to distribute them to our clients. We are early on included in the project discussions and share our opinions of what actions must be taken to deliver the best possible product. First and foremost, this is love-able because we get to be in the frontline of what is being delivered to our clients. But I would lie if I claimed I did not also like the attention we are getting from other teams asking for our words of wisdom.

What has been one of your favorite experiences so far?

The product launch of payments through Tink Link. When I joined Tink back in 2019, the payments initialization service was very young. There had been a proof of concept of building out support for this in Tink Link but it was a mess. What we had to do was to take something that was essentially a pile of bits and pieces and turn it into something production-ready. This was something I got to drive from our team’s perspective, and now a year and a half later we have fully functioning payment capabilities in Tink Link. 

What have you found most challenging?

Dealing with live credentials. At Tink we are building things that at the end of the day depend on connections to banks. The issue with that is that there is this black box that can behave unruly sometimes. When we do development, we want clear contracts, and thus we have test banks at Tink. That resolves the issue momentarily, but the contract is instead between the test bank and the real bank. This is fine when doing things in markets where we have live credentials for making end-to-end tests prior to shipping new features–but in markets where we don’t, it can be a hassle sometimes. Some debugging justifies you wearing a Sherlock Holmes outfit.

How would you describe the people in our organisation?

It’s hard to pin it to one single characteristic, but if it had to be one I’d say it’d be that people are funny at Tink. Few meetings (I would say none but I don’t dare to promise that) go without laughter. Aside from that, I’d say there is great variety, you would find sales-y sales folks, product-y product folks, and of course myself, engineer-y engineers.

What makes Tink different to other organisations?

1. The (real) dedication for learning.
Most organizations state they prioritize learning but only do so if it comes for free and definitely not if the kanban is not empty on tickets. Tink of course cares about getting the job done, but no one will bat an eye if you put a calendar entry LEARNING RUST 9-12 on a Tuesday. 

2. The smorgasbord of responsibility that is up for grabs!
I joined Tink as a junior in my career but was very eager to climb fast. My nightmare is an organization where you just can’t take more responsibility because there is none to be claimed. At Tink this was easy; my managers understood what type of career path I desired and helped me to find responsibilities taking me on such a trajectory. 

3. There is no such thing as a programmer at Tink.
You are an engineer, and by that you solve issues. Of course, you can love code(almost all at Tink do), but no one will just hand you a solution specification and expect you to type the code. Rather you will be involved in the project(what use case do we support by this), and with others scope limitations, capabilities, and timeline.