Skip to content

Intern role at Ritza

Ritza hires and trains engineering writers. This means people who are proficient both in software engineering (building things, often with code) and writing and teaching (explaining to others how to replicate what the writer built). Most people come to us stronger in either writing or engineering, and we can help you improve skills in either or both areas.

We do not have formally defined seniority levels, but we loosely think about people in terms of

  • Intern engineering writer -- can build simple proof-of-concept applications and write about how to achieve this in at least one language, often focusing only on a single language or framework and only on the back- or frontend. May need help from a more experienced engineer to figure out what to build and how to build it, including how to set up their environment. Their first drafts need significant editing work and they cannot take on more challenging assignments like using new and badly documented tools, or building more advanced full-stack examples backend, frontend, database, and deployment. Their work doesn't always follow best practices and their code might need heavy review in terms of efficiency, style, and maintainability.

  • Intermediate engineering writer -- can build out more advanced applications covering several stacks and languages. They know their tools well and do not need help with installing things like build tools, IDEs, or languages. Their first drafts need moderate editing work, and their might still be some best-practice problems with their code, but this is generally close to 'production-ready'. They can adapt their skills to develop examples in similar languages to ones they know (e.g. can develop a C# example if they are experienced in Java)

  • Staff engineering writer -- can build out production-level systems for complex topics like custom migrations, writing code across multiple languages and using tools like Docker and Kubernetes. They can learn new languages and frameworks as required to build examples and explain how they work. Their code always follows best-practices and doesn't need review beyond a basic run-through. Their writing needs only minor editing.

Coding, Writing, and Publishing

As a small company, Ritza has constantly shifting priorities. While we offer support and training for our interns as required, it's also not a 'fetch the coffee' kind of gig. We rely on our interns to produce and help ship our 'pipeline' -- the set of deliverables in any given month, where any piece may be in 'briefing', 'drafting', 'qa', 'editing', or 'publishing', and to help with growing Ritza (e.g. sales engineering).

As of May 2023, the day-in-the-life-of-an-intern may look like

This includes writing the code, but also figuring out how to fit different systems and platforms together. Often our article are long-form (2000+ words), but we also do shorter ones such as Sentry Answers (, StackOverflow style), or Tweets (e.g. this tweet, where we build a simple demo on CodePen and explain it in a Tweet).

  • Publishing operations -- this is all the other work that is required to get our work published and into the world. For example

  • Sales engineering -- to spread the word about Ritza, we often do small improvements for free to open source projects who we think might be interested in our services. For example, making corrections to their onboarding documentation or contributing a short guide on how to do something specific. This is similar to the 'engineering writing' above, but also includes more exploritory work of trying out their product and seeing what makes sense to do as a 'free sample'. Similarly, we write 'internal articles'. You can see examples at These are often shorter and shallower articles than the ones we produce for our customers, but they try to produce useful information related to things that are popular Google search terms.

  • Collaboration -- sometimes someone is struggling with something specific, or we anticipate that a deadline is going to be missed. We generally work asynchronously with conversations over Slack, but you'll also have at least one weekly call, and ad-hoc calls if required to figure out how best to collaborate with another writer or to help someone with a specific problem they're facing.


  • Overcommunication: We're all remote, so it's important that people over-communicate day-to-day. We have daily standups where people very briefly summarize what they are working on for the day in a shared team channel, but especially at the beginning it is important that people communicate progress and obstacles more often than once a day. It's much better to get help with something that someone else can do in 5 minutes than to bang your own head against a problem for a whole day, but because we are distributed we might not notice when you are stuck.
  • Honesty: we do only basic time tracking, so it's pretty easy for writers to pretend that things are more difficult or are taking longer than they in fact are, and get paid for hours that they are not actually giving to Ritza. Our business model is to buy hours and sell words, so you should be using every Ritza hour as effectively as you can towards our shared goals, and to quickly let the team know if you're not sure what you should be working on.
  • Attention to detail -- we don't have steep hierarchies and although we have a fairly polished publishing pipeline with different stages, not all of your work is going to be checked or verified. It's important that you are proud of what you produce and have high confidence that it is valuable to a reader and doesn't contain technical or other errors.

You should also read our Principles.


Working at Ritza means you'll get exposed to a large range of products, platforms, and technology. From trying out different customer products, to building examples across different languages and frameworks, you'll see we're very much about breadth over depth.

You'll also have one-on-ones every week for mentoring, whether that is improving your coding, your writing, or general career progression. This is your time and if you come prepared with things we can help you with, we're very happy to do that.


You will be an independent contractor and be required to invoice for the service you provide on a monthly basis. You can find details about invoicing and payments here.

You should do basic time tracking and submit a report monthly or as requested. We trust you to put in the agreed hours, but it helps us figure out where time is going and to optmize the business overall if we understand where hours are being spent. You're welcome to use any time tracking tool you use (e.g. Toggl), or just a basic spreadsheet, but we should be able to see how many hours you gave us on any given day and what the main things you worked on in those hours was. If you're using a spreadsheet, you could use columns such as

date, start time, end time, duration, summary
5 January 2023, 09:30,16:30,=B1-A1, wrote code samples for bryntum comparison article and uploaded 3 drafts to wordpress