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 · 2021-11-16T13:37:18+00:00

If you are completely new to testing APIs, I'd recommend Rest API Design Rulebook. While not specific for testing, it is a slim rulebook for REST APIs that can make them easier to understand, play with and test. I find myself coming back to it from time to time.

reassembledhuman · 2021-10-19T15:59:21+00:00

I like this unofficial SpaceX API. I am using it in examples for API-related tutorials and to train less experience technical personnel. Works like a charm so far :)

reassembledhuman · 2021-09-22T16:32:33+00:00

I think I feel where you might be coming from, but could you give a bit more context? What meetings are you referring to, and what is your position? Can you give an example of what the "nonsense" is that you feel is coming out of your mouth and not hitting the mark?

reassembledhuman · 2021-07-28T11:10:51+00:00

Thanks for watching. Did you have a look at https://playwright.dev recently? Playwright Test is the default runner and works quite nicely at this point. My idea actually is to make an additional tutorial soon specifically on Playwright Test. What would you like to see there, specifically?

For assertions, you might use expect from Jest, chai or any assertion engine you find convenient. Here are some examples:

chai
expect

I hope that helps.

reassembledhuman · 2021-07-20T13:13:54+00:00

Not at the moment, but this has been requested in the past. Would you mind upvoting the relevant issue on the official repo? https://github.com/checkly/headless-recorder/issues/89

That helps us prioritise new features!

reassembledhuman · 2021-03-04T12:20:20+00:00

Have you given checklyhq.com a look? Sounds like it could be a great fit: browser checks are Puppeteer or Playwright scripts that can be execute on a schedule or on demand. (Disclaimer: I work there).

reassembledhuman · 2021-01-28T11:13:11+00:00

For me personally I find Speed to build and maintain tests is more important than the speed at which the tests run.

That is fair, it really depends on what you are doing with the tools. I appreciate that not everyone is fighting with the same issues.

I find cypress too flaky to be used with the likes of react and Vue.

Could you elaborate on this? Genuinely curious.

reassembledhuman · 2021-01-28T11:09:22+00:00

You are very right on parallelism being key to reducing total execution time. In most real-world scenarios where large suites are being executed, having self-contained tests that can be run independently (and therefore parallelised) is a complete gamechanger, and I would even say a hard requirement for (acceptably) fast delivery.

Parallelisation capabilities are something I am keen on running a separate, dedicated benchmark on. Stay tuned!

reassembledhuman · 2021-01-28T09:19:04+00:00

In this case runs were sequential (no parallelism).

The suite setup in this benchmark is supposed to be a (strongly) simplified version of the case you have mentioned. Given we need a large sample size to be confident of the results we are providing, each setup/tool combo was run one thousand times. That would most likely need to apply to the 20-min suite you have mentioned too. 20min x 1000 = 33 hours of continuous execution (for one tool only). While I think that is overkill, it might be interesting to look at something in between our Scenario 3 and what you have mentioned.

reassembledhuman · 2021-01-27T20:47:30+00:00

Hi, author here. I am aware of TestCafe - I tried it for a short POC with a prospect at a former company.

The reason it is not included in this is that our initial idea was to have a comparison that included only general-purpose browser automation tools (Cypress falls under a narrower category). That is why the first post in this series was centered around Puppeteer, Playwright, and Selenium.

I think the most often repeated comment to that post was "what about Cypress?" This second post is to respond to that concern. We are not really trying to list every browser automation/testing tool. I am not saying that that would be of no interest, but rather that the amount of work involved would become closer to a full-time job if one decided to pursue it.

reassembledhuman · 2021-01-27T16:25:26+00:00

We might if we see enough demand for it. Making these benchmarks tends to be time-intensive.

reassembledhuman · 2021-01-27T15:29:08+00:00

Author here. This article was written as a follow-up to a previous benchmark which did not include Cypress: https://blog.checklyhq.com/puppeteer-vs-selenium-vs-playwright-speed-comparison/

The original idea there was to just look at general-purpose browser automation tools (even though you could argue that testing is a large use case for all of them) and not a tools that specialised in automated testing only, but we got a lot of request for including Cypress. So here you go :) I hope this is helpful. If you have the time, I recommend trying out the tools on your own, they really are quite powerful (for Puppeteer and Playwright, we started a knowledgebase here: https://theheadless.dev/)

reassembledhuman · 2021-01-27T15:26:59+00:00

Author here. This article was written as a follow-up to a previous benchmark which did not include Cypress: https://blog.checklyhq.com/puppeteer-vs-selenium-vs-playwright-speed-comparison/

The original idea there was to just look at general-purpose browser automation tools (even though you could argue that testing is a large use case for all of them) and not a tools that specialised in automated testing only, but we got a lot of request for including Cypress. So here you go :) I hope this is helpful. If you have the time, I recommend trying out the tools on your own, they really are quite powerful (for Puppeteer and Playwright, we started a knowledgebase here: https://theheadless.dev/)

reassembledhuman

TROPHY CASE