Posts in rse

RSE report from visiting University College London Advanced Research Computing

Richard Darst visited UCL RSE to see what we can learn from them, and learned the following from speaking to Jonathan Cooper, the Director of Collaborations at ARC. Thanks to Jonathan for checking and improving this post.

The RSE team at UCL (“collaborations and consultancy”) is part of Advanced Research Computing Centre (ARC), which is a department-level organization within the university. Like Science-IT at Aalto, it is not part of their IT Services, but also not part an academic department/faculty: it’s sort of their own thing. Overall, they have around 120 people, of which about 60 are in the “Collaborations Team”, which is basically the RSE side of things (broader, as they have more professions, but the equivalent in type of activity as the RSE side of Science-IT). They are professional (not academic career track) staff, but ARC does have some academic affiliation which allows them to take part in academic teaching when it’s needed.

The actual RSE work is part of “Collaborations and Consultancy” and consists of jobs titles such as Data Scientists, Data Stewards, Research Software Engineers, Digital Research Managers, and Research Infrastructure Developers. It is not that different from Aalto RSE work, but their scale means they have more emphasis on large projects. Many of their staff are assigned to various projects for months at a time (usually more than one project, but not too many - actual day-to-day time allocation is decided based on what works for each project). Many projects have a more senior and junior staff member working together, or at least aware of the work.

Other sides of ARC are platforms & services (HPC and many more research-focused IT services) and teaching/training. Overall, ARC and ARC Collaborations are quite similar to Science-IT and Aalto RSE, but at a much larger and more industrial scale, capable of helping very many more people.

ARC’s RSE team has grown over the years. It started in 2012 with 3 posts, and by around 2016-2017 it was 8 people and began growing very rapidly.

I was especially interested in the work of RSE within research groups (this was the original purpose of the meeting). There are several main strategies they use.

A project provides funding and ARC staff member(s) are deployed to work on the project, scheduling as it makes sense. This is the most common approach, for large and small projects. All ARC staff area are on permanent contracts because when any given project funding ends, they know there will be other projects available. This is what we have done with some flagship projects.

“Professional opportunities” - this is a special middle ground. Someone is hired as a RSE to a research group, with ARC’s help in recruitment. They are paid and work within the group (with a job title such as postdoc). ARC supports their work and makes sure it goes well. After the funding is over, the person is pre-approved to join ARC permanently if they wish (assuming things have gone well, which thanks to ARC’s help, they always do).

“Associate ARC membership” - people outside of ARC can become associated and be part of chat channels, meetings, internal trainings, etc. This allows others to improve their research engineering skills even without being employed by ARC.

Like we have found, they think that full time permanent employment is best for professional RSE work. Short-term contracts like postdocs results in mixed motivations and constant turnover. They have scale so that they know people are always being hired, so that they can essentially promise postdocs positions when they are done. This allows higher quality candidates and for them to focus on their RSE work, not think about what (academic) job might come next. They currently (in 2025) have enough history to have approval to hire 6 new staff each year (even without knowing exactly what projects they will work on).

Just like at Aalto, one can also ask “should these staff better be hired within research projects in academic departments?” And just like at Aalto, the answer is “yes, it could make sense - but these departments aren’t current set up to teach, mentor, supervise, promote, and keep RSE skills.” Thus it’s a separate team, just like at Aalto.

Overall, my evaluation is that if ARC is doing a lot of things right, Aalto Science-IT is doing it right too. There are implementation differences as you might expect from the different national and university environment. My thoughts for the future are:

ARC RSE began growing very rapidly after about 5 years of existence (6-8 staff/year). Aalto RSE is that point now.

Hiring RSEs to research groups is possible, but is different than hiring to a central team. It requires close cooperation and thought about their future career paths, otherwise the effect is only a bit different from a postdoc.

Research computing is different than university IT Services, I like the way UCL research computing is a different department, but practically speaking I don’t think we can or should go towards that now.

Read more ...

What is a Research Software Engineer?

What is a Research Software Engineer (RSE)? Too many things to define, you can find these definitions elsewhere. Maybe the question you would like to know is How do I get value from Research Engineers like Aalto Scientific Computing does? - that’s what we’ll try to answer here. Through that, we may learn a functional definition.

This page is written from the perspective of computational science - similar messages may apply to other fields. Note that computing and AI is in every field now.

When someone wants Research Engineers, it’s probably because they see something that is missing in the current academic system. Thus, to understand what we want, we need to understand the system. Below is rkdarst’s current mental model:

Academics are who we usually consider researchers. They do research, and are promoted based on articles published and citations received from other academics. Citations from academics tend to focus on innovation and novelness, so that’s what decides career paths.

Research Engineers (REs) focus on the practice and “structural integrity” of the research: the tools, the reproducibility, and more. They are more concerned with the work being done well, than pure novelness and citations. [0]

Research Software Engineers (RSEs) are a subset of Research Engineers, and I feel that the “software” is the least significant part there. Software is important, but so is data, computing, reproducibility, etc.

Particular examples of things that Research Engineers are good at include: Reproduciblity, maintaining software and data across academic generations, Open Science, programming, using large computer clusters, data security, and research ethics processes.

Researchers, in my mind, cover both of the above (and more). Industrial research teams would have both of the above and possibly even more different roles all working together on their problems. In universities, we tend to only consider the academics to researchers.

So what’s a Research Engineer? To me, it’s defined mostly in terms of what is missing from the typical academic career path (of undergraduate → junior researcher → senior researcher). At all levels, I’ve seen research engineering under-valued and under-taught (not necessarily because it’s not wanted, but because it’s not novel science and there’s no time). Senior researchers (group leaders) often see the value, but don’t have the time (or sometimes ability) to train and supervise research engineers well.

Years before Aalto RSE started (~2017-2018), I saw a need for more basic skills (for example: version control to manage code) and worked to promote them in undergraduate programs. This basically didn’t work, because they were seen as not scientific thus not something to be taught in academic courses (and if they were thought, the courses would be full of people looking for easy ECTS). While there certainly are study programs in software and software engineering, these are their own thing, and not part of data science, or other fields that need computation. Software engineering programs also aren’t adapted for the unpredictibility of research.

This was the prompting to start Aalto Research Software Engineers - if we can’t teach people skills in study programs, we have to support them when they become researchers (and teach it via practical mentoring). This has worked out very well, as you can see by our rapid expansion and heavy usage.

Aalto RSE is essentially the collaborator our research groups need to do their top-level work. This system works very well, but are there other options?

The above leads to various ideas. Take your pick for what angle you want to approach the problem:

Better RE teaching in undergraduate programs:

As part of existing programs (is there time to teach this? Is there desire? On the other hand, RE skills are great for employment prospects)

As dedicated majors? (Some people are trying to make dedicated RSE study programs at different universities, and there is a value there. But if you ask me the best value is learning RE along with academic research in a different field)

Better RE teaching in graduate programs:

Many of the same things as above apply here, mainly the lack of time, and the necessity to spend time on novel research, not learning existing best practices.

Nurture REs within existing research groups:

Nothing stops group leaders from hiring students and postdocs who have chosen to focus on research engineering. This often happens when supervisors hire technical postdocs to manage the RE side of things. (The question is: can they be supervised and mentored well by academic supervisors, if they need to be home-grown?)

If group leaders hire good candidates, Aalto RSE can help mentor them. See the companion blog post RSE work rotations for one idea.

Recruit REs as professor-level group leaders” similar to how senior academics are recruited:

These people would focus on collaborating with others to make projects possible.

The university systems don’t seem set up to value these people, thus they don’t appear among the ranks. They could appear if they spent their careers chasing academic citations, but then would they be able to spend enough time on research engineering?

I think this is what some people mean when they say they want a RSE career path: a way to recruit senior academics who lead research engineering groups. I think the idea is good but it’s not how universities are set up, so it’s a long way off. The values systems may not even match up.

Create parallel structures that support research engineering

That is what Aalto RSE has done. We are researchers, but we make new research possible by collaborating with academics, instead of trying to publish by ourselves. We are part of the services of the School of Science.

We also take it upon ourselves to do teaching and mentoring via co-working for all types of researchers (aspiring academic or research engineer). We can fill in the technical mentoring that’s missing by many supervisors.

You can read about our history in more detail.

I’ve seen many people interested in gaining research engineering competence for their organization. You need to develop an environment where they fill in the gaps you need.

Junior academics: encourage them to explore their technical skills. Show that there is value in this, even if it reduces the number of publications. Encourage them to get training (for example the Aalto RSE training). Give them time, encouragement, and career prospects to reach beyond the focus on papers.

Other support staff at universities and other organizations: don’t view them as limited-purpose supporters of an {infrastructure, service, process}. View them as supporters of research: let them holistically support research projects from many angles at once, rather than only in narrow silos with strict project reporting requirements.

You can hire dedicated staff to be REs, but it’s important that they are integrated into the local research environment. Most of our hires have been local staff who have grown into a new role, and I think this is how it should be.

Any of the above, especially the first two, require time being made available for RE work and a clear vision and network. Aalto RSE (with the help of others in Finland) is planning on making a networking and onboarding program for new research engineers who wish to adopt this vision.

If you read this far, you probably see the value in research engineers and want them yourself. Just hiring someone, or changing someone’s job to “RSE”, won’t magically solve the problem you need. It’s a whole mindset shift towards a multi-disciplinary research team.

What’s the right level of research engineers, permanent and experienced or junior and learning? Probably a bit of both.

I know that “Research Engineer” is a job title that can have other definitions.

Read more ...

RSE work rotations

Let’s say you want to start a Research (Software) Engineer team in your own unit. How do you set your new hires off on the right path? A proposal is outlined below.

This is a companion post to Future RSE collaboration in Finland.

You need to find the right person to hire for the role. Most likely, this means someone with the skills you need but the mindset to transition from their own work to making other work possible. You can find hiring resources on the Aalto RSE page and some brief thoughts in the companion post Future RSE collaboration in Finland.

Let’s say you have hired someone. What’s next?

This proposal is much easier for someone inside of Aalto University than outside, but possibly could be negotiated for others.

Your new hire works as part of the existing School of Science RSE team initially, perhaps ~1 year.

The hire is paid, organizationally supervised in, and sits in your own unit. It is absolutely critical that they maintain close connections to your own unit, the membership in our team is only virtual. (Our team is remote-first, so this is easy).

They focus on projects from your own unit, but as part of our daily flow. This could mean asking your audience to join our Scicomp garage for help and requesting that new big projects come via our project management systems.

Your new hire will learn all about how we work.

Your new hire will experience a tremendous diversity of projects and work with experts on them.

After the initial ~1 year period, we sit down and decide what is next. Does your new hire stay working as part of our team (with a greater focus on your own unit’s projects)? Or do they split off and start doing their own thing in your unit? Or some combination?

This gives you the most important part of our onboarding and training. There is no better way to develop the right mindset. If we split later, your staff will know who to ask for harder problems that come up later.

If this sounds interesting to you, contact the author of this article (first.last@aalto.fi or various chat systems).

Read more ...

Future RSE collaboration in Finland

The Aalto University School of Science has a successful Research Software Engineering service serving the whole university. This service has proven its value and there are an increasing number of questions of how others can form their own teams in Finland and work together. This post gives some thoughts on the matter.

This page is the opinion of the author and not Aalto itself. It’s not an open offer for collaboration. The author is happy to help with any questions you may have (first.last@aalto.fi or various chat systems).

Universities have academics: the traditional core, making ideas and new results. Much research, even not “computer science”, needs computational tools. However, the skills needed even for basic computation can be so complex that not all academics can master it to do cutting-edge research. A Research (Software) Engineer (RSE) can bridge that gap: academics focus on their primary work, and the RSE makes the computing seamless.

For more info, see the Aalto RSE site. This is not that different from research engineers supporting complex physical equipment.

We’ve found there are plenty of qualified people to hire. The harder part is mentoring them to transition from a researcher (focused on single projects with emphasis on own publications) to supporter (supporting a wide variety of people with respect and compassion). This transition needs active mentoring.

See the companion post about work rotations for RSE mentoring - if you are in Aalto University then start there.

You should decide if you want (a) wide-ranging support which may include helping with basics or (b) specialist support for a limited audience. I would argue that our most important impact is (a): this has gotten us the most benefit overall, and a steady stream of more advanced projects as work advances.

Let’s say you want your own RSE team at your own organization. How can you and Aalto RSE work together?

Even without joint funding, some of us Aalto people would be happy to talk and give some advice, and be part of a broader general network. For example:

How our team works, what makes it work, advice for your team

Joint RSE seminars to build skills, for example as part of FCCI Tech (aka the SciComp Tech series), Nordic-RSE seminar series, or something new. Both of these are good for professional development and community.

All the advice and practices on the Aalto RSE site.

Professional networking and so on.

However, without funding, Aalto needs to focus on its own work.

With joint funding, it might be possible to make a collaboration.

Any higher level collaboration needs to be discussed with management. Assuming these discussions go well, we might join a collaboration together so that we can actually share projects between the team. There should always be a strong local presence, because that gets the best value. This opens more possibilities.

The more experienced or larger teams could provide:

Mentoring possibilities for new research engineers and their teams (see RSE work rotations).

A base for professional networking.

A larger base of knowledge, for more advice and help with specialist problems. A very important part of our team is that for almost any problem, someone has seen it and can solve it quickly. Then we train others to solve it.

Joint support sessions such as our Scicomp garage, which allowed a wider support base for problems, covering the previous point.

The newer or smaller teams could provide:

Funding via some joint project.

More staff around to help fill in the gaps when needed (these staff also get training in these projects they experience).

Specialty domain knowledge (both for support of academics and for professional development).

A collaboration with larger funding could have a joint project flow: there is one place to submit new projects requests, and the right people in any organization will work on them.

We would welcome observers in our support sessions, especially from other staff at Aalto. The Nordic-RSE chat is also a good way to ask questions and see what we are up to for those outside Aalto University.

We know of various opportunities being considered for national (Finland) or international RSE collaborations. The above are some basic thoughts, but any model would be tailored to the actual funding and partners. There is definitely a benefit to starting off together.

For more information, contact the author at first.last@aalto.fi and read Research Software Engineers for more info.

Read more ...

Research Software Engineer project funding: what’s been working

The “Research Software Engineer” service provides technical collaborators for researchers to complement their scientific knowledge. Read about Aalto RSE here. The idea of this service was that it would be available to everyone, but some projects who made extensive use would fund it themselves.

If you are a group leader reading this, Aalto RSE can help you release research code, debug it, make it reusable, rescue old code from former members and make it usable again, make it run on our cluster or CSC’s clusters, manage data, prepare data for easy use, and so on. If it’s not long (less than a month), our work is free, if it’s more than a month, the below applies.

When we started, we hoped for around 50% project funding. The idea was that a lot of the funding for the service would come from the research projects themselves. This hasn’t really worked out so well, because a) we accomplish the vast majority of our projects quickly, in less than a few weeks, and b) finance would understandably not like to deal with small transactions for small amounts of time.

What actually happened was that we basically have received only a small amount of the project funding we would have wanted. On the other hand, this also means we have supported a far wider variety of projects than we would have otherwise. It also means we are better accomplishing our other goal: tactical support right where and when it’s needed most, with the least amount of administrative overhead. This actually better matches our mission of helping the researchers who need us most.

For any long projects (more than a month or so), we still follow do our original plan: we can receive funding from grants (or basic funding) to do long-term projects. This is usually 40-80% of a RSE’s time, spread out over more than a month (and it can also be bursty: lots of work at some times, waiting for the next task at other times). We have done this for projects, and we know we can do it in the future.

But there’s another thing that has worked well: retainer-type funding instead of project-based funding. You have extra funding that needs to be used? You know your group needs support but you can’t name a single specific project to use all the time? Hire RSEs on long-term retainers and we’re there for you as needed. You will always get priority for all the quick questions you have (in Scicomp garage or otherwise), and you get the highest priority for your medium projects, we can attend your other group meetings, and so on. As your team wants, we’ll make high-impact improvements here and there. This could be (for example) anywhere from 10-40% time over a long period.

We have worked out how to do both one-off projects and retainers with Finance. As for as external funders are concerned, our staff count as researchers, so we can use any funding you might have.

If you think you have a project or want us on retainer, let us know: Research Software Engineers or Starting a project with us.

This is a valid questions. Compared to many RSE groups, we seem to be focusing on many small questions for a broad audience that knows a lot about the problems they need to solve. Thus, we can come in to something already set up well, provide help, and mostly back off and be available for maintenance long-term. The units that fund us (schools, departments) have been happy with this, so we’ve kept it up. On the other hand, we are pretty fast. There have been projects where a summer worker was going to be hired, that we could end up doing (learning the framework + all the main tasks) in two weeks. The way we work together as a team also makes things quite fast. Thus, a project has to be quite deep in order to exceed a month of work.

Read more ...

The Aalto RSE hiring process

This post describes the hiring process of Aalto RSE. The goal is to make hiring more equitable by providing the background information so that everyone can apply successfully. For those not applying to us, it might still provide some valuable insight about how to market your skills as a PhD making a sideways career move. What’s said here may not apply to every organization, but it might give you some things to think about.

Disclaimer: This page is a rough average description of the past, not a promise to always do this in the future.

Aalto RSE has usually hired people who have postdoc experience and will transition to a more applied software/data/computing oriented role (as opposed to being focused on writing papers). For many people, we are the first experience of job applications post-degree and thus people have to learn how to present their skills in a new, non-academic context.

One should start by reading about us - we have lots of information publicly available about what we do and how we think. This should be understood in order to do the next steps well.

The cover letter is the most important thing we read, and the first and most important filter. It’s read before the CV.

At the level we are at, almost everyone’s CV and achievements are effectively equivalent. Does it matter who got the most fancy papers? Who has the most awards? The classes people took? When most of a person’s knowledge has come from self-study, probably not. The cover letter is the chance to interpret your skills in the context of the job you are applying for.

When reading the cover letter, the first question we ask is “does this person know what they are applying to and know why they think they are a good fit?” (It’s always interesting to get letters which clearly don’t understand the job, but on the other hand it’s an easy filter.) The first paragraph should answer this question and that the rest of the letter will go into detail about why. Start with the most important information, don’t make it hard for us.

Beyond that, talk about interests and skills as relevant to the organization. Discuss special projects, including non-academic ones or random things that you are interested in (this is especially true for us, since we are the transition from academia to practical work). Our job advertisement gives you some specific ideas that you can talk about. Anything specifically important to the job should be pointed out here and not just left in the CV.

If you don’t exactly fit the stated job requirements: here is the chance to explain it. The job requirement has to say roughly what we need (to not waste people’s time when applying, and because our hiring decisions must be justifiable based on the requirements), but there are many cases where someone with a different experience can accomplish our actual goal (as said in the job ad or found in your background research). A person that can say this, that they are adaptable, and will have a very good chance.

We have adopted some system of anonymous recruiting. We request that cover letters are submitted without identifying information (name, signature, etc) so that one person gives them numbers, and a broader group tries to take a non-biased look at them. After this initial impression, we bring in the rest of the application. Don’t make assumptions about what the reader will know about your background, just say it.

The letter should be as short as possible to get the information across. One page is usually about the shortest we get, and a bit less than two pages is typical. But if it’s engaging, we’ll read as much as you write. Remember, most important information first, don’t make us hunt for things.

Update 2024: Do you want to use AI to write your cover letter? Please think again. Since LLMs became a thing, cover letters have become harder to read, longer, and more generic-sounding. It’s better to write in your own voice and be shorter than rely on what AI gives you.

The CV serves as non-anonymous reference information, but they are hard to read and all look pretty similar. To be honest, we don’t worry that much about the format and contents here: get us basic factual information in the most efficient way. For our particular jobs, non-academic skills such as software/data tools are more important than scientific articles, etc. Remember, we are busy and have plenty of applications, make it easy to read.

Open Science isn’t just good for research, it’s good for you, too. If you can point to public repositories of work you have done, this is very useful. Things like Gitlab/Github profiles with activity and your own projects, links to data you have released, etc. They don’t have to be perfect - something is better than nothing. The best case would be a few projects which are well-done (and you know it and point them out to us), and plenty more stuff that may be of lower quality to show you can get simple stuff done simply. Not everyone is fortunate to have a field where they can practice open science throughout their career, but even publishing a project or two before they apply for a job with us is very useful.

Despite what the previous section said, we do try to dig through applications that seem on-topic but don’t say everything we are looking for, to give them the most fair shot we can.

We always need to heavily filter the list down. Some relevant filtering includes:

Do they know what job they are applying for? Can they connect their skills to the job?

Have they touched on the main points in our job advertisement and the linked “Become a RSE” page?

Are they interested in teaching, mentoring, and real collaborative projects? Do they know what kind of teaching and mentoring we do?

Is there enough knowledge about the research process?

Any relevant skills about this call’s particular topic (if there is any)?

How do their skills and experience match what our team is currently missing, regardless of the open call?

How similar has their previous work been to “research engineering” (helping the research process) instead of only focusing on academic promotion?

The recruitment team makes several passes over and we discuss how to filter down. We try to get a good variety of candidates.

Sometimes, there is some initial recorded “video interviews”, which provide some initial familiarity in both directions before the actual interviews. We know these are non-interactive and a recording isn’t a conversation so this is harder than an interview, but we consider that when watching them. One shouldn’t worry too much about these, if we do them.

Our actual interviews are not designed to be stressful. We have some prepared questions and go through them in a friendly manner. You have a chance to ask questions to use at the beginning and end (and any other time too). The questions are designed to hear about your experiences and not trick or test you.

We don’t currently ask technical challenge questions. The number of things which you’d need to know is so broad, it’s more important that you can learn things quickly. Since we usually interview relatively advanced people, we can instead look at existing projects they have done and check references, without having to do a technical challenge. This may change depending on the type of candidates we are interviewing, but just like the main interviews we are more interested in how people think, rather than raw knowledge.

In the future, there might be more “meet the team” kind of events.

We want to respond to people as soon as possible, but there’s a simple fact: we don’t want to tell anyone “no” until we are very sure we have an acceptance (we don’t want to tell someone “no” and then hire them later), and we have very many qualified candidates. So there is often an unfortunately long delay in hearing back. We hope that everyone knows within a month, though (and ideally ~2 weeks if all goes well).

We get a relatively large number of applications, with a lot of good people. So far (before 2023), we have been hiring at a relatively high level - researchers with postdoc experience who have been some sort of RSE-like experience with helping others with research (beyond only focusing on making papers for themselves) and technology. Don’t let this discourage you. There are many qualified applications, so if you don’t get selected, that doesn’t mean that you were unqualified. We look at everyone, regardless of their level, for every position. The fit to our particular job is more important that anything else, so keep trying until you get the right fit - it’s just a numbers game.

For reference, this is an older job application text, so that you can see how the things above are integrated. (to be updated with the 2023 version soon)

[ standard header removed ]

Aalto Scientific Computing is looking for a

Research Software Engineer/Supporter

To a permanent, full-time position.

Are you more of a programmer than your researcher colleagues? Are you more of a researcher than commercial developers? Do you fit in both, but have a home in neither? Be a Research Software Engineer with us and find your home. If you are looking for a career path which combines the interesting parts of both fields, this is a good choice.

Aalto Scientific Computing is an elite “special forces” unit of Research IT, providing high-performance computing hardware, management, research support, teaching, and training. Our team consists of a core of PhD staff working with top researchers throughout the university. Our services are used by every school at Aalto University and known throughout Finland and the Nordics. All our work is open-source by default and we take an active part in worldwide projects.

In this position, you will:

Provide software development and consulting as a service, depending on demand from research groups.

Provide one-on-one research support from a software, programming, Linux, data, and infrastructure perspective: short-term projects helping researchers with specific tasks, so that the researchers gain competence to work independently.

As needed and depending on interest, teaching and other research infrastructure support.

Continually learn new skills as part of our team.

Primary qualifications: There are two main tracks, and candidates of diverse backgrounds are encouraged to apply – every candidate will be evaluated according to their own unique experiences.

PhD degree with research experience in some computational field and much knowledge of practical computing strategies for research, or

Software developer or computational scientist with a strong software/open source/Linux background, scientific computing experience, and some experience in research. Masters degree or similar experience.

This particular call emphasizes the ability to work in machine learning and AI environments. The ideal candidate will be working closely with machine learning researchers, and thus a background in machine learning is highly desirable.

Important skills:

Ability to tackle any problem with a researcher’s mindset and a developer’s passion for technology.

Experience or knowledge of the principles of open source software, open science, and software development tools such as version control.

Please see https://scicomp.aalto.fi/rse/become-a-rse/ for more information on what kind of skills we value - or more precisely what you are likely to learn.

What we offer:

You will join the dynamic Aalto Scientific Computing team, where you will learn from some of the best research IT specialists in Finland.

Co-working within top-quality research groups, getting experience in a wide variety of fields and developing an extensive network of scientific contacts. This includes contacts to the Aalto startup scene and community.

A way to be close to the research process while focusing on interesting computational problems and not the publication process.

Our program will offer you a chance to improve your software skills – you are expected to engage in plenty of professional development.

Open Source is our expectation. All (or most) of your code may be open source and may be added to your public CV, depending on the needs of researchers.

Salary will be according to experience, for a recently graduated PhD similar to a postdoc salary. Work hours are flexible, but are expected to sync with the audience being served. Primary workplace is Otaniemi, Espoo (Helsinki region), Finland. Aalto University has a hybrid work policy which allows 60% remote work possibility, and our team takes good advantage of this flexibility.

To apply successfully:

Please include a separate cover letter (~1-2 pages). Please try to write your cover letter avoiding information like name, gender, nationality or other demographic information that is not directly related to why you would be the right person for this position (this includes, for example, a signature on the letter) unless you think it benefits you. This will assist in anonymous recruitment possibilities. The letter should include for example:

Why being a Research Software Engineer is for you,

past research experience, if any

past technical teaching or mentoring experience,

past software development experience (even informal self-learning),

past Linux, command line, or scripting experience,

highlight one (or a few) collaborative projects you have taken part in and your role within it, and

what you bring and what you intend to learn.

A normal professional or academic CV including

a list of your technical and programming tools and level of proficiency (e.g. basic/proficient/expert). This is the time to show the breadth of your experience.

Github link or other public sample code. If not available, whatever is possible to demonstrate past programming experience. Please highlight one or two of your outstanding research software projects.

[ standard footer removed ]

Read more ...