The following is the report I wrote upon completion of my 16 month internship at the IBM Canada Software Lab in Markham, ON. I had the report reviewed by an IBM manager who made sure it contained no confidential information.

I’m putting this up here because I’ve had numerous people ask me if they should do the PEY (Professional Experience Year) program. Hopefully this report will help them see what kind of stuff I got up to, and the skills, contacts, and values I developed while working in the industry for a year and half. By the way, my recommendation would be to absolutely do the PEY program. It is an invaluable opportunity, and will help pave the path for your future.

PEY Internship Report 2011-2012

By: Kevin Sloan


  1. Disclosure
  2. Introduction
  3. Job Description
  4. Project Report
  5. Skills and Knowledge Developed
  6. Values
  7. Career Plans
  8. Conclusion

1 Disclosure

This is to confirm that the information enclosed is correct and contains no confidential information.

2 Introduction

This report will summarize my experiences during my 16 month internship as a PEY Intern at the IBM Markham software lab. I worked as a Quality Assurance Analyst on IBM’s DB2 Database Management System (DBMS). Throughout my internship I worked on several software projects involving many different cutting edge technologies and software development techniques. I discovered what life is like at a large world leading company and developed many professional and technical skills. It has helped me evaluate my career plans and given me valuable insight into the possibilities that lie ahead.

3 Job Description

My position was Quality Assurance Analyst. I worked on the System Verification Testing (SVT) team for IBM’s DB2 software. This team tests the product as a customer would use it. They are the last line of testers before the product gets released to the customer. The team is in charge of testing the features that the customer will be using. Since the product is so large the SVT team is also responsible for testing the compatibility of different software and hardware components together.

Use cases are spread out among the team and every member was responsible for a different component. My specific specialty was network failures. One of the primary features of the DB2 software is resiliency against failed network components. My job was to intentionally fail different components on different hardware and observe that the detection and recovery was performed correctly.

When a QA Analyst finds a problem they collect as many diagnostics as needed and do an investigation to the point where they can identify a single software component that is causing the issue. Once the component has been identified they put together a note (structured email) describing the issue and send it off to the development team in charge of that component. They then work with the dev team to further diagnose the issue and verify proposed fixes before they are committed to the main code base. Once a fix is confirmed it is added to the main product and they move onto the next issue. Most of the time a single QA analyst will be balancing many different issues at once.

4 Project Report

During my time at IBM I worked on three major projects; DB2 v9.7/9.8, DB2 v10/10.1, and the new DB2 PureSystems family. I arrived halfway through the first project and worked with an existing team member to complete the testing scenarios. Near the end of my time at IBM I was working with a small team on an ”all-in-one” integrated system which was a combination of hardware, software, and storage that customers could plug in and start using right away.

However, the majority of my time was spent working on IBM DB2 V10 which was a major release of their DBMS software. I was in charge of the network failure testing scenario for this release. I was given a deadline and before that time I needed to cover a number of testing scenarios. These included several different types of hardware, operating systems, and networking fabrics. I was trained on the software and my scenario by the intern in charge of the same scenario before he left. Other members of my team had scenarios including storage failures, install/upgrade, large databases, and rollbacks to name a few. The team was a mixture of students and regular employees.

Seeing as my scenario required so many different configurations, I was assigned a number of machines to work with. I worked with several operating systems including RHEL, SLES, and AIX. The networking fabrics I was testing included Ethernet, InfiniBand and Fibre Channel.

My routine consisted of installing the latest build of DB2 (from the Rational ClearCase version control system) on several networked machines. I then set up the environment the way a customer would use it and started an automated workload to simulate users accessing the system. Once the entire system was up and running I would fail a networking component. I failed either the public network (connected to the internet), the private network (for local communication between machines), or the switches between machines (facilitated all the routing and communication between machines). Depending on which components I failed I expected different outcomes. Sometimes the failure was handled by the OS and sometimes by the software itself depending on the configuration. I checked for things such as network resiliency, communication re-routing, machine fencing and failover as well as crash recovery on the database. I made sure these things happened in the right sequence and within a reasonable time.

When I found that something was not behaving as it should I stopped testing, collected diagnostic data and started my investigation. The issues I found included performance, recovery, database corruption, abnormal client termination, and failure detection, among others. Most of the time the issues I found were caused by the DB2 software but there were a few hardware, and OS issues as well. After diagnosing the issue I found the team that was in charge of that component of the software. Sometimes the problem lied between teams as a compatibility issue and both teams needed to be involved. I also submitted the issue to the change tracking database (Rational ClearQuest or Jazz). Using this platform kept bug tracking and fixes organized so we knew what has been fixed and when it was committed, and to which build.

Once a defect was confirmed, I continued to work with the development team. Sometimes it consisted of further diagnostics and reproductions of the problem to determine why it was happening. After the problem is isolated a fix is proposed and I was responsible for testing the new fix and making sure it not only solved the problem, but didn’t cause any new ones. Once I approved a fix it got committed to the main build.

I was constantly tracking several issues at once on different configurations so staying organized was of utmost importance. Being able to continue to achieve progress on one configuration while another was tied up with development was a main success factor. Sometimes a scenario would become blocked by issues outside of my domain, like installation. It was up to me to find a way to work around those issues to get my scenario completed.

Diagnosis and investigation was the key to being a good QA analyst. The goal was to pinpoint the origin of the problem and provide logs and traces that proved beyond a doubt what needed to be fixed. The more information you can give about a problem, the faster it will get fixed and delivered.

When I was stuck on a problem I would first check the DB2 Info Centre (DB2 Docs) on the topic. If the problem was related to the OS or general machine issues I would first do some internet research and check the technical documents on the subject. If I had no idea where to start with a problem or was still stuck after checking the docs, I would usually go to the regulars with the symptoms of my problem. They would point me in the right direction. I found this was the fastest way to progress quickly with an issue. Every regular has a few specialties so if you knew who to see about what subject the answer was fairly easy to find.

I submitted weekly progress reports and attended daily scrum meetings during crunch times. Each meeting consisted of 3 main questions:

  • What have done since we last met?
  • What will you do before we meet again?
  • Is anything slowing you down or getting in your way?

We also had weekly team meetings to discuss progress as a whole, team-wide issues, and important announcements.

Once my scenario was completed I continued to check for regressions on newer builds as well as help other team members complete their work. During this downtime between projects I studied to improve the weaknesses I noticed on the previous project and to improve my workflow efficiency. Once the scenarios were assigned for the next project I started the whole process again.

5 Skills and Knowledge Developed


  • I practiced my organizational skills by managing a scenario with many variables and issues to track simultaneously.
  • I practiced time management skills by meeting deadlines.
  • I taught two interns over the course of four months how to be an effective QA analyst and how to tackle the network failure scenario. I practiced delegating work to these new students and being a team leader by aiding/teaching them while completing my own work.
  • I practiced my presentation skills by giving a presentation for the QA department on Remote Direct Memory Access as well as giving presentations to new interns about the DB2 related technologies.
  • I worked as part of both large teams and small teams on different projects and learned how to work well on both of them.
  • I learned how to read technical documents effectively and quickly narrow down where to find an answer.
  • I learned how effective meetings are conducted, and how they can also be a burden.
  • I learned how to solve problems in a corporate environment by finding the employees who can assist in solving your problem the fastest.
  • I observed that positive motivation is much more effective than negative motivation.
  • I learned effective status reporting and how to give effective progress reports in a
  • meeting scenario.
  • I learned how to use email as an effective collaboration tool and how to structure them for optimal clarity and invoke a quick response.


  • I became comfortable and proficient working with the command line. I gained experience with multiple operating systems including RHEL, SLES, and AIX.
  • I practiced software development strategies (mostly agile development).
  • I gained experience with IBM’s Rational ClearQuest comprehensive software change management system.
  • I opened issues, and tracked them to completion and delivery into the product.
  • I worked with IBM’s Rational ClearCase and Jazz version control and workspace management software.
  • I learned how to use the DB2 software and the many customer scenarios that are being used in the industry today.
  • I worked with the latest hardware and software in the industry.
  • I learned how server rooms work and how the machines themselves are configured, including networking solutions like switches and independent storage solutions.
  • I learned all about effective software testing strategies.


I observed several different management techniques throughout my internship. Some managers were more hands off and others were more aggressive. I noticed that employees responded differently to the techniques but the most effective for me was the hands off and positively motivated approaches. While workers did respond to negative motivation in the short term, they work much more effectively on a regular basis when working on their own accord and receiving praise instead of being intimidated or threatened.

I saw that as a corporation, IBM understands this and gives it’s employees an incredible amount of freedom. Employees can come and go when they feel is most efficient. Working from home occasionally is an option given to many departments. They have a full cafeteria, a gym, and offer many clubs and sports. They understand that a happy and healthy employee is an effective employee. They give a lot of power to their employees, and every one of them is very talented at what they do. IBM finds the right employees and gives them the freedom to do what they do best.

The best memories from my internship were the Friday team lunches and the beach volleyball games with my teammates. But also the completing my scenarios, coming in on a weekend to get some critical work done for a customer, finding crippling stop-ship issues with the software and being the ”go-to-guy” for something. IBM really gives you an environment where you can be proud of your work, and even though it’s a large corporate company they try to make sure you get recognition for your achievements and get out what you put into the company. I feel this is the most important quality that IBM embodies for their employees.

7 Career Plans

From working at IBM I have learned the advantages of working at a large corporation. IBM gave me access to an incredible amount of resources from certification courses, to weekly education sessions. The employees at IBM are very skilled at what they do and have expertise in each area of the business in which they operate. IBM has many different departments and while growing a career at this company you can see what life is like in other departments and switch to them if you find one you like. Working at a large company is a lot more stable than working at a small one. I met a lot of employees at IBM that have been there for over 10 years. Being a small cog in a large machine gives you a steady work pace and reasonable expectations for your future.

On the other end of the spectrum you are given a very specialized position and tend to only learn your small part of the full business in which you operate. The politics in a large corporation are not so noticeable to the interns because we lived in a small world but I’m sure being a regular employee this could be more of a problem. Making changes in a large business like IBM is slow, cumbersome, and very frustrating. Although IBM tries their hardest to give employees freedom to do what they want, it often crushes entrepreneurial spirit under the weight of bureaucracy and best practices.

Although I really enjoyed my time at IBM I felt there was something missing from not doing something for myself. I like being the master of my own destiny and I want to be a leader. I need to experience life at a smaller company before I decide my career path. As I get older I will lose more and more freedom, so I want to make sure to explore all my options before committing to a large company. I can see myself building a career at IBM and becoming a very important cog in their machine, but I think right out of school I will see what life is like in a smaller company, and if I excel in that environment first.

8 Conclusion

The PEY program has provided me with invaluable experience and knowledge. I grew a lot over the 16 months I spent at IBM and after stepping away from it I can see how effective of a machine it really is and why it is one of the most successful companies in the world. It has taught me many valuable skills and given me a real insight into how I want to grow my career.