Top XML Interview Questions

Interview Questions Categories
Core Java | J2EE | Database | Struts | XML | HTTP | Web Services

I have prepared this list for those of you seeking to appear in Java / J2EE interview at various companies globally. This post contains a list of popular XML questions normally asked during interview. These are prepared from most frequently asked questions from various software industries. I myself have interviewed over 100 candidates. I have intentionally not provided the solution here. But if you are desperate for one, send me an email via Contact Us link. For other interview questions such as those for J2EE, Core Java, Database etc and for some sample programming implementations intended to help you to prepare for the interview of tech giants like Google / Microsoft / Amazon, go to my page here.

  1. What is XML?
  2. What is the difference between XML and HTML
  3. What are some of the benefits of XML?
  4. How do you parse and XML?
  5. What is a DOM Parsing?
  6. What is a SAX Parsing?
  7. When do you use a DOM Parsing vs a SAX Parsing?
  8. What makes an XML Well formed?
    • A well-formed document in XML is a document that adheres to the syntax rules specified by the XML 1.0 specification in that it must satisfy both physical and logical structures
  9. What is XML Schema Definition (XSD)?
  10. What is an XML Schema?
  11. What are some differences between DTDs and Schemas?
  12. What is a simple element?
  13. What is a complex element?
  14. What are namespaces?
    • XML Namespace is a mechanism to avoid name conflicts by differentiating elements or attributes within an XML document that may have identical names, but different definitions.
  15. Why are namespaces important?
  16. What are two different ways you can use namespaces?
  17. What is CDATA section in XML?
    • The term CDATA means, Character Data. CDATA are defined as blocks of text that are not parsed by the parser, but are otherwise recognized as markup. The predefined entities such as <, >, and & require typing and are generally difficult to read in the markup. In such cases, CDATA section can be used.
  18. Describe a logical structure of XML?
  19. Why is XML Extensible?

Pair Programming – A Comprehensive Guide To Get You Going

As of 2016, I have worked in an scrum based agile environment for over five years for a Fortune 100 company. This comprehensive guide was created as a part of mentoring new resources or new scrum teams to make them aware of pair programming and analyze the benefits and techniques so as to meaningfully use the concept and not just do pairing for pairing sake. Here is a summary of what you can expect to learn from this article.

  1. What is wikipedia definition of Pair Programming?
  2. What are the benefits of pair programming?
  3. What negative things people think about pair programming?
  4. What problems may arise in a pair programming environment?
  5. What are some of the good practices of pair programming?
  6. What are some of the popular pairing models?
  7. What are some of the situation to pair on?
  8. What are some of the situations where pair programming might not be beneficial?
  9. How to detect pairing smells?
  10. What are some popular pairing techniques (compare with pairing models)?
  11. When it is not a true pairing?
  12. How my current team pairs?
  13. Miscellaneous thoughts and suggestions around pair programming

Definition of Pair Programming:

According to Wikipedia,

  1. Pair programming is an agile software development technique in which two programmers work together at one workstation.
  2. One, the driver, writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in.
  3. The two programmers switch roles frequently

What are the benefits of Pair Programming?

  • More time spent upfront but less defects
    • Less Defects go into production
    • Defects caught early are less expensive
  • Improved Quality of Design and Software
    • Different background of developers
    • Different skill set
    • Different Thoughts
    • Negotiation during conflict
    • Multiple points of view
  • Confidence
  • Team Building and Communication
    • Working as a team towards the same goal
  • Continuous informal review of code
    • Saves you from separate code review
  • More than one person knows what is being implemented
    • Better diffusion of knowledge and transfer of skills
    • New team members get to learn
  • Old team members get to be mentors, coach
  • Continuous feedback and development opportunity
  • More economical
  • Co-ordination between developers is simplified
  • No need to setup extra meetings
  • More focus and engagement
    • Pairs stay focused longer than individuals
    • Less Multitasking
      • You are less likely to multitask when you are a pair
  • Can solve problems faster
  • Fewer blockage
    • One person’s blind spot might not be a problem to the other guy
  • Vacation or emergency situations
    • Less dependence on one person
  • Work ownership
  • Better adherence to organization’s coding standards
  • Better design
  • Share responsibility and pressure
  • Reduced Training Cost

What people also think about pair programming (Myths)?

  • Waste of time and resource:
  • Two people working on one item while they could be working on two separate works
  • Less work will get done
  • Cost will double
  • Not everyone is equal – new and less experienced resources will slow down the experienced ones

These myth’s are either untrue or partially true on a short term. If you look at the larger picture, you will definitely find these myths incorrect.

What problems may arise in a pair programming environment?

  • Conflicts of ideas
  • Conflicts of schedules
  • Partner not available
  • Going over the speed limit
  • False sense of confidence
  • Not ideal in every situations
    • Some research work
    • Both pairs don’t know how to implement
    • Partners hate each other
    • Odd number of developers
    • Work is trivial

Good Practices of pair programming:
The following are some of the good practices to keep your pairing healthy, mutual and productive.

  • Think out loud
  • Switch Pairs
  • Switch Roles
    • Between story cards?
    • Time Sliced?
    • Half hour?
    • Before lunch / after lunch?
    • Between Coding / Unit Testing
  • Be a good listener
  • Get away from your phones
  • Be a good observer
  • Do a team work
  • Communicate well
  • Follow the convention
  • Ask Question
  • Negotiate
  • Accept other people’s ideas if they are better
  • Suggest Re-factoring
  • Everybody owns the code

Pairing Model:

So, how do you pair? Or how are pairs formed? Based on the knowledge and skills of individuals, there are three possible pairing combinations.

  1. Expert and Expert Pairing
    • Highest productivity
    • Greatest results
    • Complex solution
    • Quick Turnaround
  2. Expert and Novice Pairing
    • Ideal
    • Leads to learning and mentoring
    • New solutions and ideas
  3. Novice and Novice Pairing
    • Least Optimal
    • Still better than two new people working alone

What are some of the situations where pairing is helpful?
The following are some of the examples when the pairing is beneficial. Mind that these are only “some of the” example. There could

  • Production defect fix
  • New Story Cards
  • Complex problems
  • Unit Testing
  • Code and Database Design

In what situations pairing is not very useful?

  • Someone asks you to download logs for them
  • A work has trivial or pre-defined solutions:
  • Field name changes on an html component
  • Creating branches from svn
  • Doing builds by pushing a button
  • Research work

What are some of the popular pairing techniques?

  • Ping Pong Pairing
    • Mostly meaningful if you are doing TDD
    • If Brad and George are pairing,
    • Brad writes a new failing test
    • George implements just enough code to pass the test
    • George then writes a test that will fail
    • Brad implements the code needed to pass the test
    • Refactoring is done whenever need arises by whoever is driving.
  • Cross-Functional Pairing
    • E.g. Testers pairing with Developers
    • Or, Testers pairing with Analysts
  • Distributed Pairing
    • Solves problem of geographically distributed pair
    • Developers work via a collaborative real time editor, shared desktop or Cloud Development Environments

How my current team pairs?

  • Pairs are decided at the beginning of Iteration
  • Pairs Take a story card:
    • If a card is 1 or 2 points:
      • Pairing is optional, code review is mandatory
    • If a card is 3 points
      • Person A writes and completes code
      • Person B writes unit Tests in addition to consistently being a navigator
    • If a card is 5 points,
      • Person A writes code until he is tired
      • Person B writes code from where person A left
  • Repeat this until code and tests are complete.
  • If a pair is not found, Tech Key will pair.

When is it not pairing?

  • You identify yourselves as pairs but you sit at two different terminals
  • One person does work, the other one sit behind playing on the phone or with no interaction
  • You split the work and work individually

Pairing Smells:

Not all the pairing might go as expected, or might deteriorate after sometime. These are some of the things to watch for to detect if a pairing has rotten and has start smelling.

  • Pair Marriages – You always prefer to work with same person for a long time
  • Disengagement – worker /rester pairing
  • You agree to whatever the driver does, or the navigator tells you
  • Debates lasting longer than 10 minutes with no new code.
  • Unequal access to keyboard
  • Driver does not explain what he is doing
  • Silence – The pairs are not talking

Other thoughts and suggestions around pair programming:

  • Determine your pair at the beginning of your iteration.
    • Generally done by Scum Master / Iteration Master or Technical Key
  •  Until pairing goes normal, talk about how pairing is going at the daily scrum.
  •  It’s a pain, but it works.
  •  Look for visual indicators such as story cards having only one avatar.
    •  Ideally, every story card should have two avatars.
  • Include pair programming as a part of Definition of Done.
    • If you didn’t pair under normal circumstances, your card is not done.
    • Have a conversation with Tech Key on why you didn’t pair.
  • Get a pair and walk your code with your pair before marking the card as done.
  • If you couldn’t pair for some reason, get your code reviewed
  • Pull an expert from another team if they have time
  • Review does not mean it needs to be done by Tech Key or Tech lead.
  • Pull another developer, or even another pair