Skip survey header

Developer Personality Test

Welcome to DZone's Developer Personality Test!

This 62-question test will give you the 5 dimensions of your developer personality, much like the famous Myers-Briggs personality test. You will see your results on the second-to-last page. On the last page, you'll see descriptions of each dimension.

To take the *Short* version (25-questions), go here. Visit DZone to find top developer articles, research guides and reference sheets!
1. You prefer a language like Python that adds strict rules on indentations but doesn’t require closing brackets or “ends” at the end of a statement. *This question is required.
2. You believe that your team needs to have rules and process throughout your entire development workflow. *This question is required.
3. You believe you’re able to do everything you need to do with the tools you currently have for the foreseeable future. You’re not currently interested in adding recently created tools or upgrading current tools. *This question is required.
4. You prefer to write code in a language (like Python or Ruby) that doesn’t require semi-colons at the end of lines. *This question is required.
5. You often ask for help, even if you don’t need it but you’re curious for another perspective. *This question is required.
6. You think real-time pair programming is a bad idea about 90% of the time. *This question is required.
7. You prefer to just focus on one slice of the stack and don’t want to spend time and effort learning other slices if it’s not absolutely necessary. *This question is required.
8. You like sharing the highs and lows of development with colleagues in a team. *This question is required.
9. You’re willing to go to some of the lowest levels of the programming language (C/C++ or lower) to improve performance. *This question is required.
10. You’re always bookmarking new development resources and articles to grow your skills outside of your current focus, even if you are rarely able to look closely at all of them. *This question is required.
11. You are frequently willing to scrap pieces of software that you’ve built if something new comes along that might do the job better. *This question is required.
12. Developers should only innovate incrementally and not try to make major leaps. *This question is required.
13. You believe teams should never compromise quality or skip process steps to meet a deadline. *This question is required.
14. You think that many of the popular web frameworks and libraries go too far in abstracting away the lower-level code processes, destroying the essential need for understanding the inner workings of many parts of an application. *This question is required.
15. There are so many new tools out there that try to address problems we solved years ago, and the older, time-tested methods are preferable. *This question is required.
16. You hate doing low-level tasks like pointer arithmetic or moving registers around. *This question is required.
17. It is okay if you have to reduce the amount of testing and review that goes into new features in order to meet a release deadline. *This question is required.
18. You will often defer to other people on your team that you disagree with if they are very confident in their beliefs and you know they have strong technical knowledge. *This question is required.
19. You would rather buy a product with some amount of ecosystem lock-in than rely on your ability to build something out of unsupported open source technologies from scratch. *This question is required.
20. You prefer to have shared programming spaces for a majority of your daily work so you can constantly bounce ideas off of each other. *This question is required.
21. You like working on solo projects for days on end. *This question is required.
22. Trying to build test coverage for every imaginable scenario is not a productive use of your time. *This question is required.
23. You would consider yourself a specialist in your area of the stack, not a generalist that just knows a little bit of everything throughout the whole stack. *This question is required.
24. You find that your quality of work increases significantly when you collaborate or pair program frequently. *This question is required.
25. The pain of re-architecting an application or re-engineering it with different technologies for major potential benefits is usually too great and it's often too risky. *This question is required.
26. You believe that the best software is usually built from the architectural vision of one person, rather than a collection of ideas from multiple people. *This question is required.
27. You prefer to have projects that force you to learn new skills rather than learning them through your personal projects. *This question is required.
28. You believe IT organizations should never hesitate to fix deeper technical problems just because the software still works and is passable to customers. *This question is required.
29. You like to have your ideas and opinions challenged by team members. *This question is required.
30. You usually feel that planning and meetings take too much time, which could be better spent on doing actual work. *This question is required.
31. You think that even if a technology is relatively new, if it has a bit of momentum and a community, you’ll gladly be an early adopter. *This question is required.
32. You usually only read articles and find resources that are relevant to the current project you are working on. *This question is required.
33. You believe there is roughly one or two ideal ways to build most of your features and software, and it’s important to get as close as possible to that ideal. *This question is required.
34. You like to use new tools and libraries in production software even if the tools are not very mature and the community isn’t very large. *This question is required.
35. You dislike having to make a case for your views on the direction of development (which tools to use, processes, etc.) to your colleagues. *This question is required.
36. You believe software features should be as good as you think you can make them (at the time) before you release them. *This question is required.
37. You will start using a technology in production software only if the technology has significantly matured in reliability and community. *This question is required.
38. You get out of your office multiple times a day to discuss coding issues or ideas with others. *This question is required.
39. You believe that developers shouldn’t waste time trying to figure out an ideal way to build software, and instead should just rapidly prototype on a design that simply works. *This question is required.
40. You prefer to spend significant time early on in development making every performance optimization you can think of. *This question is required.
41. You believe that many of the rules and steps in formal development methodologies (e.g. Agile, Kanban) are unnecessary. *This question is required.
42. You like to focus on one project at a time - at work and in any hobby development - and if it’s a hobby project, the knowledge you’re trying to gain is always for specific, practical, and applicable skills that you will need to use soon. *This question is required.
43. You consider yourself a Jack of all Trades. *This question is required.
44. You will start using a technology you want to use in production software even if it’s only one year old or less. *This question is required.
45. Collaboration often doesn't result in significant innovations. Individual study and research is much more fruitful in this regard. *This question is required.
46. You like to work on a lot of projects at once, hobby or work-related. *This question is required.
47. If you had to choose, you would prefer tools/languages with more ease of use over tools/languages that are more error-safe. *This question is required.
48. You like to be in control of low-level things like memory management, when it's appropriate, instead of the programming language. *This question is required.
49. You believe IT organizations must often compromise and temporarily ignore deeper technical problems in software releases or critical systems. *This question is required.
50. You are a reference for many people in your company because you know obscure pieces of trivia and can provide a list of tools for many use cases, even in subjects outside your current focus. *This question is required.
51. You like to be knowledgeable and somewhat proficient in the parts of software production that you don’t primarily focus on in your day-to-day work (such as having sysadmin skills, hardware skills, compiler or language building skills). *This question is required.
52. You should spend about 40-70% of your time planning a project so that there is less code to write and by the time you start coding, you’ll mainly be filling in stubs. *This question is required.
53. You are more likely to over-comment your code than under-comment it. *This question is required.
54. You want to migrate frameworks and libraries in your software to the newest versions as soon as they are available. *This question is required.
55. Developers need to experiment with radical changes to their software that could yield leaps in innovation. *This question is required.
56. You like to learn in advance how to handle the problems you will face in building your application. *This question is required.
57. You like to learn how to solve problems as they come to you in the application development process. *This question is required.
58. You prefer coding projects where you are the main designer and writer of the crucial code. *This question is required.
59. You should spend no more than 15% of your time planning a project because you can plan as you go. *This question is required.
60. You quickly create working solutions for immediate problems focusing on productivity and learning as needed. *This question is required.
61. More developers are only needed on a project when the lead developer needs to delegate some of the tasks. If the lead dev can do it on their own, they should. *This question is required.
62. You feel it’s important to be very knowledgeable about the lower (source code) levels underneath various development frameworks, libraries, and languages. *This question is required.
0%