1

I am working alone on a software development project.

I am employed for a year in an academic institution to complete this project. I am the only person working on this project.

My tasks include engineering the product as well as taking design/architecture related decisions.

How can I politely write that in a resume, emphasizing the autonomous part of the task ?

3
  • Is this an actual job?
    – Kilisi
    Commented Mar 24, 2020 at 11:14
  • 1
    I am employed for a year in an academic institution to complete this project. I am the only person working on this project.
    – eliott42
    Commented Mar 24, 2020 at 11:18
  • @TonyK Sorry, I started editing without re-reading. Thanks for the note, reverted. Commented Mar 24, 2020 at 14:01

3 Answers 3

4

Think this from another angle - instead of highlighting the fact that you were the only resource, focus on the facts that what all are the responsibilities you handled during that assignment(s).

Whether you worked as the only resource or not doe not tell much about your achievements or capacity - but mentioning the responsibilities handled by you while working as the only resource, like

  • Design
  • Review
  • Development
  • Testing
  • Delivery and
  • Support / Maintenance

will speak on your behalf. Consider highlighting these points in the resume.

3

I think you've got the wrong mindset here. Emphasizing "I did this by myself!" is actually a negative. Likewise, the fact that you view yourself as "Working Alone" is actually a problem as well.

Let me try to illustrate that by contrasting your experience with one I had a few years back where I was also the sole developer and sole architect, creating an application for rubber mixing in a factory.

I was never working alone. I was talking with the business area at least twice a week, showing them what I was working on, brainstorming possible improvements, getting their take on proof-of-concept work, demoing new features, etc. I would talk with other developers to get their opinion on code or techniques. I would talk with the systems people to ask what the impact of doing certain things would be. Etc. Etc.

You shouldn't be working alone. First off, you're not generating the requirements, are you? Presumably the institution that's hiring you has the requirements of what they're paying you to develop. Okay... so why aren't you working alongside them? Why aren't you meeting with them at least once a week to touch base and show what you're working on - and make sure you're on the right path? You want a fast failure cycle... but if you're never talking with the people that you're developing for, you won't know if you're failing until you finally show off your final product. Second, you should be using other people's expertise. I can guarantee you that you're not the subject matter expert over every single aspect of what you're working on. Software Dev has gotten too expansive for anyone to be the expert in everything anymore.

Which brings me to the final point: Working Alone isn't something to brag about on a Resume. Seriously, being able to develop code is just one piece of the puzzle. Being able to collaborate and work constructively alongside others is an even bigger piece. You don't want to brag "Yeah, this project I did? I didn't have to work with anyone else!"

By all means, mention that there were project roles where you were the sole member - you were the sole developer, you were the sole architect... but treating this as "I worked alone" isn't the direction you want to go with here.

0

How can I politely write that in a resume, emphasizing the autonomous part of the task ?

Writing anything in the resume only gets you in the door. Make sure you know exactly what and why were you doing. The project was assigned by someone with bigger problem that testing and engineering. Thus, you didn't work "alone".

I have been in similar situation. To start, you can write something like:

Designed, wrote, and tested software to [find antibodies], part of [curing cancer] project supported by $1M grant from [NIH].

Find a way to put your work in context, and get ready to discuss the project in the interview.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .