Interview Questions for Agile Developers


Developers who are familiar with Agile have seen their stock rise. That’s because CIOs view the framework as a way to keep up with the ever-evolving needs of owners and a welcome alternative to traditional methodologies.

The approach fosters incremental software development by replacing silos with svelte cross-functional teams and emphasizing communication and collaboration over documentation and meetings. Daryl Kulak, a vice president at consulting firm Pillar Technology Group, likes to mirror Agile’s collaborative spirit during interviews. Here are some of the questions he asks.

Click here to see Agile development jobs.

How long is your typical sprint?

  • What Most People Say: “Most of my sprints last one month or longer.”
  • What You Should Say: “My sprints last one week, two weeks max.”
  • Why You Should Say It: Agile requires frequent feedback from project owners. Short sprints give the owner a chance to make adjustments and developers a chance to react throughout the development cycle. Collectively, short sprints give the entire team a chance to nip coding or quality issues in the bud.

What’s your definition of Test-Driven Development?

  • What Most People Say: “TDD refers to unit testing on a completed section of code.”
  • What You Should Say: “TDD in an Agile environment refers to the testing cycle. First, I write the test. Then, I write the code to pass the test. Finally, I run the test and refactor the code as necessary.”
  • Why You Should Say It: TDD is better than unit testing because it facilitates quick identification and resolution of coding problems. “It’s better to write the test before you write the code,” Kulak says. “It forces you to think through the specification and code with the test in mind.” In addition, the tests replace documentation, which rarely gets amended as the code changes.

How does Agile impact the design process?

  • What Most People Say: “It doesn’t. Designers or architects produce the design. They give the software design documents to developers like me, who interpret the design and write the code.”
  • What You Should Say: “In Agile, the design and development process are intertwined. Developers are also designers and team members alternate between designing, developing and testing throughout the entire development process.”
  • Why You Should Say It: Consolidated development and design is the hallmark of Agile. It reduces errors and improves productivity because developers don’t have to interpret designs or seek clarification from designers before they write the code.

What is the ideal length of a method?

  • What Most People Say: “There’s no ideal length. I’ve written methods containing five to 100 lines of code.”
  • What You Should Say: “Ten to 20 lines of code is my personal rule of thumb.”
  • Why You Should Say It: A method should only accomplish one thing, Kulak says. “If your code exceeds 20 lines, you’re trying to do too much,” he believes. “It’s hard to read, decipher and maintain lengthy code segments. Methods should be simple and small.”

Related Articles

Image: joreks/

10 Responses to “Interview Questions for Agile Developers”

  1. Shantal

    This is one interview where I won’t be in attendance, as one who has witnessed these 5 minute sessions of ineffectual communication sessions result in shoddy products and even complete disasters. This is something I would never provide a client in good conscience. In almost all cases, the shorter a sprint, the less analysis and communication has occurred resulting in a multiplicative number of bugs and long term base problems. This is actually developer centered with an agenda of keeping a project on the doles for a longer period of time. Agile development is far from being a conceptual nirvana in which it was said to quickly integrate many different technologies, but is actually neither in intent or application. It is amazing to me how much energy and resources are being poured into such a generally ineffective methodology of work process. Developers and project managers are human beings, not robots who should be expected to perform at high capacity with inadequate levels of communication and testing.

    • Rob S

      While it’s true that many places do not implement Agile correctly, if done right it will make MOST projects work more efficiently.
      The mistake by many is, as you imply, lack of long-term vision. Good agile does not preclude that; it simply takes the long term vision and slices off a piece to work on.
      And yes, if everything is worked out in advance, Agile will be slower than “waterfall” because you have to stop; present interim work; examine how to break things into small pieces that cannot exceed a certain timespan (e.g. 2 weeks); refactor to make up for the shorter timespan that forced you to create an interim solution while trying to complete the bigger task.
      However, given that few projects are 100% right from the beginning, and most change directions frequently as the projects go, using waterfall would require a major re-build of all the parts to address the new direction, then a major rebuild again with the next new direction.
      In Agile, you only have minor shifts because at worst you lose a sprint of work then regroup and move forward.

      So all in all, if you know exactly where you’re going, use waterfall; for many other thing where you discover new paths or new features you’d like to add, Agile is much better.

    • You are correct, Agile is not Nirvana. There are numerous ways in which it will fail. If implemented on a team where the corporate attitude includes “Failure is not an option”, it won’t work. Implemented on a dysfunctional team it will magnify the dysfunctions. That’s one of the things the methodology is supposed to do. A team honestly reviews the dysfunctions and try to correct them. The process is then repeated each sprint. If a team does not try the corrections and gets frustrated then the process fails.

      Another mistake is doing Agile only with developers. I’ve been on a team done this way. Design and QA was done outside of the team. Feedback also came from outside the team. Developers came to refer to it as the “Blame us” meeting. Needless to say it didn’t work out well.

      However, I’ve also been on a team where it worked phenomenally. The waterfall process always resulted in hundreds or thousands of bugs found days before a deployment and long hours fixing and testing. Unofficial policy was that no one could take time off the week of deployment. Initially Agile was a disaster. We held retrospectives and gradually fixed things. The testing process that under waterfall reported hundreds of bugs was updated to run all the time and reported a few bugs each day. This was much easier to handle and the team knew the bugs would be retested again and again before deployment. It increased the confidence within the team that the bugs were fixed and stayed fixed. Instead of taking a week deployments could be done in a day or a few hours.

      Agile focuses on the people over the tools. In the team above I was one of the problems because I took a volume over value approach to fixing bugs. I would fix ten easy bugs and leave one undone because it was hard. The one bug would be a higher priority and may have been worth thirty lower priority ones. This was pointed out in one of the stand up meetings. I had to change my way of working. It was not easy but I did make it. Agile helped me with this though the feedback from daily stand up meetings. I don’t thing the shift in the way I worked would have been as fast without it.

      No, Agile is not Nirvana. It requires work, trust and dedication.

    • I’m not sure if you mean TDD over code-first testing, but TDD is more like the carpenter’s shop, to use your analogy. It’s not just the unit tests, automated acceptance tests, etc. It’s the attitude, principles, and practices that drive the value from those tools.

      It is possible to frame a development problem properly in your head, write the code well, then create all tests needed for that code. However, if TDD is followed properly, properly-framed design, simply-written code, a comprehensive testing and code quality are a natural and consistent output.

      Again, to tie it back to your analogy, it’s possible to wing a wood project in your kitchen and get a good result. A well-run carpentry shop will consistently produce quality work.

  2. It’s completely depending on the client and industry you target. I hardly think that any Government contracts that require strict conformance to ISO would accept Agile as a valid paradigm of software development. The difficulties also stem from long term vision, if a developer is working on a small single component it can be hard to see the significance of that part in the grand scheme of things. This can naturally foster opportunities for miscommunication.
    However, it can address one criticism that the industry tends to receive from it’s traditional “waterfall” approach to coding, it allows dev teams to be far more reactive (and in cases of good agile teams proactive) to client requirements.

    Agile totally depends on the industry segment that the enterprise or project is for. The games industry make fantastic use of agile development as it allows them to be highly reactive based on players (their customer feedback)

    Like everything, Agile is a tool, its up to you to decide how best to use it!

  3. Jonathan Greene

    As i understand it Agile is implementing code in blocks or sections. Is this right? If not I am not sure what methodology I use as I create the plan, work on the logic, build the test cases. Then I build the section, check the sections against the test cases. Evaluate both the test cases and the code to make sure i am getting the desired result of the overall project. Move onto next block.

  4. There are several pitfalls which, when compared to the benefits of agile scrum, certainly make a strong case for not using agile scrum to develop software. They are:

     More time required for communication among team members
     Increased demands on developers and testers
     Absent documentation
     Poor code quality or technical debt
     Scope creep
     Hindering the creativity process
     Difficult for newcomers to learn existing code
     Micromanages employees
     Sometimes pushed by individuals who are not software developers

    I can go into each one of these points in detail, but this is hardly the place for that.