Note: Specifics of the projects in discussion will not be disclosed due to confidentiality


ABOUT MAGNET FORENSICS

“Seek Justice. Protect the Innocent.”

  Criminal investigations have transformed greatly over time due to the technological advances of society, placing a larger focus on digital elements such as location data, images, browser histories, instant messages, and email. Digital forensic labs were overwhelmed by the sheer amount of data that needed to be manually recovered from computers and mobile phones, and some of the most relevant data couldn’t be accessed at all.
  Starting in 2011, Magnet Forensics was launched with the purpose of revolutionizing the way investigators obtain and handle digital evidence. Now as a global leader in digital investigation software, with over 4,000 customers in over 100 countries, Magnet Forensics plays a crucial role in modernizing digital investigations. Recognized as one of the fast-growing Canadian companies in recent years, it has employees working in offices located around the world, including Waterloo, Ottawa, Atlanta, Singapore, and more, especially after merging with GrayShift and acquiring Griffeye in 2023, expanding the reach within the industry, and manifesting even further success.
  The company has firm roots in government and law enforcement, as well as helping agencies fight cyber enabled crimes such as human trafficking, child exploitation, and terrorism. In addition, organizations in telecommunications, technology, health care, and financial services have adopted their software to investigate important potential issues such as corporate fraud, employee misconduct, IP theft, and external threats such as ransomware, malware attacks, and business email compromise.


Magnet Forensics Website

JOB DESCRIPTION

  For the entire duration of my 8-month work term at Magnet Forensics, I worked on the Remote Acquire team, which is part of one of Magnet's main products, Magnet AXIOM Cyber. This particular feature of the product allows the user to monitor and acquire data from other machines remotely after deploying an agent to them, which can be useful in a variety of ways for organizations or investigators. For example, a feature exists to disguise the running agent process under a specified name, to ensure the user of the remote machine won't be suspicious. It helps organizations particularly to catch employees who are breaking rules, committing fraud, and more, helping to prevent damage to the company. Furthermore, the Remote Acquire team is just one of several teams that contribute to the overall AXIOM Cyber/Process product, and all teams work on separate parts of the application that are vital in different situations.
  Using Agile SCRUM methodologies for the first time since my short 2-month experience at NCR during my first work term, I worked on the Remote Acquire team, on which we called ourselves the "Sharks" for a multitude of loosely-connected reasons, as is on-brand with Magnet's refreshing and fun company culture. The team consisted of 5-7 developers including me, and 2-3 testers, with the team having some small changes throughout my time there. Using .NET/C#, with Workflows for the user interface, I was given the opportunity to contribute to the product's development, completing 2 medium-sized features, and one very large one. While I will discuss a particular feature that in which I had a very important role for my team, I will not be disclosing any more information about which features I worked-on for confidentiality purposes. Moreover, I applied my experience with C#, object-oriented design, git, JIRA, AWS, and more from my previous co-op placements and my education at the University of Guelph. After only a month or two into my term, I was told that I was working on-par with other developers on my team, if not above in some cases, as my experience and willingness to learn and improve had helped me to excel as a Magnet Remote Acquire developer. Also, I participated in a variety of formal meetings, such as stand-up, sprint retrospective, sprint planning, sprint demo, team health check, technical refinement, root cause analysis, and more, as well as informal meetings such as testing debriefs and troubleshooting sessions.



TOOLS AND TECHNOLOGIES

  While I learned to use a few new tools and technologies, this term mostly consisted of me improving my effectiveness at using tools I already knew, such as git, Jira, .NET/C#, and Slack. However, I used Miro much more extensively than before, using it in creative ways for technical refinement meetings to act as an interface for planning poker, as well as to organize ideas in brainstorm sessions, or to draw diagrams to explain concepts to the team. In addition, I also had some experience using Trello to keep track of specific tasks that the team wanted to get done in a certain time period, separate from our team Jira board that monitored our progress on the current sprint. One of the biggest changes to which I had to get accustomed was using Microsoft Visual Studio 2022, as I had only used Microsoft Visual Studio Code before. While VS Code is a lightweight text-editing application with many extensions to improve its usefulness for different things, Visual Studio Code is slightly different: it's a full IDE, with many more features built-in to support development in .NET/C#, which made coding on this team very smooth. Although, in the beginning, I was struggling since the keyboard shortcuts are different from those that are present in VS Code, but later I was shown that Visual Studio has a setting to map the keyboard shortcuts to the VS Code ones, which made it much easier. Other than that, Visual Studio was excellent to use every day, with its comprehensive building and running/debugging tools, and the ease of use for tracing through the code, which sometimes poses a challenge in object-oriented languages; being able to click on a function call and jump to the implementation code made traversing the code base a breeze. Moreover, I also got the opportunity to use a few new tools such as AnyDesk, and VNC Viewer, especially when working-on my large MacOS-related spike, as I needed to perform a remote connection to a Mac machine in order to do my investigation and testing. AnyDesk is a great, fast software for remote connection, while VNC Viewer seemed to be very slow, and at times unusable for this reason. Another new tool I learned to use was the Google Cloud Platform, as the product used Google Telemetry to track certain events happening during runtime, making it useful for testing and maintenance moving forward. Lastly, I also worked-on some tickets involving the team's automated UI testing, which utilized Test Studio; most people on my team weren't familiar with Test Studio, and it is difficult to work with since there are a limited number of licenses for the team, and only a couple people can be using it at the same time, as well as the fact that the automated tests could often be flaky due to the nature of automated UI tests. I learned that automated UI tests are not essential, and may even cause more work than necessary through my experience with Test Studio. However, it was still valuable to see how automated UI tests work; for instance, in Test Studio, it simply runs scripts that determine where the mouse cursor should click and which keyboard presses should be used in a sequence, which allowed our team to design scripted scenarios of common user flows within the application. In the end, I feel that I'm much more comfortable with fundamental tools and technologies that I will more than likely use again in my career again, such as .NET/C#, Jira, git, Slack, Visual Studio Code, and Miro, as well as others that I think enrich my work experience in a variety of ways, giving me insight into software development, like Test Studio, as well as opening my eyes to new possibilities that I had never thought of utilizing in software development before, like Google Telemetry.



WORK HIGHLIGHTS

  Throughout my term at Magnet Forensics, I gained a lot of insight on the industry as a whole, as well as honed my skills to become at the same level, or above the average junior developer, making my transition into the working world after I graduate to be smoother. Doing both frontend and backend work, and having to learn a brand new framework for coding the UI, with Workflows in .NET/C#, allowed me to also practice my ability to adapt on-the-fly and utilize my own research and experimentation to become effective and efficient with a new tool. By the end of the term, although most of my work was backend work, my familiarity with the UI organization system with Workflows increased each time I challenged myself to take-on a ticket that involved updating or adding to the UI. I was able to do somewhat complex frontend changes such as adding a new entry to the settings page, with a brand new format that allowed the user to browse for a certificate on their machine and keep it selected to be used througout the application, as well as simple changes like adding a checkbox and label to one of the screens. On the other hand, most of my work was creating and modifying classes in the code in order to accomplish the portion of the new features that I was tasked to do. For instance, I was able to create new functionality like allowing the user to select which certificate the application was to use, rather than using the default, which was also related to one of my UI changes that I previously mentioned. In addition, I had the opportunity to work-on multiple spikes, which I had never been assigned in my past work terms, and one of which was vital to the team's success for one of our new features, which I will discuss below. Overall, I challenged myself and took any change I could to take-on various tasks that required different skills so that I could really improve my ability as a software developer in my final co-op work term. I'm very appreciative of my team members for answering my many questions and of course allowing me to work-on the tickets that I wanted, rather than assigning me "easy" ones to do so that it wouldn't cause the team harm if I didn't meet expectations; their trust in me helped to push my learning to the next level, and as a result, I have gained extremely valuable experience with .NET/C#, Workflows, debuggers, AWS, and more.
  As I mentioned briefly, I worked-on a particular spike with one of my team members that paved-the-way for the rest of my team to complete the feature in a smooth and timely manner. What I can say about the feature is that it involved a great deal of primary investigation on many MacOS-specific processes and tools, and since nobody on my team had much experience with this operating system in general, there was no disadvantage to going into the spike not knowing anything. Consequently, with the encouragement of my manager, I decided to challenge myself, and take this on as my first spike in my career. However, the topic was large and complex enough that one of my team members was also assigned to the spike in order to try to speed-up the process, which worked-out well since her and I communicated our findings effectively and had many one-on-one discussions about what we were doing. Ultimately, after not even knowing if the requested feature for MacOS was possible, after the spike that I completed, we had a proof of concept ready, and presented it to the team, answering any questions, and then documenting all of our findings on our team wiki for future reference. Consequently, the research and investigation that I performed for the spike was vital in the team's great success in delivering this feature, as the release went very smoothly, and all of our customers were very pleased with it. In addition, it was an interesting role for me to take-on, since this was a large feature that took many sprints to complete, and for that entire duration, despite being a co-op, I was one of the main people on the team to answer questions about our plans for the MacOS feature, how it will work, and what won't work, etc. Having such an important role on my team for that significant part of my 8-month term felt very rewarding, and I undoubtedly learned quite a bit about MacOS and its security systems, which I'm sure will be useful knowledge for my career in software development in general.
  Another big highlight of my 8-month work term was my trip to Ottawa for a week during May, which was generously covered by the company. All members of my team who didn't live in Ottawa, with two being in Guelph including myself, one in Vancouver, and one in Calgary, were able to visit Ottawa for a week, with all expenses paid, in order to meet me, spend some time with the team in-person, and attend an Agile workshop organized by my manager. For a team that works remotely, getting some time to bond and meet in-person was invaluable for me, and I'm very appreciative of this experience. We got to tour downtown Ottawa, and go sight-seeing, as well as go out for dinners as a team. Regarding the workshop, the content was very helpful, as it allowed everyone to think differently and come-up with new ideas, and improve our current processes. For example, we learned about the proper ways to split tickets, which is known to be a difficult art in software development, and I believe that the team was noticeably better at doing so for the rest of my term. Also, we adjusted how we did our technical refinement to facilitate more participation as a product of that workshop, and speaking to other teams at Magnet about their processes, and it worked-out very well. I truly felt like part of the team, and I'm glad my manager organized this whole event during my term so that I could see Ottawa for the first time, get to work in the office there, and bond with all of my team members. While we had weekly hour-long meetings to play online games, which was always fun and something I looked forward to each week, being able to meet these friends in-person was well worth it.
  Throughout the 8-month term, Magnet allowed all co-ops to gather on every Thursday for a one-hour meeting to play online games and chat in a Microsoft Teams call, as an attempt to keep us connected with people in similar situations, who are also around the same age. As part of my own initiative, I created a private group chat for all co-ops to give everybody a chance to break-the-ice and become more comfortable with each other from the beginning of each 4-month term. Overall, it was a great program, because I made some friends as a result of these weekly social sessions, and I truly had a fun time de-stressing and laughing with the others. We usually ended-up playing Codenames with this group, which is a game I had not really played much before this term, but it was fun to learn!



GOALS

      LITERACY - Information Literacy: Improving Technical Vocabulary
      Goal
        I will learn new terms and abbreviations related to the software development process and various development tools to improve my technical vocabulary, so that I can more easily understand and contribute in technical conversations with my team, and any future teams.
      Action Plan
        My action plan is to record all unfamiliar words or phrases in a personal document, and either research them individually, or ask one of my teammates for an explanation, in order to define and understand each new word. I will also record the definition for each, so that I can fully understand, and consequently be able to utilize, each term or abbreviation in any meetings or presentations with my current software development team, as well as any future teams.
      Measure of Success
        My measure of success is the number of new terms that are in my list by the end of the work term; My goal is to create a list that contains at least 5 new words, as well as their definitions. Although I learned many new terms at my previous co-op placements, I believe that due to the difference in the tools and processes between the teams and companies, learning 5 new terms or abbreviations is a reasonable goal.
      Reflection
        By the end of my first 4 months in my new position, I have achieved my goal of learning 5 new terms/abbreviations used in software development, or at least at this particular company. The terms, which are detailed below, include the following: OKR (Objectives and Key Results), MVP (Minimum Viable Product), POC (Proof of Concept), XF (Cross-Functional) Technical Refinement, and more. Furthermore, I found it much less common to come-across new terms or abbreviations related to software development that I had not heard of before during this term; I believe that I have a pretty considerable technical vocabulary at this point, and while I still clearly have much to learn, it is also evident that I have come a long way since my first software development job in 2021.

      Terms and Definitions:
    • OKR:
      Objectives and Key Results - a term used mostly when having discussions with the product manager about the road-map, and more specifically, when narrowing-down what needs to be done, and in which order, for an upcoming epic.
    • MVP:
      Minimum Viable Product - refers to the product in a state where it is acceptable to be distributed to the users/clients, while only requiring the minimum amount of time and effort. This is usually important when trying to make a specific feature available to users as soon as possible in a working state, and then addressing the finer details after the official release, as it is not important to have all of the changes in before the release date.
    • Technical Refinement:
      The Agile ceremony in which the team spends time to think about the tickets in the backlog, determine the specifics of what needs to be done for each, and/or the effects of completing it, as well as assigning story points. Since assigning story points is important for team utilizing Agile scrum processes, and is undoubtedly one of the main reasons to hold this meeting each week, "Sizing" is a term that is commonly used as an alternative to Technical Refinement.
    • POC:
      Proof of Concept - used to describe the result of a technical investigation which acts as a kind of prototype, to verify that the original idea being proposed will actually work as in practice. For example, a detailed diagram or flowchart, or even a modified branch of the code that can be run and tested, can both be a proof of concept for a specific epic or story, as it simply proves that the idea is possible to implement. It avoids putting work into something that isn't possible, and also organizes an idea in a way that is easier for the team to understand.
    • XF:
      Cross-Functional - means that it falls under multiple teams or products or departments rather than just one. Involves people from different areas of the organization working as a team to achieve a common goal with their varied expertise.
    • Tech Debt:
      Short for "Technical Debt," is a type of ticket that can be worked-on, other than a story, spike, bug, or task. It usually is resultant from taking shortcuts, or pushing a concern back until later because the team wants the product to be ready for customers in-time, even if it means more work later to fix or improve it so that it matches the original plan for the feature. For example, a tech debt that could be created would be need to refactor some classes to be more easily unit-tested, since it was too close to the release day to both create the new class for the feature, and refactor the related classes as well.
    • FIPS-compliant:
      FIPS stands for "Federal Information Processing Standards," which is a set of standards that need to be met when developing certain products. Additional work goes into ensuring that the product is FIPS-compliant as it is updated over the years, since compliance means the product meets all the necessary security requirements established by the U.S. government for protecting sensitive information. In order to achieve this essential status for a product related to cyber security, a product must adhere to rigid standards, pass rigorous testing, and be certified by NIST (National Institute of Standards).
    • STS:
      Software, Tools, and Systems - an abbreviation commonly used for a team within the organization that is concerned with making the software developers' lives easier through DevOps (Development Operations). It increases the organization's ability to deliver applications and services faster than traditional software development processes. For example, the STS team would be in charge of a pipeline tool such as Jenkins, and setting-up an automatic pre-build system when creating a PR to make testing simpler and more efficient.

  1. CRITICAL & CREATIVE THINKING - Problem Solving: Updating Onboarding for Future Team Members
    Goal
      Over the course of my onboarding, I will improve the current onboarding instructions documentation by updating it as needed, and adding any necessary information for any new hires that will be using it in the near future.
    Action Plan
      As I go through the onboarding process, I will take notes, and address my concerns by updating the documentation with updated information, or helpful tips for future new hires. I will also be sure to ask my supervisor or mentor that I'm permitted to do so.
    Measure of Success
      I will consider this goal a success if I successfully make at least one addition to the Magnet developer onboarding wiki pages, in order to improve the clarity of the development environment setup process, and update anything that may show outdated or incorrect information.
    Reflection
      I have completed my goal, and even went beyond in this case. Not only did I improve the team's onboarding documentation during my first couple of weeks, as I was getting set-up, but also near the end of the first 4 month period. For example, I updated the documentation to reflect version changes in the team's work environment, as well as updated instructions to more closely resemble the updated UI of some of the interfaces that needed to be navigated to setup the developer work environment. Lastly, when I received an error that my Visual Studio 2022 IDE was to expire, and was told through my IT support request that I needed to install the IDE a specific way that was not documented in the onboarding wiki, I also added this information so that future hires wouldn't make the same mistake that I had. Overall, I believe that my contributions to the onboarding documentation will be very helpful to future new team members, and I will continue to update it when I can for the rest of my career.

  2. COMMUNICATING - Oral Communication: Learning More About Agile SCRUM Processes
    Goal
      I will learn more about Agile SCRUM processes, becoming more efficient and effective in Agile ceremonies, helping the team to have more effective discussions.
    Action Plan
      By participating in Agile ceremonies such as retrospectives, technical refinements, sprint plannings, and more, I will familiarize myself with the processes of SCRUM, and be able to contribute more to the team's output of work.
    Measure of Success
      As a measure of success, I will get feedback from my team member(s) at the end of the term regarding my effectiveness and reliability in technical refinements, including planning poker, as well as leading the discussion on an issue. I will also evaluate myself regarding how frequently my estimates in planning poker differ from the majority, and why. I will aim to have reasonable estimates in planning poker meetings at least 50% of the time, being able to estimate the amount of work in a ticket as effectively as the majority of my team.
    Reflection
      I have achieved my goal, as I've had the opportunity to gain considerable experience with the Agile SCRUM process, rather than Kanban, on the Remote Acquire team, and I believe that my abilities regarding planning poker and refinements has definitely improved. For example, over the past 2 planning poker sessions, I have had reasonable estimates, falling into the majority vote 6/8 times, with the other 2 instances being very close to the majority, and essentially interchangeable with the other option. I'm able to voice my opinion on why I believe my estimate is valid if it's not part of the majority, but I'm usually not required to do so since my estimates are commonly in-line with most of the team. In addition, during technical refinement sessions, I've continued to lead multiple discussions on tickets that need to be sized and refined, or at least contributing helpful information and notes to the ticket description in advance, receiving positive feedback from my supervisor in that regard. Moreover, I have evidently improvement my understanding of Agile SCRUM processes to the point where I am able to effectively contribute to the refinement discussions, as well as making thoughtful and reasonable estimates during planning poker sessions, but I will surely continue to improve my knowledge of this software development process so that I can apply it to any team that I may be a part of in the future.

  3. COMMUNICATING - Oral Communication: Leading More Meetings
    Goal
      I want to lead more presentations, demonstrations, and discussions as a professional software developer, whether it is within or outside of my own team in order to improve my further improve my oral communication skills, as well as my ability to present information clearly and efficiently in the software development field.
    Action Plan
      To achieve this goal, I plan to do demonstrations of any of the changes I worked-on that may be worth showing to the other teams in our regular sprint demo meetings, in addition to presenting findings and progress that are resultant from a spike/investigation task. I have never worked-on a spike before in my career, as spikes are usually assigned to senior developers. However, in some cases, when no team member has any real knowledge on a topic, it can be assigned to anyone. Judging by what I know about the future plans for my team's product, I believe that I will have an opportunity to be assigned a spike, and if not, I will ask my supervisor for an opportunity to do so. Additionally, due to the variety of my work, I believe that my changes to the product will, at some point, be reflected in a notable way that is worth presenting in the regular sprint demo meetings.
    Measure of Success
      I will measure my success by the completion of the following: completing my first spike and presenting the results, as well as presenting any notable changes to the product that I have influenced with my work in a sprint demo to other teams other than my own. I am aiming for at least one spike, and presenting in at least one sprint demo presentation, and with both of those completed, I will have achieved my initial goal.
    Reflection
      I completed a total of 3 spikes over the the remainder of the work term after setting this goal, as well as presenting in two sprint demos. Nonetheless, I believe I have achieved my goal in an outstanding fashion; however, I want to continue working on my presentation skills the future, as I think there is much improvement to be made regarding my performance in the mentioned sprint demo presentations. While my performance was acceptable, I would like to strive towards having impressive presentations to stand-out from my peers / team members.
  4. CRITICAL & CREATIVE THINKING - Depth & Breadth of Understanding: Honing Code Review Abilities
    Goal
      In order to improve my reliability and dependability as a team member, I will try to improve my ability to provide increasingly thorough and prompt code reviews. Usually, due to a lack of knowledge and experience, I will approve a code review without leaving any comments, but I want to try to ask questions or make comments more frequently, as well as take advantage of the code review tutorial that my supervisor had presented to the team in order to help determine what to look for when reviewing a team member's code.
    Action Plan
      On all code reviews, I will try to make at least one comment or ask at least one question about the code if possible, in order to improve my engagement in the review process. I will also go through the checklist of things to look for while reviewing code to ensure that I am being thorough. As a result of these practices, I believe that I will become more efficient in code reviews, while also learning more about specific code design decisions through my comments and questions, making me a more reliable and efficient reviewer.
    Measure of Success
      In order to measure my success, I will record the number of times that my code review reveals an issue that the developer had not realized. I will aim for making a notable review contribution at least 5 times by the end of the term, whether it is noticing a typo, or asking a question about something unclear that needs to be further investigated, such as a possible exception being thrown in a particular part of the code. I will also get an opinion from my supervisor and/or team members near the end of the term about my level of reliability in code reviews, and if it has seemed to improve over the term.
    Reflection
      Unfortunately, I was only able to make notable review contributions 4 times for the remainder of the term, not reaching my goal. However, when speaking with my supervisor and mentor on the topic, they both reassured me that my code review skills are not lacking, but I instead simply need more experience to be able to more frequently have something to add to code reviews in the future, whether it's because I have worked on something similar to what I'm looking at, or if it's because I know the codebase or programming language to a higher degree, and can consequently give some insightful advice. I will continue to work hard at improving my helpfulness with code reviews as I gain more experience in the future.
  5. PROFESSIONAL & ETHICAL BEHAVIOUR - Leadership: Becoming More Valuable in Technical Refinement
    Goal
      I want to be better at leading technical refinement sessions in particular, as it will be applicable to any Agile Scrum team on which I will work in the future. I also want to be more active in the discussions about other tickets being discussed by my team members to improve my dependability and value as a junior software developer.
    Action Plan
      To start, I will always make time to research the ticket I have been assigned before the technical refinement meeting, in order to offer more context and lead the discussion about the specifics of the requirements and the amount of work needed to complete the task at hand. Moreover, I will strive to never forget to do my preliminary research/homework on the topics, and always set aside time for it, which will help ensure that the discussion flows well. In addition, I will try to be more active in the discussions of other team members' assigned tickets, by offering opinions and ideas, and speaking-up rather than remaining quiet, whether it is providing some insight based on some knowledge I have that other team members do not, or simply affirming that I agree with the current acceptance criteria that has been laid-out.
    Measure of Success
       By counting the number of times I lead discussions in the technical refinement meetings, I will measure my success. I will aim to lead at least two ticket discussions per month during technical refinement sessions by the end of the term. I will also periodically, every month, ask for some feedback on my ability to lead discussions, in case my mentor or supervisor have ideas on how I can improve that skill. Ultimately, at the end of August, I want to be able to say that I have led two or more technical refinement discussions per month, and that my team members believe I can effectively lead a refinement discussion, as well as a full-time junior software developer can.
    Reflection
       I led discussions in the technical refinement meetings at least twice per month by the end of the term, reaching my initial goal. In terms of feedback from my team, they only had positive things to say, and agreed that I was at, or above, the level they would expect from a junior developer. However, I want to be more articulate with my words, which may come with experience, but also with practice. Moreover, I will continue to put myself in situations where I can practice leading discussions about technical topics in my career to improve this skill.


CONCLUSIONS

  Overall, I truly enjoyed my time at Magnet Forensics, both last summer, and this year, for a total of 12 months of experience working there. The company culture is fun, welcoming, and refreshing, making it a joy to work every day. In addition, the people on my team are so helpful and knowledgeable, that I never felt stuck or lost in my work. In this particular term, I learned a lot about the industry, as well as was able to improve my fundamental skills as a software developer, and I'm grateful for the experience Magnet has given me, as it will surely be an asset in my career moving forward. The mission of the organization is to "Seek Justice" and "Protect the Innocent," so there is something special about the work we do, as we know it will truly help people around the world. To emphasize this, Magnet even has regular company-wide meetings where we listen to testimonials about users of our products, and how it saved lives, or brought justice to criminals, and that makes all of the hard work that my team and I put-in so rewarding in the end, and always gives me an incentive to continue working hard and doing my best. The faith and generosity I was shown over the course of my work term is unlike anything I'd ever expect for a co-op student, and I wish the best for all of the people I had the privilege to work with, as well as the success of the company in their plan to maximize their grasp on the industry, but retain their wonderful culture.



ACKNOWLEDGEMENTS

I would like to thank the following people for making my 8-month co-op experience at Magnet so amazing, as I genuinely enjoyed working with each and every one of them, and they created an extremely welcoming and positive environment in which I was able to gain valuable experience as a developer:

MAGNET REMOTE ACQUIRE MANAGEMENT

SHARKS TEAM (my team)

OTHER

  • Andy Kwak - Senior Engineering Manager
  • John Tran - UX Designer
  • Rene Johannsen - Technical Support Analyst