This is a test of your organization software development culture. The answer “a” gives you 0 points, “b” gives 1 point, “c” gives you 2 points, etc. Sum all the points. You can spent as much time as you want to.

1. Software Design Approach.
You need to program a new feature.
a) You read a manual, a book or search in google for possible solutions, and select the best one.
b) You inform yourself about the used tools (programming language, framework, templates etc) and come up with an own solution.
c) You come up with at least two different solutions before you start coding, compare them, understand positive and negative features of them, tentatively select one of them, code, test, and perhaps switch to another approach.

2. Code implementation approach.
a) You find a solution in google and paste it to your code without reading.
b) You find solutions in the Internet, read them, and re-implement them, using your code style.
c) You write your own solution.
d) You write your own solution and open source it.
e) Same as above, but you also write a unit test.
f) Same as above, but you also write some documentation.

3. Interface design approach.
You have two different processes and have to design an RPC interface between them.
a) You don’t create your own interface, but find and use some another existing function instead, that sometimes coincidentally does almost the same thing you need.
b) You think of one possible piece of data that should be transferred between the systems, define a function for that, and call it a day.
c) You think the interaction between systems through, possibly helping yourself with UML sequence diagrams. You go through all use-cases you want to focus on in the first version, and ensure that the API has a complete set of functions and data structures.
d) Same as above, but you also implement both sides of the interface (create DTOs and function proxies) as a library.
e) You also check that both sides of communication are always in a predictable, correct state, no matter how the other party might misbehave during the communication. You ensure absence of racing conditions. When appropriate, you implement the communication in a secure way. Both sides of the communication log the sent and received data to enable API debugging.

4. System architecture design approach
You have a single feature that has to be distributed across different systems (eg. client / server system, or systems with several CPUs).
a) You find at most one possible cutting line and cut the feature along it.
b) You split the feature into the layers (eg. Application & UI, Middleware and Hardware-specific Code) and draw the border along a layer.
c) All your features are split along the same line, so that layers nicely map to systems.

5. Bug fixing approach
a) You guess bug reason without reproducing it, perform a change, check that the software works, and close the ticket.
b) You first ensure the bug is present by reproducing it, then proceed as above.
c) You reproduce the bug, then understand exactly why it happens, then fix it, then check it is fixed, then remove the fix, check it is broken again, the redo the fix and check it is fixed, then set ticket to “ready to test”
d) As above, but you also create an automated unit test for this very bug, and run it every time you release the new version (or even every time somebody commits a change)
e) Same as above, but you also reflect what other parts of  software could have a bug of similar nature. For each such place, you reproduce the bug, implement similar fix, and test it.
f) Same as above, but you also post a wiki article / communicate with other team members in case of an especially nasty bug.
g) Same as above, but you also submit a bugfix, in case you’ve fixed an open-source software.

6. Usage of SCM
a) You don’t use any SCM
b) You commit once a week without writing a comment.
c) You commit once a day, but regularly have changed files you never commit to SCM, and your comments are not very informative.
d) You commit several times a day; after each commit you don’t have any changed local files anymore. But you think branching and merging is dangerous.
e) You can freely use all SCM features (including merging). You prefer using SCM over commenting out unused code paths, because it is more comfortable.
f) You have hooks on SCM server (for example, a continuous integration server, an automatic e-mail, or a automatic policy checker)
g) You have an established code review process.

7. Release process
a) You just copy over some compiled files happen to be stored in various folders on your development PC. You don’t label the state nor have a trackable version identifier.
b) You set a label in SCM, but create your release by manually and selectively cherry-picking some specific files.
c) You label a release in SCM and create a release from that state automatically, so that you can always recreate a bit-identical release by running an automatic script.
d) After each release, you run automated tests and then optionally automatically deploy the software in production

8. Code Ownership
a) Each team member owns a specific set of source files. Nobody else is allowed to touch them.
b) Everybody is allowed to change any files. Nobody feels responsible for any file.
c) Everybody is allowed to change any file by implementing the change locally, testing it and sending it to the file owner with suggestion to check and integrate the patch.
d) Even when changing my own files, I send my change to a peer code reviewer and get his sign-off.

9. Communication strategy
a) Information doesn’t flow horizontally or flows accidentally (meeting someone in the coffee kitchen: oh, by the way, do you know that…)
b) There are dedicated persons (leads, coaches, managers) who are responsible for information flow
c) Information gets stored in the project’s wiki
d) Project’s wiki is a very popular highly visited place, not less entertaining than Facebook/twitter

10. Project planning
a) Software developers don’t plan projects and ignore project planning of other people (eg. managers).
b) Software developers try to achieve deadlines declared from outside (eg. by managers) and fail doing that.
c) Software developers write down an own realistic plan and work at least once a week with management to establish a common realistic roadmap.
d) Most deadlines are met.

 

26 to 37 points: you probably work at some Software Developer Paradise like Google

15 to 25 points: you’re industry standard.

0 to 15 points: you’re in hell, get out of here!