comtech screening Flashcards
(11 cards)
Tell me about yourself.
I’m a computer science grad from U of M with experience in software engineering, cybersecurity, as well as R&D.
Currently I am with Bass Pro Shops as an ETL Developer, where I am responsible for building and maintaining ETL pipelines, and also maintaining our Linux servers and SQL databases.
In the time that I’ve been here, I’ve been able to automate 70% of the manual reporting cycles, as well as improve the performance of our invoice processing by over 10x.
Before Bass Pro I was with the NRC, where my responsibility was to engineer solutions to allow our machines to interface with our database,
collect telemetry and timeseries data,
and assist with reporting and analysis.
Additionally, I spent one year with Public Safety Canada where I worked on intelligence analysis and full stack development using .NET and C#.
And finally, I spent one term with the Government of Manitoba working in cybersecurity and ETL development.
Tell me about your metal binder jetting project.
At the NRC, I worked on an R&D-focused project involving a metal binder jetting 3D printer used to create metal parts for manufacturing.
My responsibility was to engineer the data acquisition system that collected both static and time-series data to as part of our research on sustainable manufacturing.
The system captured static metadata like print speed, binder type, and powder material from the HMI.
We also logged temperature, humidity, and internal airflow, which we collected using a combination of Raspberry Pis and sensors.
Sensors would be polled on a fixed interval, and data was batched and pushed over Ethernet to an edge node, which handled staging and forwarding to a PostgreSQL database.
From there, I configured dataflows to PowerBI to allow our team to create reports and conduct analysis. One example of a report I created was a control board that showed operational logs of my pipelines, such as uptime, error alerts, and resource usage.
This system gave our team a reliable and automated data pipeline that directly supported material optimization experiments, improving the durability and sustainability of produced parts.
Tell me about a technical project you’re particularly proud of.
One project I’m especially proud of was one I finished with Bass Pro, where I completely redesigned our data infrastructure from the ground up.
When I joined, everything was running on Windows Task Scheduler through a virtual desktop—which meant no 24/7 availability and frequent failures.
Teams were spending hours manually pulling data and fixing reports.
I proposed a infrastructure rework and got approval from my manager and director and** led a migration to a modern stack**: Airflow on Linux, GCP for storage, dbt for modeling, and Snowflake as our warehouse.
As a result, we cut manual reporting by 70%, and improved job runtimes by more than 10x with my new pipelines.
It was a big leap forward in terms of scalability, reliability, and impact, and it’s something that the organization will make use of for many years.
Can you describe a time when you solved a difficult problem independently?
At Bass Pro, I noticed early on that our data infrastructure was holding the team back.
What stood out to me was the opportunity to elevate our organization and provide a significant impact.
I wasn’t asked to look into it, but I saw a chance to make a real technical leap forward for the organization. So I took it upon myself to explore how we could move to a more scalable, automated, and cloud-native solution.
I independently conducted a technical assessment of the system, identified bottlenecks, and developed a comprehensive proposal outlining a new architecture using Airflow, GCP, dbt, and Snowflake.
I made the case not just from a technical angle, but also in terms of long-term ROI—less manual work, faster data access, and greater reliability.
After presenting it to leadership, I got full support and was given full ownership of the project.
I led the entire rebuild, cooperating with on-site IT and US team cloud administrators and system engineers, and documented the entire process so that the system can be maintained for many years to come.
The result was a fully automated, production-grade data pipeline that cut manual work by 70%, ran 10x faster, and significantly increased trust in our data.
That experience really cemented my belief that great engineering is about taking initiative, spotting problems early, designing thoughtful solutions, and having the drive to see them through.
Tell me about a time you made a mistake—how did you handle it?
During my first position with the Government of Manitoba, I was responsible for developing a ** standalone software tool for filtering logs**.
I was excited to deliver functional code quickly, so I dove into development and focused heavily on getting it deployed.
The mistake I made was neglecting documentation entirely. By the time the tool was complete, it was clear that I was the only one who could fully understand or maintain it, unless someone sat down and read through every line of the code or came to me directly.
That obviously created friction for handoff, maintenance, and long-term usability.
Once I realized that, I went back, created detailed technical documentation, wrote a usage guide, and walked through the system with other engineers.
Additionally, I made it a core part of my engineering practice moving forward.
That experience taught me that writing code isn’t the end goal—software engineering, like building a bridge, requires planning, communication, and clear blueprints.
You wouldn’t build infrastructure by** just laying bricks without a plan**, and software is no different.
It’s one of the most important ways to ensure your work has long-term impact and provides scalability.
How do you approach debugging a complex system?
My approach always starts with understanding the system holistically before making any changes. I’ve learned that when dealing with complex systems, rushing to fix the surface issue often leads to unintended consequences.
For example, I once had to revise part of our invoiced sales pipeline, and on the surface, it seemed like a small logic change. But as I dug in, I realized that piece of logic was deeply interconnected—it was depended on by another part of the pipeline, which itself was tied into yet another module. A small tweak would have caused cascading issues downstream.
That experience taught me that diagnosing and understanding the system is often 80% of the solution. I now treat debugging like system mapping—I trace dependencies, isolate affected components, review logs and test cases, and try to simulate the issue in a controlled environment.
Describe a time you worked with cross-functional teams.
I’ve worked extensively with cross-functional teams throughout my career—collaborating with everyone from engineers and analysts to policy makers and finance teams.
One specific example is a project I led to build a software tool that historized promotional changes throughout the fiscal year.
The goal was to give the business better visibility into how promotions were evolving and affecting inventory and sales.
To deliver the right solution, I spoke with inventory managers, supply chain leads, and department heads. Each stakeholder had unique requirements—some cared about timing accuracy, others about pricing deltas or audit traceability.
I took the lead on requirements gathering, iterative design reviews, and making sure the technical implementation reflected the real-world needs of each group.
The result was a centralized, automated tool that gave teams a single source of truth for tracking promotions—saving time and improving decision-making across the board.
That project underscored how effective software comes from deep collaboration, and I enjoy being the person who translates business needs into technical solutions that work.
Have you ever disagreed with a teammate or stakeholder? How did you handle it?
I’ve been fortunate to work where disagreements rarely turn into conflict.
However, I did see a situation during my time at the NRC.
A research student got into a heated disagreement with a senior engineer over how to implement a section of ladder logic for our thermal test bench.
The disagreement escalated to the point where the student walked away from the conversation. I stepped in to speak with him privately—helping him calm down and understand that while technical differences are normal, our shared goal is to build great systems, not win arguments.
I reminded him that as students, we’re lucky to be here and our goal is to learn as much as we can. We need to respect their seniority and ownership if they want the final say in system design. After our conversation, he was able to return and work more constructively with the team.
What is your experience with Power BI, Grafana, or similar tools?
I have hands-on experience with Power BI and DOMO, primarily through my work at Bass Pro and during my time at the National Research Council.
At Bass Pro, I worked with both Power BI and DOMO to set up dataflows and semantic models that supported reporting for many teams across the organization.
This involved integrating transformed data from our cloud data warehouse and assisting analysts with building visuals
At NRC, I supported the setup of Power BI dataflows to streamline the analysis of telemetry and testing data, helping researchers identify trends and generate automated reports.
What is your experience with CI/CD and Git?
As a data engineer, DevOps responsibilities are often part of the role. I’ve used Git extensively for version control, including branching strategies, pull requests, and code reviews.
I’ve also contributed to production deployment processes that incorporate automated testing and validation steps to ensure reliability.
Tell me about your experience working with that test bench rig.
At the NRC, I also worked on a project involving our thermal test bench, which was used to evaluate the durability of 3D-printed metal materials by subjecting them to cycles of high heat and extreme cold.
My responsibility was to design and implement a system for cycle tracking, anomaly detection, and alerting.
Our team installed a PLC to monitor and log the timing and completion of each thermal cycle.
I used Modbus TCP to poll the PLC at intervals from an edge node.
If the system detected a deviation beyond a defined threshold—such as a heater failing to reach temperature within a safe time window— an alert was pushed to our Microsoft Teams channel using a webhook, ensuring the research team could respond quickly.
This system ensured quick detection of equipment failure, and prevented data contamination from invalid test runs.
