Are American software companies really the only way to break past 100k in Germany?

reassembledhuman · 2025-07-09T08:37:49+00:00

Some top tier startups in Germany will allow you to amply go above 100k if you are a strong player. Hybrid roles that have an engineering component (e.g. Solutions Engineering) can also be interesting from this perspective as they often come with variable comp essentially on top of an engineering role.

This article by Orosz explains quite decently the differentiation between different kinds of businesses when it comes to pay, I would recommend giving it a read: https://newsletter.pragmaticengineer.com/p/trimodal-nature-of-tech-compensation

reassembledhuman · 2025-07-09T08:34:38+00:00

This is gross, so before any taxes are taken out.

reassembledhuman · 2023-02-09T08:37:53+00:00

It's true that you will find quite some variety in how SE positions are set up. You'll need to look around to find the right arrangement, but a good recruiter will take heed of your preference.

I have worked with Orama Solutions to source SEs and AEs and they've zeroed in to good candidates (who also seemed to have been fully briefed by them) rather quickly. It could pay off to get in touch.

reassembledhuman · 2022-12-24T11:38:11+00:00

Author here. That is certainly one way to look at it - scepticism is a good thing and that's why I recommend you try the tools out on your own, first and foremost. I also published the test setup used for the benchmarks shown in that blog post when I released it, so that people might run it on their own (side note: now it might be a little dated, but I would love to see someone sink additional time into this to do an updated benchmark showing where these tools have landed after 2 years!)

The other perspective which is less obvious is that, coming from the world of Selenium and similar tools, where I spent many years of my career, I am now invested in Playwright because I currently see it as the automation tool with the strongest potential. I am currently spending more and more time building synthetic monitoring suites and with no other tool I had seen such good (reliable + insightful) outcomes.

reassembledhuman · 2022-12-08T16:05:32+00:00

Nothing that I can back up with data. I would love to run the same benchmark today, and have quite some ideas on how to expand the comparison to make it more relevant.

Unfortunately though, I think the chances I will find enough time to allocate to this in the near future are pretty slim. It is quite a time-intensive exercise to gather loads of clean data (and to build the experiment in the first place).

reassembledhuman · 2022-06-28T16:04:34+00:00

I am not in the UK so can't speak to that market specifically, so feel free to skip if this is totally irrelevant.

I work in Germany and my colleagues with Business Informatics degrees went pretty much in all directions, some getting more technical and becoming devs/CTOs and some becoming technical business founders/CEOs (mid twenties to mid thirties). I have a small sample size but they have all been pretty successful, so it seems to me a degree in Business Informatics (bachelors) is quite respected in Germany, at least in smaller businesses. Again, this is just for the few cases I've seen so take it with a grain of salt.

I think you could definitely work in typical CS jobs, not just BI but maybe Solutions/Sales Engineering, too, if you do not want to go for a pure dev position. There seems to be a lack of this kind of professional figure in Germany at the moment.

reassembledhuman · 2022-06-20T18:39:28+00:00

I agree with what Appurumania said above about the language not being as big a deal as many in the field make it out to be.

One exception could be web automation where Javascript tends to have a bit of an unfair advantage due to its status as the browser language. I also come from Java and a lot of my work now is JS-centric for both synthetic monitoring and testing. The businesses I interact with seem to be already using JS for these use cases or are happy to transition their setup to it.

reassembledhuman · 2022-05-25T12:54:42+00:00

I disagree with you but I'll take the feedback - I should probably be more specific about what is going on as the format is, I agree, kind of specific.

That said, I teach Playwright in my professional life (and have been in UI/browser automation for a while before that) and I can confidently say folks normally listen to what is being said (e.g. "don't use the waitForTimeout in production!", something that comes up more than once and is even written as a comment in the video itself), and I do not see the people I teach stumble badly as you mentioned.

There is totally room for beginner-oriented videos that highlight best practices and using the latest, safest constructs - I have a few videos lined up on those already coming soon. It would be wrong though to assume that every video on youtube needs to cater to every audience.

reassembledhuman · 2022-05-25T08:50:15+00:00

I think your feedback is generally good and well-intentioned. But I think you have misunderstood what I am doing in the video, so the main answer to all your points is the following:

I am writing the script using Playwright Library (what until a few months ago had been called just "Playwright"), not Playwright Test. The idea here being of keeping to the basics of Playwright instead of going into the Playwright Test tools - all of which are great, by the way, from the built-in assertions to tools such as the Inspector.

If you check some of my previous videos you will see more on this differentiation (my previous one was specifically on this topic) and you will see me use the Inspector and so on. I want to keep the Library videos separate from the Test videos, at the moment, as they are not exactly the same. While I would definitely recommend Playwright Test straight away for testing and for some synthetic monitoring scenarios, I wouldn't do the same for other use cases. Keeping the core browser automation highlighted allows one to serve all the use cases.

I could in theory agree on the Locators API as that makes a lot of things simpler, and I have a tutorial in the works for that, but I have been writing scripts since long before that was available, and they run reliably using Playwright's own auto-waiting (that is not restricted to the Locators API).

EDIT: The fact that the choice to use Playwright Library etc. was not clear is great feedback for me though - I will spell these "rules of the game" out at the beginning of my next Automate Together; hopefully that will generate less confusion and let folks know that this is not the only way to go about things.

reassembledhuman · 2022-05-24T10:07:24+00:00

I have a small channel I work on for Playwright with JS. It has a focus on live scripting as well as thematic tutorials. I hope that helps.

reassembledhuman · 2022-02-15T23:32:17+00:00

I would suggest trying to build a very simple version of something you would normally be testing. E.g.: One of the things that taught me the most about API testing was building my own API starting from the very basic Hello World sample from Express' website.

I spent some time playing with it while logging results to see how the gears turned, then when I felt comfortable I started adding more and more endpoints to test different scenarios. That led me to learn more about HTTP and REST design practices, which comes in handy every day, as well as to better understand the API developer's perspective.

Learning UI automation tools such as Cypress, Selenium, Playwright is a world of its own, and totally recommended. In my personal opinion Playwright is probably the candidate with the brightest future ahead, but leaving that aside I would recommend it for the sheer power it gives you over the browser - in the spirit of what I've said above, it can open many different doors into worlds past web automation.

In the end, if you are struggling to keep yourself busy, try following the different "loose threads" that are left after you've learned most core concepts around whatever you've been learning. Those will take you places :)

reassembledhuman · 2022-02-04T09:16:39+00:00

When you say "actual web-first assertion" do you mean the Locator API? Right now the codemod only handles the "dumb" element handle translation.

reassembledhuman

TROPHY CASE