Mixing
How to select an applicant with good documentation skills
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
6
down vote
favorite
We are a local outsourcing company and currently hiring for a technical position (Linux/Network engineer) - however our main objective now is to find someone not only able in the Linux/Networking field but also - and mainly - keen to create documentation about everything they learn while getting up to speed with our clients and keep the documentation current.
We used to have one such guy in the past - he kept taking notes and creating wiki pages about everything important. Sadly he left us some time ago and the team's docs quality has gone downhill very quickly. Our engineers can certainly be pushed into writing some docs but they only do enough to get the managers off their backs, but not nearly as a useful resource. I accept it - some people are born writers some are not (and I'm one of the latter group, I admit).
What interview questions would you use to identify whether someone is that kind of documentation freak that we now need?
interviewing hiring-process documentation
asked Mar 18 '15 at 23:12
MLu
1312
 |Â
show 2 more comments
up vote
6
down vote
favorite
We are a local outsourcing company and currently hiring for a technical position (Linux/Network engineer) - however our main objective now is to find someone not only able in the Linux/Networking field but also - and mainly - keen to create documentation about everything they learn while getting up to speed with our clients and keep the documentation current.
We used to have one such guy in the past - he kept taking notes and creating wiki pages about everything important. Sadly he left us some time ago and the team's docs quality has gone downhill very quickly. Our engineers can certainly be pushed into writing some docs but they only do enough to get the managers off their backs, but not nearly as a useful resource. I accept it - some people are born writers some are not (and I'm one of the latter group, I admit).
What interview questions would you use to identify whether someone is that kind of documentation freak that we now need?
interviewing hiring-process documentation
asked Mar 18 '15 at 23:12
MLu
1312
3
If you want to know if they are a documentation freak ask them "How do you feel about writing documentation". If they like writing documentation they will tell you.
– paparazzo
Mar 19 '15 at 13:13
The documentation role is more that of a business / systems analyst than of an engineer. Perhaps you should recruit for a combination position.
– Wesley Long
Mar 19 '15 at 16:12
@Wesley - If you aren't willing to do the documentation then you really shouldn't be calling yourself an engineer. Developer maybe, but certainly not engineer which implies a bit higher degree of professionalism.
– Dunk
Mar 19 '15 at 20:22
@Dunk - Respectfully, I disagree. An engineer's role is to develop solutions, and to document their own work. It is not their role to document the work and systems of others. That is what business analysts and technical writers do. That's the reason these positions exist.
– Wesley Long
Mar 19 '15 at 20:23
@Wesley - As long as you agree that an engineer's role includes documenting at least their own work then I'm ok with that.
– Dunk
Mar 19 '15 at 20:59
 |Â
show 2 more comments
up vote
6
down vote
favorite
up vote
6
down vote
favorite
We are a local outsourcing company and currently hiring for a technical position (Linux/Network engineer) - however our main objective now is to find someone not only able in the Linux/Networking field but also - and mainly - keen to create documentation about everything they learn while getting up to speed with our clients and keep the documentation current.
We used to have one such guy in the past - he kept taking notes and creating wiki pages about everything important. Sadly he left us some time ago and the team's docs quality has gone downhill very quickly. Our engineers can certainly be pushed into writing some docs but they only do enough to get the managers off their backs, but not nearly as a useful resource. I accept it - some people are born writers some are not (and I'm one of the latter group, I admit).
What interview questions would you use to identify whether someone is that kind of documentation freak that we now need?
interviewing hiring-process documentation
asked Mar 18 '15 at 23:12
MLu
1312
We are a local outsourcing company and currently hiring for a technical position (Linux/Network engineer) - however our main objective now is to find someone not only able in the Linux/Networking field but also - and mainly - keen to create documentation about everything they learn while getting up to speed with our clients and keep the documentation current.
We used to have one such guy in the past - he kept taking notes and creating wiki pages about everything important. Sadly he left us some time ago and the team's docs quality has gone downhill very quickly. Our engineers can certainly be pushed into writing some docs but they only do enough to get the managers off their backs, but not nearly as a useful resource. I accept it - some people are born writers some are not (and I'm one of the latter group, I admit).
What interview questions would you use to identify whether someone is that kind of documentation freak that we now need?
interviewing hiring-process documentation
asked Mar 18 '15 at 23:12
MLu
1312
asked Mar 18 '15 at 23:12
MLu
1312
asked Mar 18 '15 at 23:12
MLu
1312
asked Mar 18 '15 at 23:12
MLu
1312
1312
3
If you want to know if they are a documentation freak ask them "How do you feel about writing documentation". If they like writing documentation they will tell you.
– paparazzo
Mar 19 '15 at 13:13
The documentation role is more that of a business / systems analyst than of an engineer. Perhaps you should recruit for a combination position.
– Wesley Long
Mar 19 '15 at 16:12
@Wesley - If you aren't willing to do the documentation then you really shouldn't be calling yourself an engineer. Developer maybe, but certainly not engineer which implies a bit higher degree of professionalism.
– Dunk
Mar 19 '15 at 20:22
@Dunk - Respectfully, I disagree. An engineer's role is to develop solutions, and to document their own work. It is not their role to document the work and systems of others. That is what business analysts and technical writers do. That's the reason these positions exist.
– Wesley Long
Mar 19 '15 at 20:23
@Wesley - As long as you agree that an engineer's role includes documenting at least their own work then I'm ok with that.
– Dunk
Mar 19 '15 at 20:59
 |Â
show 2 more comments
3
If you want to know if they are a documentation freak ask them "How do you feel about writing documentation". If they like writing documentation they will tell you.
– paparazzo
Mar 19 '15 at 13:13
The documentation role is more that of a business / systems analyst than of an engineer. Perhaps you should recruit for a combination position.
– Wesley Long
Mar 19 '15 at 16:12
@Wesley - If you aren't willing to do the documentation then you really shouldn't be calling yourself an engineer. Developer maybe, but certainly not engineer which implies a bit higher degree of professionalism.
– Dunk
Mar 19 '15 at 20:22
@Dunk - Respectfully, I disagree. An engineer's role is to develop solutions, and to document their own work. It is not their role to document the work and systems of others. That is what business analysts and technical writers do. That's the reason these positions exist.
– Wesley Long
Mar 19 '15 at 20:23
@Wesley - As long as you agree that an engineer's role includes documenting at least their own work then I'm ok with that.
– Dunk
Mar 19 '15 at 20:59
3
3
If you want to know if they are a documentation freak ask them "How do you feel about writing documentation". If they like writing documentation they will tell you.
– paparazzo
Mar 19 '15 at 13:13
If you want to know if they are a documentation freak ask them "How do you feel about writing documentation". If they like writing documentation they will tell you.
– paparazzo
Mar 19 '15 at 13:13
The documentation role is more that of a business / systems analyst than of an engineer. Perhaps you should recruit for a combination position.
– Wesley Long
Mar 19 '15 at 16:12
The documentation role is more that of a business / systems analyst than of an engineer. Perhaps you should recruit for a combination position.
– Wesley Long
Mar 19 '15 at 16:12
@Wesley - If you aren't willing to do the documentation then you really shouldn't be calling yourself an engineer. Developer maybe, but certainly not engineer which implies a bit higher degree of professionalism.
– Dunk
Mar 19 '15 at 20:22
@Wesley - If you aren't willing to do the documentation then you really shouldn't be calling yourself an engineer. Developer maybe, but certainly not engineer which implies a bit higher degree of professionalism.
– Dunk
Mar 19 '15 at 20:22
@Dunk - Respectfully, I disagree. An engineer's role is to develop solutions, and to document their own work. It is not their role to document the work and systems of others. That is what business analysts and technical writers do. That's the reason these positions exist.
– Wesley Long
Mar 19 '15 at 20:23
@Dunk - Respectfully, I disagree. An engineer's role is to develop solutions, and to document their own work. It is not their role to document the work and systems of others. That is what business analysts and technical writers do. That's the reason these positions exist.
– Wesley Long
Mar 19 '15 at 20:23
@Wesley - As long as you agree that an engineer's role includes documenting at least their own work then I'm ok with that.
– Dunk
Mar 19 '15 at 20:59
@Wesley - As long as you agree that an engineer's role includes documenting at least their own work then I'm ok with that.
– Dunk
Mar 19 '15 at 20:59
 |Â
show 2 more comments
3 Answers
3
active
oldest
votes
up vote
6
down vote
If you're looking for interview questions, there are basically two:
- Do you have any previous job experience where you had to write a lot of documentation?
- Are you willing to write documentation?
Other than this, you may want to get some writing examples or rely on the correspondence you get during the interview process: CV, cover letter, email.
Personally, I think your approach is only a part of an over-all solution. Documentation becomes important when it is evaluated and relied upon. Someone should be doing a periodic review of the documents. The objective should be whether or not the documents were created but are they useful to anyone else. When I create instructions for a particular task, I observe someone reading and executing the instructions and ask that they sort of "think aloud" so I can tell if I've given enough information. I take notes if there are any hesitations or questions.
Determine the purpose of the documentation and have an effective way to know if they've met that objective. Writing takes practice along with getting valuable feedback. When the consumers of the documents (or someone to simulate a future user), indicate which parts don't make sense, the writer soon learns how to communicate more effectively.
It would be sad for you to hire someone who is very good at writing documentation but over time they discover that you neglect, fail to acknowledge and give them no credit doing it. Also, they need to know that you understand the time commitment and won't pressure them to complete other tasks with unrealistic time limits and then punish them for not writing adequate documentation.
Documentation becomes important when it is evaluated and relied upon. This is definitively the most important part, lot of us hate to do documentation and generally the argument is always the same "NOBODY AIN'T GONNA READ IT/IT WON'T BE UPDATED". Which is... still too often true ?
– Walfrat
Feb 3 '17 at 12:25
1
Question 3: "Do you have any examples of your past writing you can share with us, and can you discuss how you approached those?"
– keshlam
Feb 5 '17 at 5:16
@Walfrat - Especially when someone agrees to a tight deadline it isn't communicated that it will get done, but at a lower quality with no documentation or testing.
– user8365
Feb 8 '17 at 13:24
suggest improvements |Â
up vote
5
down vote
To all the pompous people who think that documentation is somehow not a useful thing or below their dignity, please try working with code/systems that are undocumented and/or not self documenting. Sure, you can use your brilliant engineering mind to figure it all out. But, you'll lose a lot of time. You might even make mistakes and then start over. So, please spare us the "developers should not make documentation" slogans.
EDIT - Refer end of answer.
I am not a professional & have never hired anyone. But, here are a few suggestions for how you could judge a person's interest in documentation.
1 - Ask him how he feels about writing documentation.
Personal example - I absolutely love it. Actually, I love teaching and simplifying things for others. Maybe that is where my love for documentation comes from. I like to keep it short, but informative.
2 - Ask him about his frustrations with badly documented systems.
Personal example - It took me 2 months to understand something that could have been understood in 1-2 weeks.
3 - Ask him about how he improved documentation in his previous company or how his documentation helped people.
Personal example - People often used to ask me how to use some features of internal apps. I saw too many requests of the same kind. So I created detailed documentation for it. Next time, I just shared the links to the docs. I never got any further requests after most of those requests. Maybe I did a good job.
4 - Ask him to describe a few things and see how he does it.
Notes - Consider that an audience does not know what a car is. I know people who'd begin describing a car in terms of engines, combustion, thermodynamics etc. when they should really be talking about 4 wheels, steering and moving from place A to B.
You could ask him about things that you know about better than him. Eg. What is a test automation framework and what does it really do ?
5 - Ask him to write a manual for any daily object.
Notes - Maybe your soda vending machine in your office ? See the kinds of questions he asks when documenting the object. If he does not ask the right questions, then he might not get the right info. If that happens, then his docs will not be effective.
6 - Ask him if he wrote blogs, github docs or self documenting code.
PS - Hope this helps. I guess I just showed some of my love for documentation. Off to punching out some code !
EDITS -
To clarify, by "documentation", I don't mean long manuals and such. It can be short too, depending on your audience. If someone wants more details (like interns), then they can talk to the developer. Documentation can have different forms. In software development, that can be self descriptive code and comments.
answered Feb 3 '17 at 0:48
SenseiTester
7014
Agree with what Jeff said - give good documenters credit for their work. Also give them incentives. You could go cheap and let them go, only to realize how valuable they were, when you have to waste time and money to figure out poorly documented things.
– SenseiTester
Feb 3 '17 at 0:57
spare us the "developers should not make documentation", well on ther other hand, you're often ask to write "a documentation" without a clear objective, and I won't talk about all the times I have to write a installation/exploitation documentation which belong to the system area (in which I'm not supposed to be competent since there are the system guys for that). And the thing I hate the more is when I have detail every single step (click on next, open the command by typing "cmd" in the startup menu,...) so even a five years old kid should be able to do it.
– Walfrat
Feb 3 '17 at 12:32
I mean, do aircraft engineer write their documentation so even a five years old kid can build a plane ? Why should we then ? Just get a decent System administrator.
– Walfrat
Feb 3 '17 at 12:33
@Walfrat - When the objective is not clear, I would say so to my manager and document whatever little we know, only if that would be helpful for us. I would keep the docs very minimum or even zero initially. I can add more details when the objectives become clearer. Maybe even mention why one design/solution was abandoned in favor of another. (So that anyone newcomer who thinks about going to the old design will know not to).
– SenseiTester
Feb 3 '17 at 20:51
As for the kiddie level of documentation, here is what I have to say. If your audience is a layperson/intern, then the docs have to be at their level. If your audience is customers/end users, then maybe a product manager/business analyst can do that kiddie level documentation, not the developer. I never said that the developer has to create customer manuals and everything, if thats what you meant. If there is no product manager (maybe in startup) then guess who has to multitask ? The developer or QA.
– SenseiTester
Feb 3 '17 at 20:54
 |Â
show 3 more comments
up vote
-2
down vote
I myself am in a situation where I have to demonstrate that I know how to document:
I have answered a few questions on stackoverflow.com I believe that the way I answered these questions is a good reflection on how well I can write documentation.
I run a couple of blogs. While they need an update, I believe that they expose the quality of my technical writing pretty well.
If it's doable, ask to see current writing samples.
Back in December 1999,I successfully interviewed for a position as a marketing analyst for a high tech marketing consulting company. The core of the interview was a one-hour writing test on any technical subject. The interviewer ripped out of my hand within 30 minutes - and almost gave me a paper cut - he'd seen enough, and I got my phone call the next day :)
If writing ability is important to you, I expect that you'd have filtered out those who sent you poorly written cover letters and resumes. A poorly written, poorly organized Linkedin profile is a no-no :)
answered Mar 19 '15 at 10:22
Vietnhi Phuvan
68.9k7118254
Paper? Nobody wants to see my handwriting. My writing, I hope, is another matter.
– keshlam
Feb 3 '17 at 1:12
suggest improvements |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
If you're looking for interview questions, there are basically two:
- Do you have any previous job experience where you had to write a lot of documentation?
- Are you willing to write documentation?
Other than this, you may want to get some writing examples or rely on the correspondence you get during the interview process: CV, cover letter, email.
Personally, I think your approach is only a part of an over-all solution. Documentation becomes important when it is evaluated and relied upon. Someone should be doing a periodic review of the documents. The objective should be whether or not the documents were created but are they useful to anyone else. When I create instructions for a particular task, I observe someone reading and executing the instructions and ask that they sort of "think aloud" so I can tell if I've given enough information. I take notes if there are any hesitations or questions.
Determine the purpose of the documentation and have an effective way to know if they've met that objective. Writing takes practice along with getting valuable feedback. When the consumers of the documents (or someone to simulate a future user), indicate which parts don't make sense, the writer soon learns how to communicate more effectively.
It would be sad for you to hire someone who is very good at writing documentation but over time they discover that you neglect, fail to acknowledge and give them no credit doing it. Also, they need to know that you understand the time commitment and won't pressure them to complete other tasks with unrealistic time limits and then punish them for not writing adequate documentation.
Documentation becomes important when it is evaluated and relied upon. This is definitively the most important part, lot of us hate to do documentation and generally the argument is always the same "NOBODY AIN'T GONNA READ IT/IT WON'T BE UPDATED". Which is... still too often true ?
– Walfrat
Feb 3 '17 at 12:25
1
Question 3: "Do you have any examples of your past writing you can share with us, and can you discuss how you approached those?"
– keshlam
Feb 5 '17 at 5:16
@Walfrat - Especially when someone agrees to a tight deadline it isn't communicated that it will get done, but at a lower quality with no documentation or testing.
– user8365
Feb 8 '17 at 13:24
suggest improvements |Â
up vote
6
down vote
If you're looking for interview questions, there are basically two:
- Do you have any previous job experience where you had to write a lot of documentation?
- Are you willing to write documentation?
Other than this, you may want to get some writing examples or rely on the correspondence you get during the interview process: CV, cover letter, email.
Personally, I think your approach is only a part of an over-all solution. Documentation becomes important when it is evaluated and relied upon. Someone should be doing a periodic review of the documents. The objective should be whether or not the documents were created but are they useful to anyone else. When I create instructions for a particular task, I observe someone reading and executing the instructions and ask that they sort of "think aloud" so I can tell if I've given enough information. I take notes if there are any hesitations or questions.
Determine the purpose of the documentation and have an effective way to know if they've met that objective. Writing takes practice along with getting valuable feedback. When the consumers of the documents (or someone to simulate a future user), indicate which parts don't make sense, the writer soon learns how to communicate more effectively.
It would be sad for you to hire someone who is very good at writing documentation but over time they discover that you neglect, fail to acknowledge and give them no credit doing it. Also, they need to know that you understand the time commitment and won't pressure them to complete other tasks with unrealistic time limits and then punish them for not writing adequate documentation.
Documentation becomes important when it is evaluated and relied upon. This is definitively the most important part, lot of us hate to do documentation and generally the argument is always the same "NOBODY AIN'T GONNA READ IT/IT WON'T BE UPDATED". Which is... still too often true ?
– Walfrat
Feb 3 '17 at 12:25
1
Question 3: "Do you have any examples of your past writing you can share with us, and can you discuss how you approached those?"
– keshlam
Feb 5 '17 at 5:16
@Walfrat - Especially when someone agrees to a tight deadline it isn't communicated that it will get done, but at a lower quality with no documentation or testing.
– user8365
Feb 8 '17 at 13:24
suggest improvements |Â
up vote
6
down vote
up vote
6
down vote
If you're looking for interview questions, there are basically two:
- Do you have any previous job experience where you had to write a lot of documentation?
- Are you willing to write documentation?
Other than this, you may want to get some writing examples or rely on the correspondence you get during the interview process: CV, cover letter, email.
Personally, I think your approach is only a part of an over-all solution. Documentation becomes important when it is evaluated and relied upon. Someone should be doing a periodic review of the documents. The objective should be whether or not the documents were created but are they useful to anyone else. When I create instructions for a particular task, I observe someone reading and executing the instructions and ask that they sort of "think aloud" so I can tell if I've given enough information. I take notes if there are any hesitations or questions.
Determine the purpose of the documentation and have an effective way to know if they've met that objective. Writing takes practice along with getting valuable feedback. When the consumers of the documents (or someone to simulate a future user), indicate which parts don't make sense, the writer soon learns how to communicate more effectively.
It would be sad for you to hire someone who is very good at writing documentation but over time they discover that you neglect, fail to acknowledge and give them no credit doing it. Also, they need to know that you understand the time commitment and won't pressure them to complete other tasks with unrealistic time limits and then punish them for not writing adequate documentation.
If you're looking for interview questions, there are basically two:
- Do you have any previous job experience where you had to write a lot of documentation?
- Are you willing to write documentation?
Other than this, you may want to get some writing examples or rely on the correspondence you get during the interview process: CV, cover letter, email.
Personally, I think your approach is only a part of an over-all solution. Documentation becomes important when it is evaluated and relied upon. Someone should be doing a periodic review of the documents. The objective should be whether or not the documents were created but are they useful to anyone else. When I create instructions for a particular task, I observe someone reading and executing the instructions and ask that they sort of "think aloud" so I can tell if I've given enough information. I take notes if there are any hesitations or questions.
Determine the purpose of the documentation and have an effective way to know if they've met that objective. Writing takes practice along with getting valuable feedback. When the consumers of the documents (or someone to simulate a future user), indicate which parts don't make sense, the writer soon learns how to communicate more effectively.
It would be sad for you to hire someone who is very good at writing documentation but over time they discover that you neglect, fail to acknowledge and give them no credit doing it. Also, they need to know that you understand the time commitment and won't pressure them to complete other tasks with unrealistic time limits and then punish them for not writing adequate documentation.
answered Mar 19 '15 at 0:38
user8365
Documentation becomes important when it is evaluated and relied upon. This is definitively the most important part, lot of us hate to do documentation and generally the argument is always the same "NOBODY AIN'T GONNA READ IT/IT WON'T BE UPDATED". Which is... still too often true ?
– Walfrat
Feb 3 '17 at 12:25
1
Question 3: "Do you have any examples of your past writing you can share with us, and can you discuss how you approached those?"
– keshlam
Feb 5 '17 at 5:16
@Walfrat - Especially when someone agrees to a tight deadline it isn't communicated that it will get done, but at a lower quality with no documentation or testing.
– user8365
Feb 8 '17 at 13:24
suggest improvements |Â
Documentation becomes important when it is evaluated and relied upon. This is definitively the most important part, lot of us hate to do documentation and generally the argument is always the same "NOBODY AIN'T GONNA READ IT/IT WON'T BE UPDATED". Which is... still too often true ?
– Walfrat
Feb 3 '17 at 12:25
1
Question 3: "Do you have any examples of your past writing you can share with us, and can you discuss how you approached those?"
– keshlam
Feb 5 '17 at 5:16
@Walfrat - Especially when someone agrees to a tight deadline it isn't communicated that it will get done, but at a lower quality with no documentation or testing.
– user8365
Feb 8 '17 at 13:24
Documentation becomes important when it is evaluated and relied upon. This is definitively the most important part, lot of us hate to do documentation and generally the argument is always the same "NOBODY AIN'T GONNA READ IT/IT WON'T BE UPDATED". Which is... still too often true ?– Walfrat
Feb 3 '17 at 12:25
Documentation becomes important when it is evaluated and relied upon. This is definitively the most important part, lot of us hate to do documentation and generally the argument is always the same "NOBODY AIN'T GONNA READ IT/IT WON'T BE UPDATED". Which is... still too often true ?– Walfrat
Feb 3 '17 at 12:25
1
1
Question 3: "Do you have any examples of your past writing you can share with us, and can you discuss how you approached those?"
– keshlam
Feb 5 '17 at 5:16
Question 3: "Do you have any examples of your past writing you can share with us, and can you discuss how you approached those?"
– keshlam
Feb 5 '17 at 5:16
@Walfrat - Especially when someone agrees to a tight deadline it isn't communicated that it will get done, but at a lower quality with no documentation or testing.
– user8365
Feb 8 '17 at 13:24
@Walfrat - Especially when someone agrees to a tight deadline it isn't communicated that it will get done, but at a lower quality with no documentation or testing.
– user8365
Feb 8 '17 at 13:24
suggest improvements |Â
up vote
5
down vote
To all the pompous people who think that documentation is somehow not a useful thing or below their dignity, please try working with code/systems that are undocumented and/or not self documenting. Sure, you can use your brilliant engineering mind to figure it all out. But, you'll lose a lot of time. You might even make mistakes and then start over. So, please spare us the "developers should not make documentation" slogans.
EDIT - Refer end of answer.
I am not a professional & have never hired anyone. But, here are a few suggestions for how you could judge a person's interest in documentation.
1 - Ask him how he feels about writing documentation.
Personal example - I absolutely love it. Actually, I love teaching and simplifying things for others. Maybe that is where my love for documentation comes from. I like to keep it short, but informative.
2 - Ask him about his frustrations with badly documented systems.
Personal example - It took me 2 months to understand something that could have been understood in 1-2 weeks.
3 - Ask him about how he improved documentation in his previous company or how his documentation helped people.
Personal example - People often used to ask me how to use some features of internal apps. I saw too many requests of the same kind. So I created detailed documentation for it. Next time, I just shared the links to the docs. I never got any further requests after most of those requests. Maybe I did a good job.
4 - Ask him to describe a few things and see how he does it.
Notes - Consider that an audience does not know what a car is. I know people who'd begin describing a car in terms of engines, combustion, thermodynamics etc. when they should really be talking about 4 wheels, steering and moving from place A to B.
You could ask him about things that you know about better than him. Eg. What is a test automation framework and what does it really do ?
5 - Ask him to write a manual for any daily object.
Notes - Maybe your soda vending machine in your office ? See the kinds of questions he asks when documenting the object. If he does not ask the right questions, then he might not get the right info. If that happens, then his docs will not be effective.
6 - Ask him if he wrote blogs, github docs or self documenting code.
PS - Hope this helps. I guess I just showed some of my love for documentation. Off to punching out some code !
EDITS -
To clarify, by "documentation", I don't mean long manuals and such. It can be short too, depending on your audience. If someone wants more details (like interns), then they can talk to the developer. Documentation can have different forms. In software development, that can be self descriptive code and comments.
answered Feb 3 '17 at 0:48
SenseiTester
7014
Agree with what Jeff said - give good documenters credit for their work. Also give them incentives. You could go cheap and let them go, only to realize how valuable they were, when you have to waste time and money to figure out poorly documented things.
– SenseiTester
Feb 3 '17 at 0:57
spare us the "developers should not make documentation", well on ther other hand, you're often ask to write "a documentation" without a clear objective, and I won't talk about all the times I have to write a installation/exploitation documentation which belong to the system area (in which I'm not supposed to be competent since there are the system guys for that). And the thing I hate the more is when I have detail every single step (click on next, open the command by typing "cmd" in the startup menu,...) so even a five years old kid should be able to do it.
– Walfrat
Feb 3 '17 at 12:32
I mean, do aircraft engineer write their documentation so even a five years old kid can build a plane ? Why should we then ? Just get a decent System administrator.
– Walfrat
Feb 3 '17 at 12:33
@Walfrat - When the objective is not clear, I would say so to my manager and document whatever little we know, only if that would be helpful for us. I would keep the docs very minimum or even zero initially. I can add more details when the objectives become clearer. Maybe even mention why one design/solution was abandoned in favor of another. (So that anyone newcomer who thinks about going to the old design will know not to).
– SenseiTester
Feb 3 '17 at 20:51
As for the kiddie level of documentation, here is what I have to say. If your audience is a layperson/intern, then the docs have to be at their level. If your audience is customers/end users, then maybe a product manager/business analyst can do that kiddie level documentation, not the developer. I never said that the developer has to create customer manuals and everything, if thats what you meant. If there is no product manager (maybe in startup) then guess who has to multitask ? The developer or QA.
– SenseiTester
Feb 3 '17 at 20:54
 |Â
show 3 more comments
up vote
5
down vote
To all the pompous people who think that documentation is somehow not a useful thing or below their dignity, please try working with code/systems that are undocumented and/or not self documenting. Sure, you can use your brilliant engineering mind to figure it all out. But, you'll lose a lot of time. You might even make mistakes and then start over. So, please spare us the "developers should not make documentation" slogans.
EDIT - Refer end of answer.
I am not a professional & have never hired anyone. But, here are a few suggestions for how you could judge a person's interest in documentation.
1 - Ask him how he feels about writing documentation.
Personal example - I absolutely love it. Actually, I love teaching and simplifying things for others. Maybe that is where my love for documentation comes from. I like to keep it short, but informative.
2 - Ask him about his frustrations with badly documented systems.
Personal example - It took me 2 months to understand something that could have been understood in 1-2 weeks.
3 - Ask him about how he improved documentation in his previous company or how his documentation helped people.
Personal example - People often used to ask me how to use some features of internal apps. I saw too many requests of the same kind. So I created detailed documentation for it. Next time, I just shared the links to the docs. I never got any further requests after most of those requests. Maybe I did a good job.
4 - Ask him to describe a few things and see how he does it.
Notes - Consider that an audience does not know what a car is. I know people who'd begin describing a car in terms of engines, combustion, thermodynamics etc. when they should really be talking about 4 wheels, steering and moving from place A to B.
You could ask him about things that you know about better than him. Eg. What is a test automation framework and what does it really do ?
5 - Ask him to write a manual for any daily object.
Notes - Maybe your soda vending machine in your office ? See the kinds of questions he asks when documenting the object. If he does not ask the right questions, then he might not get the right info. If that happens, then his docs will not be effective.
6 - Ask him if he wrote blogs, github docs or self documenting code.
PS - Hope this helps. I guess I just showed some of my love for documentation. Off to punching out some code !
EDITS -
To clarify, by "documentation", I don't mean long manuals and such. It can be short too, depending on your audience. If someone wants more details (like interns), then they can talk to the developer. Documentation can have different forms. In software development, that can be self descriptive code and comments.
answered Feb 3 '17 at 0:48
SenseiTester
7014
Agree with what Jeff said - give good documenters credit for their work. Also give them incentives. You could go cheap and let them go, only to realize how valuable they were, when you have to waste time and money to figure out poorly documented things.
– SenseiTester
Feb 3 '17 at 0:57
spare us the "developers should not make documentation", well on ther other hand, you're often ask to write "a documentation" without a clear objective, and I won't talk about all the times I have to write a installation/exploitation documentation which belong to the system area (in which I'm not supposed to be competent since there are the system guys for that). And the thing I hate the more is when I have detail every single step (click on next, open the command by typing "cmd" in the startup menu,...) so even a five years old kid should be able to do it.
– Walfrat
Feb 3 '17 at 12:32
I mean, do aircraft engineer write their documentation so even a five years old kid can build a plane ? Why should we then ? Just get a decent System administrator.
– Walfrat
Feb 3 '17 at 12:33
@Walfrat - When the objective is not clear, I would say so to my manager and document whatever little we know, only if that would be helpful for us. I would keep the docs very minimum or even zero initially. I can add more details when the objectives become clearer. Maybe even mention why one design/solution was abandoned in favor of another. (So that anyone newcomer who thinks about going to the old design will know not to).
– SenseiTester
Feb 3 '17 at 20:51
As for the kiddie level of documentation, here is what I have to say. If your audience is a layperson/intern, then the docs have to be at their level. If your audience is customers/end users, then maybe a product manager/business analyst can do that kiddie level documentation, not the developer. I never said that the developer has to create customer manuals and everything, if thats what you meant. If there is no product manager (maybe in startup) then guess who has to multitask ? The developer or QA.
– SenseiTester
Feb 3 '17 at 20:54
 |Â
show 3 more comments
up vote
5
down vote
up vote
5
down vote
To all the pompous people who think that documentation is somehow not a useful thing or below their dignity, please try working with code/systems that are undocumented and/or not self documenting. Sure, you can use your brilliant engineering mind to figure it all out. But, you'll lose a lot of time. You might even make mistakes and then start over. So, please spare us the "developers should not make documentation" slogans.
EDIT - Refer end of answer.
I am not a professional & have never hired anyone. But, here are a few suggestions for how you could judge a person's interest in documentation.
1 - Ask him how he feels about writing documentation.
Personal example - I absolutely love it. Actually, I love teaching and simplifying things for others. Maybe that is where my love for documentation comes from. I like to keep it short, but informative.
2 - Ask him about his frustrations with badly documented systems.
Personal example - It took me 2 months to understand something that could have been understood in 1-2 weeks.
3 - Ask him about how he improved documentation in his previous company or how his documentation helped people.
Personal example - People often used to ask me how to use some features of internal apps. I saw too many requests of the same kind. So I created detailed documentation for it. Next time, I just shared the links to the docs. I never got any further requests after most of those requests. Maybe I did a good job.
4 - Ask him to describe a few things and see how he does it.
Notes - Consider that an audience does not know what a car is. I know people who'd begin describing a car in terms of engines, combustion, thermodynamics etc. when they should really be talking about 4 wheels, steering and moving from place A to B.
You could ask him about things that you know about better than him. Eg. What is a test automation framework and what does it really do ?
5 - Ask him to write a manual for any daily object.
Notes - Maybe your soda vending machine in your office ? See the kinds of questions he asks when documenting the object. If he does not ask the right questions, then he might not get the right info. If that happens, then his docs will not be effective.
6 - Ask him if he wrote blogs, github docs or self documenting code.
PS - Hope this helps. I guess I just showed some of my love for documentation. Off to punching out some code !
EDITS -
To clarify, by "documentation", I don't mean long manuals and such. It can be short too, depending on your audience. If someone wants more details (like interns), then they can talk to the developer. Documentation can have different forms. In software development, that can be self descriptive code and comments.
answered Feb 3 '17 at 0:48
SenseiTester
7014
To all the pompous people who think that documentation is somehow not a useful thing or below their dignity, please try working with code/systems that are undocumented and/or not self documenting. Sure, you can use your brilliant engineering mind to figure it all out. But, you'll lose a lot of time. You might even make mistakes and then start over. So, please spare us the "developers should not make documentation" slogans.
EDIT - Refer end of answer.
I am not a professional & have never hired anyone. But, here are a few suggestions for how you could judge a person's interest in documentation.
1 - Ask him how he feels about writing documentation.
Personal example - I absolutely love it. Actually, I love teaching and simplifying things for others. Maybe that is where my love for documentation comes from. I like to keep it short, but informative.
2 - Ask him about his frustrations with badly documented systems.
Personal example - It took me 2 months to understand something that could have been understood in 1-2 weeks.
3 - Ask him about how he improved documentation in his previous company or how his documentation helped people.
Personal example - People often used to ask me how to use some features of internal apps. I saw too many requests of the same kind. So I created detailed documentation for it. Next time, I just shared the links to the docs. I never got any further requests after most of those requests. Maybe I did a good job.
4 - Ask him to describe a few things and see how he does it.
Notes - Consider that an audience does not know what a car is. I know people who'd begin describing a car in terms of engines, combustion, thermodynamics etc. when they should really be talking about 4 wheels, steering and moving from place A to B.
You could ask him about things that you know about better than him. Eg. What is a test automation framework and what does it really do ?
5 - Ask him to write a manual for any daily object.
Notes - Maybe your soda vending machine in your office ? See the kinds of questions he asks when documenting the object. If he does not ask the right questions, then he might not get the right info. If that happens, then his docs will not be effective.
6 - Ask him if he wrote blogs, github docs or self documenting code.
PS - Hope this helps. I guess I just showed some of my love for documentation. Off to punching out some code !
EDITS -
To clarify, by "documentation", I don't mean long manuals and such. It can be short too, depending on your audience. If someone wants more details (like interns), then they can talk to the developer. Documentation can have different forms. In software development, that can be self descriptive code and comments.
answered Feb 3 '17 at 0:48
SenseiTester
7014
edited Feb 3 '17 at 21:10
answered Feb 3 '17 at 0:48
SenseiTester
7014
answered Feb 3 '17 at 0:48
SenseiTester
7014
answered Feb 3 '17 at 0:48
SenseiTester
7014
7014
Agree with what Jeff said - give good documenters credit for their work. Also give them incentives. You could go cheap and let them go, only to realize how valuable they were, when you have to waste time and money to figure out poorly documented things.
– SenseiTester
Feb 3 '17 at 0:57
spare us the "developers should not make documentation", well on ther other hand, you're often ask to write "a documentation" without a clear objective, and I won't talk about all the times I have to write a installation/exploitation documentation which belong to the system area (in which I'm not supposed to be competent since there are the system guys for that). And the thing I hate the more is when I have detail every single step (click on next, open the command by typing "cmd" in the startup menu,...) so even a five years old kid should be able to do it.
– Walfrat
Feb 3 '17 at 12:32
I mean, do aircraft engineer write their documentation so even a five years old kid can build a plane ? Why should we then ? Just get a decent System administrator.
– Walfrat
Feb 3 '17 at 12:33
@Walfrat - When the objective is not clear, I would say so to my manager and document whatever little we know, only if that would be helpful for us. I would keep the docs very minimum or even zero initially. I can add more details when the objectives become clearer. Maybe even mention why one design/solution was abandoned in favor of another. (So that anyone newcomer who thinks about going to the old design will know not to).
– SenseiTester
Feb 3 '17 at 20:51
As for the kiddie level of documentation, here is what I have to say. If your audience is a layperson/intern, then the docs have to be at their level. If your audience is customers/end users, then maybe a product manager/business analyst can do that kiddie level documentation, not the developer. I never said that the developer has to create customer manuals and everything, if thats what you meant. If there is no product manager (maybe in startup) then guess who has to multitask ? The developer or QA.
– SenseiTester
Feb 3 '17 at 20:54
 |Â
show 3 more comments
Agree with what Jeff said - give good documenters credit for their work. Also give them incentives. You could go cheap and let them go, only to realize how valuable they were, when you have to waste time and money to figure out poorly documented things.
– SenseiTester
Feb 3 '17 at 0:57
spare us the "developers should not make documentation", well on ther other hand, you're often ask to write "a documentation" without a clear objective, and I won't talk about all the times I have to write a installation/exploitation documentation which belong to the system area (in which I'm not supposed to be competent since there are the system guys for that). And the thing I hate the more is when I have detail every single step (click on next, open the command by typing "cmd" in the startup menu,...) so even a five years old kid should be able to do it.
– Walfrat
Feb 3 '17 at 12:32
I mean, do aircraft engineer write their documentation so even a five years old kid can build a plane ? Why should we then ? Just get a decent System administrator.
– Walfrat
Feb 3 '17 at 12:33
@Walfrat - When the objective is not clear, I would say so to my manager and document whatever little we know, only if that would be helpful for us. I would keep the docs very minimum or even zero initially. I can add more details when the objectives become clearer. Maybe even mention why one design/solution was abandoned in favor of another. (So that anyone newcomer who thinks about going to the old design will know not to).
– SenseiTester
Feb 3 '17 at 20:51
As for the kiddie level of documentation, here is what I have to say. If your audience is a layperson/intern, then the docs have to be at their level. If your audience is customers/end users, then maybe a product manager/business analyst can do that kiddie level documentation, not the developer. I never said that the developer has to create customer manuals and everything, if thats what you meant. If there is no product manager (maybe in startup) then guess who has to multitask ? The developer or QA.
– SenseiTester
Feb 3 '17 at 20:54
Agree with what Jeff said - give good documenters credit for their work. Also give them incentives. You could go cheap and let them go, only to realize how valuable they were, when you have to waste time and money to figure out poorly documented things.
– SenseiTester
Feb 3 '17 at 0:57
Agree with what Jeff said - give good documenters credit for their work. Also give them incentives. You could go cheap and let them go, only to realize how valuable they were, when you have to waste time and money to figure out poorly documented things.
– SenseiTester
Feb 3 '17 at 0:57
spare us the "developers should not make documentation", well on ther other hand, you're often ask to write "a documentation" without a clear objective, and I won't talk about all the times I have to write a installation/exploitation documentation which belong to the system area (in which I'm not supposed to be competent since there are the system guys for that). And the thing I hate the more is when I have detail every single step (click on next, open the command by typing "cmd" in the startup menu,...) so even a five years old kid should be able to do it.– Walfrat
Feb 3 '17 at 12:32
spare us the "developers should not make documentation", well on ther other hand, you're often ask to write "a documentation" without a clear objective, and I won't talk about all the times I have to write a installation/exploitation documentation which belong to the system area (in which I'm not supposed to be competent since there are the system guys for that). And the thing I hate the more is when I have detail every single step (click on next, open the command by typing "cmd" in the startup menu,...) so even a five years old kid should be able to do it.– Walfrat
Feb 3 '17 at 12:32
I mean, do aircraft engineer write their documentation so even a five years old kid can build a plane ? Why should we then ? Just get a decent System administrator.
– Walfrat
Feb 3 '17 at 12:33
I mean, do aircraft engineer write their documentation so even a five years old kid can build a plane ? Why should we then ? Just get a decent System administrator.
– Walfrat
Feb 3 '17 at 12:33
@Walfrat - When the objective is not clear, I would say so to my manager and document whatever little we know, only if that would be helpful for us. I would keep the docs very minimum or even zero initially. I can add more details when the objectives become clearer. Maybe even mention why one design/solution was abandoned in favor of another. (So that anyone newcomer who thinks about going to the old design will know not to).
– SenseiTester
Feb 3 '17 at 20:51
@Walfrat - When the objective is not clear, I would say so to my manager and document whatever little we know, only if that would be helpful for us. I would keep the docs very minimum or even zero initially. I can add more details when the objectives become clearer. Maybe even mention why one design/solution was abandoned in favor of another. (So that anyone newcomer who thinks about going to the old design will know not to).
– SenseiTester
Feb 3 '17 at 20:51
As for the kiddie level of documentation, here is what I have to say. If your audience is a layperson/intern, then the docs have to be at their level. If your audience is customers/end users, then maybe a product manager/business analyst can do that kiddie level documentation, not the developer. I never said that the developer has to create customer manuals and everything, if thats what you meant. If there is no product manager (maybe in startup) then guess who has to multitask ? The developer or QA.
– SenseiTester
Feb 3 '17 at 20:54
As for the kiddie level of documentation, here is what I have to say. If your audience is a layperson/intern, then the docs have to be at their level. If your audience is customers/end users, then maybe a product manager/business analyst can do that kiddie level documentation, not the developer. I never said that the developer has to create customer manuals and everything, if thats what you meant. If there is no product manager (maybe in startup) then guess who has to multitask ? The developer or QA.
– SenseiTester
Feb 3 '17 at 20:54
 |Â
show 3 more comments
up vote
-2
down vote
I myself am in a situation where I have to demonstrate that I know how to document:
I have answered a few questions on stackoverflow.com I believe that the way I answered these questions is a good reflection on how well I can write documentation.
I run a couple of blogs. While they need an update, I believe that they expose the quality of my technical writing pretty well.
If it's doable, ask to see current writing samples.
Back in December 1999,I successfully interviewed for a position as a marketing analyst for a high tech marketing consulting company. The core of the interview was a one-hour writing test on any technical subject. The interviewer ripped out of my hand within 30 minutes - and almost gave me a paper cut - he'd seen enough, and I got my phone call the next day :)
If writing ability is important to you, I expect that you'd have filtered out those who sent you poorly written cover letters and resumes. A poorly written, poorly organized Linkedin profile is a no-no :)
answered Mar 19 '15 at 10:22
Vietnhi Phuvan
68.9k7118254
Paper? Nobody wants to see my handwriting. My writing, I hope, is another matter.
– keshlam
Feb 3 '17 at 1:12
suggest improvements |Â
up vote
-2
down vote
I myself am in a situation where I have to demonstrate that I know how to document:
I have answered a few questions on stackoverflow.com I believe that the way I answered these questions is a good reflection on how well I can write documentation.
I run a couple of blogs. While they need an update, I believe that they expose the quality of my technical writing pretty well.
If it's doable, ask to see current writing samples.
Back in December 1999,I successfully interviewed for a position as a marketing analyst for a high tech marketing consulting company. The core of the interview was a one-hour writing test on any technical subject. The interviewer ripped out of my hand within 30 minutes - and almost gave me a paper cut - he'd seen enough, and I got my phone call the next day :)
If writing ability is important to you, I expect that you'd have filtered out those who sent you poorly written cover letters and resumes. A poorly written, poorly organized Linkedin profile is a no-no :)
answered Mar 19 '15 at 10:22
Vietnhi Phuvan
68.9k7118254
Paper? Nobody wants to see my handwriting. My writing, I hope, is another matter.
– keshlam
Feb 3 '17 at 1:12
suggest improvements |Â
up vote
-2
down vote
up vote
-2
down vote
I myself am in a situation where I have to demonstrate that I know how to document:
I have answered a few questions on stackoverflow.com I believe that the way I answered these questions is a good reflection on how well I can write documentation.
I run a couple of blogs. While they need an update, I believe that they expose the quality of my technical writing pretty well.
If it's doable, ask to see current writing samples.
Back in December 1999,I successfully interviewed for a position as a marketing analyst for a high tech marketing consulting company. The core of the interview was a one-hour writing test on any technical subject. The interviewer ripped out of my hand within 30 minutes - and almost gave me a paper cut - he'd seen enough, and I got my phone call the next day :)
If writing ability is important to you, I expect that you'd have filtered out those who sent you poorly written cover letters and resumes. A poorly written, poorly organized Linkedin profile is a no-no :)
answered Mar 19 '15 at 10:22
Vietnhi Phuvan
68.9k7118254
I myself am in a situation where I have to demonstrate that I know how to document:
I have answered a few questions on stackoverflow.com I believe that the way I answered these questions is a good reflection on how well I can write documentation.
I run a couple of blogs. While they need an update, I believe that they expose the quality of my technical writing pretty well.
If it's doable, ask to see current writing samples.
Back in December 1999,I successfully interviewed for a position as a marketing analyst for a high tech marketing consulting company. The core of the interview was a one-hour writing test on any technical subject. The interviewer ripped out of my hand within 30 minutes - and almost gave me a paper cut - he'd seen enough, and I got my phone call the next day :)
If writing ability is important to you, I expect that you'd have filtered out those who sent you poorly written cover letters and resumes. A poorly written, poorly organized Linkedin profile is a no-no :)
answered Mar 19 '15 at 10:22
Vietnhi Phuvan
68.9k7118254
edited Mar 19 '15 at 14:40
answered Mar 19 '15 at 10:22
Vietnhi Phuvan
68.9k7118254
answered Mar 19 '15 at 10:22
Vietnhi Phuvan
68.9k7118254
answered Mar 19 '15 at 10:22
Vietnhi Phuvan
68.9k7118254
68.9k7118254
Paper? Nobody wants to see my handwriting. My writing, I hope, is another matter.
– keshlam
Feb 3 '17 at 1:12
suggest improvements |Â
Paper? Nobody wants to see my handwriting. My writing, I hope, is another matter.
– keshlam
Feb 3 '17 at 1:12
Paper? Nobody wants to see my handwriting. My writing, I hope, is another matter.
– keshlam
Feb 3 '17 at 1:12
Paper? Nobody wants to see my handwriting. My writing, I hope, is another matter.
– keshlam
Feb 3 '17 at 1:12
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f42961%2fhow-to-select-an-applicant-with-good-documentation-skills%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
3
If you want to know if they are a documentation freak ask them "How do you feel about writing documentation". If they like writing documentation they will tell you.
– paparazzo
Mar 19 '15 at 13:13
The documentation role is more that of a business / systems analyst than of an engineer. Perhaps you should recruit for a combination position.
– Wesley Long
Mar 19 '15 at 16:12
@Wesley - If you aren't willing to do the documentation then you really shouldn't be calling yourself an engineer. Developer maybe, but certainly not engineer which implies a bit higher degree of professionalism.
– Dunk
Mar 19 '15 at 20:22
@Dunk - Respectfully, I disagree. An engineer's role is to develop solutions, and to document their own work. It is not their role to document the work and systems of others. That is what business analysts and technical writers do. That's the reason these positions exist.
– Wesley Long
Mar 19 '15 at 20:23
@Wesley - As long as you agree that an engineer's role includes documenting at least their own work then I'm ok with that.
– Dunk
Mar 19 '15 at 20:59