Yeah, so let me first say that our product is a web application, so that means we don't have any iOS or Andriod developers – yet. All of our developers are based on a webstack, we have some front end developers and some back end developers. Overall there is 8 of us, there is 5 front end developers and there is 3 back end developers and then there is me. On a high level we are organized as one team at the moment. We're 8 people now, and that kind of almost breaks the Amazon 2 pizza rule – the Amazon 2 pizza rule says that you should be able to feed every team with 2 pizzas, and the assumption is that a quarter of a pizza feeds one person. 8 is kind of the breaking point, so yeah, that might change in the future – so, we're still at 8. Apart from like the high level stuff, where we share the management and we share the scrum process on a more daily basis we have now everything organized as projects, that goes across departments. So for example with our application you collect feedback and our customers have a dashboard where they can watch and sort work with that feedback. For example let's say you want to build an export for this dashboard, this will involve many people. This will involve the product management to get requirements, it will involve the design, figuring out how this will look and feel, it will involve front end developers, because we need to build the interface, it will involve back end developers because we need to fetch stuff from the data base, it will involve maybe DevOps work because we want to put in the CDN where we can do that, but it also involves growth – should we market this feature, something that we maybe need to send out to the newsletters or something – and it even might support the customer service, because what if somebody already asked for the feature, we have to go back to these people, maybe talk to them, maybe they have some ideas how this will work.
So what I'm trying to say is if you're a developer in this project, you'll work with many different people from many departments, that's kind how we try to structure it. The advantage of this is if you're a developer in this team, of this project, you will talk to many different people, you will get insight on exactly why are we doing this. It will not just be something that you do because somebody tells you: "Hey we need an export." You really get the insight on why and how and how everything fits together and is made. The disadvantage is that the more people involved, the more communication weighs, you really need to take care that you don't get lost. And also if any other developers are to take over
these stories, this project, it's kind of hard because you are so deep into it that it's kind of hard to come as a new developer to such a project.
And the last thing I want to say about our team is what's special about our team – I thought about this a bit and it's really hard to say! I think we are a very international team, thats why I'm talking in english here now. So we have people from Austria, but also from Poland, from Russia, from Spain and from Slovenia, so english is the default language in our office and I think we are all very open and also very honest to each other. Like giving and receiving feedback is a very big part of working in our company and that starts with code reviews, where we're really honest about what could be improved, and ends on regular 1-on-1s that we have once a month to get a feel about how everbody's doing.
So basically, most of the recruiting process in our company is actually handled by the development team. That means I'll be the one who sorts out the applications and decides if we follow through with the written application. Then usually there is an interview with me, and after that we have a small coding challenge that everybody has to do, which is then also the basis for a more technical interview where you will talk to your future colleagues and also talk about what you did in the coding challenge and have a like really in-depth technical interview.
After that, usually there is a cross managerial review where you will talk to managers from different departments – so maybe the Head of Product or the CEO – just to get another second, the non-technical opinion.
Yeah, once you've joined us, there will be a technical advisor that is assigned to you, he or she will guide you through the first few weeks. There is also a lots of documentation and talking to various people in the company to get a feel of how we work, what the processes are, but overall during the onboarding I think the main goal is to really throw the people into it and really you should commit code that is on production in your first week, so that is the goal and we try to really be fast in that.
And last thing I want to say I guess is what we expect from applicants. Except for all the technical stuff, what I think is valued in our company is a drive for learning something new and it's great to have an opinion but it's really great being able to question your opinion, if you have an informed discussion about it and then maybe go back on your opinion once if you're actually convinced by something new.
Yeah, so our product is a feedback platform that allows our customers to make a decisions on a product and get feedback from their costumers. What that means in a technical way is that most of our things, many of the things that we do are implemented as widgets that work in the websites or web applications of our customers, so our code is running in somebody elses dome and that is very often a challenge. Not everybody appeals to web standards and maybe there are many different frameworks that are out there and we kind of need to work with all of them. So if Angular does a weird thing with the XHR requests, Usersnap needs to respect that and handle it in the correct way. That is very often a challenge!
Another thing that is also very closely tied to that – one of our features is to be able to create screenshots from our customers web site or application. That is also sometimes tricky, because we then render the screenshots in our own rendering engine and that also can lead to weird things if for example our customer does not expect all the web standards but they still expect the screenshots to work correctly. That is something that sometimes requires really creative and pragmatic solutions, I would say.
And I think the last point that I want to make is what has changed through all the years that we've been around – I think the thing that has changed the most is that we became more professional, in the early days of any startup everybody's kind of hacking it away "naah, let's not write automated tests, that will just holds us back, let's just host that database ourselves, it will be easier we don't need to do anything, just get it started in Postgres and we're done."
Yeah, that works really well in the beginning, but then it tends to backfire the longer you go and I think that is something that has really changed. So we've moved on from hosting everything ourselves first on to AWS now to fully embracing infrastructure as code. But also code-wise, we've implemented automated tests, we've implemented end to end test, we've implemented CI/CD pipelines so that releasing is no longer something that has to be done manually.
So yeah, I think we've grown up – also technically.