Iyfjky

Question

I am an entry-level programmer, working for just over a year for a company.
I want to refresh my CV and describe what I did during the past year in the project I was involved.

However, I couldn't come up with anything else other than just... 'building the front-end for our application'.

This is pretty much what I did, but I am not a heartless robot, and other tasks were definitely involved, but I don't know how to find out which.

How can I find out what real world skills it is likely for me to have used during the past year?

I can remember, but I am not sure what corresponds to what. There is a difference between the technical aspect of programming and the non-technical one, right? I assume 'Programming' something would not mean I only learned how to program, and that some other fundamental skills were likely involved. — anon, Mar 20 '14 at 16:48
Sorry if my question is unclear but I don't know how to phrase this. Help me out? — anon, Mar 20 '14 at 16:52
What kind of job do you want? Your CV should be tailored to the job description of the job that interests you. Include any relevant activities/experience and discard the rest. — Mar 20 '14 at 17:33

Communityâ™¦ 1 · Accepted Answer · 2017-04-13 12:48:42Z

I like the answer that's here, but had a different perspective.

In user17580's answer, there's things that I think are really good and what I would call "search engine relevant":

what languages did you use or have to learn? In fact, a way to dodge the "I had to write some X, but I couldn't develop in X day in and day out" is to talk about what languages the product used, without necessarily highlighting them on your skills list.

what programming elements, development tools or complex pieces of infrastructure did you have to know?

what processes or best practices did you have to learn to be successful - agile? waterfall? test driven design? Did you pioneer any?
- to some extent, the development process defines some of your deliverables. For example, if you are working in agile, you may be defining stories, or use cases, or epics, but you are likely NOT writing a requirements spec. If you do waterfall, you are likely to have a huge paperweight of a document for your requirements, and you would know if you had contributed to it.

Then there's some quick ways to describe the project itself:

Release cycle - how many per year?

Code size - big, medium, small?

User base - how many? open source? paid service? product with licensing? Some businesses have a defacto model - for example, most social networking is free for the user base.

Where is it in it's lifecycle? Prototype, Beta, mature (multiple versions), legacy? Also - what about your feature - did you prototype it or are you supporting an existing user base?

Then there's team stuff, how you communicate and what your role is within the team, the company and outside of the company is useful resume content - sometimes. For example:
- within the team - what was your scope of responsibility? Was there anything that you were the primary owner of? It doesn't have to be a product or a feature, it may be that you wrote and owned the build script, or the automated test harness.

within the company - were you the delegate for anything? Did you have accountability and ownership for it? Going to a meeting of interested people is not a resume item, but being the guy they send to resolve test issues across a multi-team working group may be worth mentioning - particularly if your effort improved things.

outside the company - did you have any customer consulting or support responsibility? It takes strong people skills to be able to communicate to external parties, so if you had to resolve customer support tickets or you consult on proposals with customers for new work - these are useful points to highlight.

Particular actions - presentations, paper writing, leading a discussion - places where you take the initiative beyond your daily responsibilities is a worthwhile thing to highlight. Note that you probably don't want to highlight work that you do as a normal part of a process that is more or less standard - for example, at the of an agile sprint, it's common to give a demo. I would not put "regularly demo'ed features at spring reviews", but if you have the same demo with a bit more polish to customers as part of a sales pitch, I might say "demonstrated the product as part of our sales process".

Ownership, accountability and productivity

First, I'd say that the focus should be places where you've taken ownership, been accountable and been productive. Note, productive does not equal successful. A great engineering product may fail it the business due to a misunderstanding of the market - that doesn't mean that the engineer did a bad job. However, being the owner of a feature and delivering many weeks late on a 2 week project, is probably NOT the feature you wanted to highlight, unless you can tell this story as a success.

The goal with this is to create enough useful information about your job that the interviewer can have a meaningful conversation with you. "Ah, I see you took responsibility for 3 major features this year, talk to me about the one you found most challenging...". "Oh, I see you were part of a team that embraced agile - what do you think of it? what would you change about the team's process?"

So the big bottom line - don't write about things you don't want to talk about.

NOTE: A huge failure isn't a taboo subject - I have often gotten jobs with enthusiastic discussions of the things I've learned from my mistakes, and tales of how we recovered or succeeded anyway. A good story has to have a good challenge in it. :)

1 Year is 1 Year

Realize that there is only so much you can do in a year. I suspect you can get more than 1 sentence out of the experience, even if it's 1 sentence for the product, one for the role within the team, and one for it's business value - you've got three sentences and that's not so bad. In a year, I really don't expect that someone will have hung the moon, so don't try to get too wordy. Succinct is good.

user17580 712311 · Answer 2 · 2014-03-20 16:59:48Z

Updating your resume can be tricky, especially if you are having difficulty summing up your work in a way hat is attractive to other companies. Here are a few questions you should ask yourself about your work:

Which computer languages were involved (!!)

Which programming elements were used (OOP, AJAX, JSON, SOAP, XML, REST)

How many acronyms can you cover

How many people use this on a daily/monthly basis (traffic)

What kind of problems did it solve.

How many other people worked on it with you

did your work win any awards (was it recognized for anything.)

What is the most positive thing you boss would say about it.

If you still need some advice, you can find a way to get you hands on some other people's resume (put an add in Craigs list or look in other forums for resume postings.) Take a look at what they did and see if that gets you mind going.

Finally, you can always hire someone to help or go by you local unemployment office and get some help there.

Thank you. I don't have a problem with listing the computer languages or programming elements because those are obvious. How would I know if for example I did requirements analysis or functional specifications ( even if not specifically told to do so ) during my work, just because it was part of my work? — Mar 20 '14 at 17:07

Communityâ™¦ 1 · Answer 3 · 2017-04-13 12:52:18Z

Anything you did has been communicated to "outer world" somehow.

Electronic communication is saved / stored somehow, you need to figure which means you have used, how it was archived and check details in these archives.

First thing to check is sentbox in your email tool. If you ever mailed details of what have been done to anyone, it has to be there (unless you have a very bad habit of removing sent mails).

As a programmer, you likely were using issue tracker or version control system.

Find and check details of the tickets you worked with in issue tracker and this will help to refresh your memory (especially if you have a very good habit to add detailed comments when working on the tickets).

Find and check details of the code you committed to VCS and this will help to refresh your memory too (especially if you have a very good habit to write detailed commit messages when submitting your code changes).

If you've got nothing of above, tough luck ^{but see note below} - at least, use this case as an opportunity to learn that it is important to:

Keep emails you sent

Use issue tracker and write detailed comment in tickets

Use VCS and write detailed commit messages

_{Note that even if you failed to keep electronic 'traces" of what you worked with, not all is lost. This is all in your head, really, you only need to learn how to recover it from there - but if this is your case, it would rather be a question for another site - Productivity.SE (where it likely already has been asked and answered).}

Communityâ™¦ 1 · Accepted Answer · 2017-04-13 12:48:42Z

I like the answer that's here, but had a different perspective.

In user17580's answer, there's things that I think are really good and what I would call "search engine relevant":

what languages did you use or have to learn? In fact, a way to dodge the "I had to write some X, but I couldn't develop in X day in and day out" is to talk about what languages the product used, without necessarily highlighting them on your skills list.

what programming elements, development tools or complex pieces of infrastructure did you have to know?

what processes or best practices did you have to learn to be successful - agile? waterfall? test driven design? Did you pioneer any?
- to some extent, the development process defines some of your deliverables. For example, if you are working in agile, you may be defining stories, or use cases, or epics, but you are likely NOT writing a requirements spec. If you do waterfall, you are likely to have a huge paperweight of a document for your requirements, and you would know if you had contributed to it.

Then there's some quick ways to describe the project itself:

Release cycle - how many per year?

Code size - big, medium, small?

User base - how many? open source? paid service? product with licensing? Some businesses have a defacto model - for example, most social networking is free for the user base.

Where is it in it's lifecycle? Prototype, Beta, mature (multiple versions), legacy? Also - what about your feature - did you prototype it or are you supporting an existing user base?

Then there's team stuff, how you communicate and what your role is within the team, the company and outside of the company is useful resume content - sometimes. For example:
- within the team - what was your scope of responsibility? Was there anything that you were the primary owner of? It doesn't have to be a product or a feature, it may be that you wrote and owned the build script, or the automated test harness.

within the company - were you the delegate for anything? Did you have accountability and ownership for it? Going to a meeting of interested people is not a resume item, but being the guy they send to resolve test issues across a multi-team working group may be worth mentioning - particularly if your effort improved things.

outside the company - did you have any customer consulting or support responsibility? It takes strong people skills to be able to communicate to external parties, so if you had to resolve customer support tickets or you consult on proposals with customers for new work - these are useful points to highlight.

Particular actions - presentations, paper writing, leading a discussion - places where you take the initiative beyond your daily responsibilities is a worthwhile thing to highlight. Note that you probably don't want to highlight work that you do as a normal part of a process that is more or less standard - for example, at the of an agile sprint, it's common to give a demo. I would not put "regularly demo'ed features at spring reviews", but if you have the same demo with a bit more polish to customers as part of a sales pitch, I might say "demonstrated the product as part of our sales process".

Ownership, accountability and productivity

First, I'd say that the focus should be places where you've taken ownership, been accountable and been productive. Note, productive does not equal successful. A great engineering product may fail it the business due to a misunderstanding of the market - that doesn't mean that the engineer did a bad job. However, being the owner of a feature and delivering many weeks late on a 2 week project, is probably NOT the feature you wanted to highlight, unless you can tell this story as a success.

The goal with this is to create enough useful information about your job that the interviewer can have a meaningful conversation with you. "Ah, I see you took responsibility for 3 major features this year, talk to me about the one you found most challenging...". "Oh, I see you were part of a team that embraced agile - what do you think of it? what would you change about the team's process?"

So the big bottom line - don't write about things you don't want to talk about.

NOTE: A huge failure isn't a taboo subject - I have often gotten jobs with enthusiastic discussions of the things I've learned from my mistakes, and tales of how we recovered or succeeded anyway. A good story has to have a good challenge in it. :)

1 Year is 1 Year

Realize that there is only so much you can do in a year. I suspect you can get more than 1 sentence out of the experience, even if it's 1 sentence for the product, one for the role within the team, and one for it's business value - you've got three sentences and that's not so bad. In a year, I really don't expect that someone will have hung the moon, so don't try to get too wordy. Succinct is good.

user17580 712311 · Answer 5 · 2014-03-20 16:59:48Z

Updating your resume can be tricky, especially if you are having difficulty summing up your work in a way hat is attractive to other companies. Here are a few questions you should ask yourself about your work:

Which computer languages were involved (!!)

Which programming elements were used (OOP, AJAX, JSON, SOAP, XML, REST)

How many acronyms can you cover

How many people use this on a daily/monthly basis (traffic)

What kind of problems did it solve.

How many other people worked on it with you

did your work win any awards (was it recognized for anything.)

What is the most positive thing you boss would say about it.

If you still need some advice, you can find a way to get you hands on some other people's resume (put an add in Craigs list or look in other forums for resume postings.) Take a look at what they did and see if that gets you mind going.

Finally, you can always hire someone to help or go by you local unemployment office and get some help there.

Thank you. I don't have a problem with listing the computer languages or programming elements because those are obvious. How would I know if for example I did requirements analysis or functional specifications ( even if not specifically told to do so ) during my work, just because it was part of my work? — Mar 20 '14 at 17:07

Communityâ™¦ 1 · Answer 6 · 2017-04-13 12:52:18Z

Anything you did has been communicated to "outer world" somehow.

Electronic communication is saved / stored somehow, you need to figure which means you have used, how it was archived and check details in these archives.

First thing to check is sentbox in your email tool. If you ever mailed details of what have been done to anyone, it has to be there (unless you have a very bad habit of removing sent mails).

As a programmer, you likely were using issue tracker or version control system.

Find and check details of the tickets you worked with in issue tracker and this will help to refresh your memory (especially if you have a very good habit to add detailed comments when working on the tickets).

Find and check details of the code you committed to VCS and this will help to refresh your memory too (especially if you have a very good habit to write detailed commit messages when submitting your code changes).

If you've got nothing of above, tough luck ^{but see note below} - at least, use this case as an opportunity to learn that it is important to:

Keep emails you sent

Use issue tracker and write detailed comment in tickets

Use VCS and write detailed commit messages

_{Note that even if you failed to keep electronic 'traces" of what you worked with, not all is lost. This is all in your head, really, you only need to learn how to recover it from there - but if this is your case, it would rather be a question for another site - Productivity.SE (where it likely already has been asked and answered).}

Search This Blog

Iyfjky

How to know what real world skills I have used during my work that I could list on my CV? [closed]

closed as unclear what you're asking by Jim G., CMW, Jarrod Roberson, Monica Cellioâ™¦, Rhys Mar 21 '14 at 8:37

closed as unclear what you're asking by Jim G., CMW, Jarrod Roberson, Monica Cellioâ™¦, Rhys Mar 21 '14 at 8:37

closed as unclear what you're asking by Jim G., CMW, Jarrod Roberson, Monica Cellioâ™¦, Rhys Mar 21 '14 at 8:37

closed as unclear what you're asking by Jim G., CMW, Jarrod Roberson, Monica Cellioâ™¦, Rhys Mar 21 '14 at 8:37

3 Answers
3

3 Answers
3

3 Answers
3

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

Category

Random preview

How to know what real world skills I have used during my work that I could list on my CV? [closed]

closed as unclear what you're asking by Jim G., CMW, Jarrod Roberson, Monica Cellioâ™¦, Rhys Mar 21 '14 at 8:37

closed as unclear what you're asking by Jim G., CMW, Jarrod Roberson, Monica Cellioâ™¦, Rhys Mar 21 '14 at 8:37

closed as unclear what you're asking by Jim G., CMW, Jarrod Roberson, Monica Cellioâ™¦, Rhys Mar 21 '14 at 8:37

closed as unclear what you're asking by Jim G., CMW, Jarrod Roberson, Monica Cellioâ™¦, Rhys Mar 21 '14 at 8:37

3 Answers 3

3 Answers 3

3 Answers 3

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

3 Answers
3

3 Answers
3

3 Answers
3

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor