comtech screening Flashcards
(9 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.
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 what drew you to apply for this role at ComTech Energy, especially given our focus on clean energy infrastructure.”
what really stood out to me was the direct connection between the software we’re building and its impact on clean energy.
I’ve been looking for a role where my coding skills could contribute to something more tangible than just increasing revenue or shareholder value.
The idea of working on embedded systems for a mobile refueler, for instance, is fascinating.
It’s a complex problem that requires a high standard of engineering and considetion of safety-critical operations.
The fact that the code I write could be running in a hazardous location, ensuring the safe and efficient delivery of clean fuel, is a powerful motivator.
I’m drawn to the immense challenge that it is, and I believe my background and experience would allow me to contribute greatly to that mission.
