Behavioral Questions (BQ) Top 10

1. Tell me about yourself.

• 1:30 minutes – 2 minutes
• Total number of years of experience as [ROLE] + major tech skills + summary of the most recent project & individual responsibilities in 2-3 sentences.
• Proper ending sentence: e.g., That is about me. I will be glad to answer any questions if you have.

Hi, I’m Bingying Liang, and I’m currently based in Philadelphia, Pennsylvania. It’s great to meet you, and I really appreciate you taking the time to chat with me today.

I have over three years of experience as a full-stack software engineer.

I’m currently working at Comcast on the XM360 platform, a microservices-based application used by Xfinity Mobile retail and telesales agents. I led the Reliability team across onshore and offshore teams, focusing on new feature delivery and production stability, and I am also a member of the pNPS team to resolve product-related issues and improve both agent and customer experience.On the frontend, the current project uses Angular. In the middleware layer, we use Kotlin with Spring Boot, and on the backend, we use Spring Boot–based microservices. I work in an Agile environment.

In the past few years, I worked in different companies and played roles related to the full-stack developers.

My primary language is Java.
For backend I am familiar with SpringBoot. For databases, I’ve also worked with both relational and non-relational databases like MySQL and MongoDB. For frontend, I am familiar with Angular. On top of that, I have hands-on experience with tools like Docker, Kafka, RabbitMQ, Jenkins, and AWS. For testing tools, I have used Junit, Mockito.

That is about me. I will be glad to answer any questions if you have. Thanks again for meeting with me.

2. Tell me about a challenging project you worked on.

• S（Situation）

  When I joined the Comcast XM360 project, it was already a five-year-old production system, so there was a lot of legacy code and business logic to understand. At the same time, I was leading a newly formed Reliability team. We also inherited around 20 existing pNPS production issues, and I was responsible for delivering a new feature called Standalone Watch.

• T（Task）

  So my main challenge was to deliver a new feature while also stabilizing production, even though I was still ramping up on a pretty complex, mature system.

• A（Action）

  What I did first was align with the Product Owner and Scrum Master to make sure priorities were clear. Since production issues were more urgent, we adjusted the plan so I could focus on the high-impact pNPS issues, while feature work was shared across the team.

  I also worked closely with an onshore engineer who had led the pNPS team before, which really helped me understand the system history faster. To stay organized, I set up a simple tracking sheet to group issues by severity and affected services, and then I tackled them one by one, sprint by sprint.

  Whenever I got stuck, I reached out early to upstream or downstream teams to confirm expected behavior, especially because changing a legacy system always comes with risk.

• R（Result）

  Within a few sprints, we delivered the Standalone Watch feature and cleared the transferred production issues. That noticeably improved system stability, and after that, new feature work became much smoother and more predictable.

• L（Learned）

  The biggest takeaway for me was that on a long-running system, you really need to respect the history, break big problems into smaller pieces, and keep communication tight—that’s how you move fast without breaking things.

3. Tell me about a time you had a conflict with a team member.

• S（Situation）

  I was working on a new feature called Plan 7.0, and one of the tickets was a Kotlin API integration. Before the grooming meeting, I reviewed the ticket carefully and felt that the requirements weren’t clear enough to start development. However, the solution designer believed the information was sufficient and suggested we move forward.

• T（Task）

  My responsibility was to deliver the Kotlin API integration on time, but at the same time, I needed to make sure I actually had enough information and that the backend API was ready—especially since I was still relatively new to Kotlin and other tickets depended on this integration.

• A（Action）

  Instead of pushing back emotionally, I tried to verify the gap objectively.

  I talked with teammates who had more experience with Kotlin and similar integration tickets to confirm what information was usually required.

  Then I scheduled a quick meeting with the solution designer to walk through the design together and clearly explain what was missing from a development point of view.

  During that discussion, I asked specific questions about API readiness, request and response contracts, and error handling. I also aligned with the Scrum Master on whether it made sense to start a draft implementation while waiting on the backend.

• R（Result）

  As a result, the solution designer confirmed with the backend team that the API was not ready yet. Since I had already prepared a draft PR and scaffolding, once the backend API became available, I was able to integrate it quickly and unblock the dependent tickets without delaying the sprint.

• L（Learned）

  This experience reinforced that conflict often comes from different assumptions, not disagreement. Clear communication, asking concrete technical questions, and validating concerns early can prevent rework and help the team move faster together.

4. Tell me about a time you failed. (讲一次你失败的经历)

Key Points: * Honesty: Pick a real, but not career-ending failure. * Ownership: Take responsibility. Don't make excuses. * Learning: Focus heavily on what you learned and how you improved your process/behavior to prevent it from happening again.

5. Why do you want to work here?

I’m really interested in [Company] because of both the product impact and the technical challenges behind it.

I started from the product side — I really like how [specific product / platform / user scenario] solves [specific problem]. When I looked deeper into the technology behind it, I realized there’s a strong overlap with what I’ve been working on, especially in [microservices / scalability / reliability / data / frontend-backend collaboration].

What excites me most is that [Company] is operating at a scale where engineering decisions truly matter, and I feel my background would allow me to contribute while continuing to grow as an engineer.

6. Describe a time you demonstrated leadership. (讲一次你展现领导力的经历)

Key Points: * Definition: Leadership isn't just management. It can be mentoring, driving a technical decision, or stepping up when things were ambiguous. * Example: Leading a migration, mentoring a junior dev, or organizing team process improvements.

7. How do you handle tight deadlines or pressure? (Google)

Tell me about a time you worked under pressure or a tight deadline

• S（Situation）

  In the middle of a sprint, our team received a high-priority QCI8 content change related to a plan update. I needed to update DocuSign content in the telesales flow, and the content was different for different user tiers.

  This change affected a key part of the XM360 shop flow, especially the last page. Because of security rules, the page couldn’t be refreshed many times, which made local testing and mocking difficult.

• T（Task）

  The sprint timeline didn’t change, so I needed to deliver the feature on time while keeping the code quality high. I also had to manage PR reviews and make sure QA could test the feature without blocking the sprint.

• A（Action）

  I first did a quick impact check and focused on the most important parts. I delegated first-round PR reviews to other team members and focused on the core implementation and second-round reviews myself.

  For testing, I used Kibana logs to find real accounts with different user tiers, tested the flow locally, and shared those accounts with QA. This helped them test faster and reduced back-and-forth.

• R（Result）

  I delivered the feature within the sprint, QA finished testing smoothly, and there were no major issues in the release.

• L（Learned）

  I learned that mid-sprint work needs clear readiness, estimates should include some buffer, and it’s important to push back if a ticket isn’t ready. As a senior engineer, protecting delivery quality and team pace is just as important as writing code.

8. Tell me about a time you received constructive feedback. (讲一次你收到建设性反馈的经历)

Key Points: * Receptiveness: Did you get defensive? (Hopefully not). * Action: How did you implement the feedback? * Growth: How has that feedback helped you improve since then?

9. Tell me about a time you had to learn a new technology quickly.

• S（Situation）

  Learning new things quickly is pretty common in my role. One example was when our team took on a new feature that required Kotlin API integration in the middleware layer. The service was built using the Netflix DGS framework to expose GraphQL APIs. At that time, I was the only person on the team who had access to the middleware repository, but I didn’t have much hands-on experience with Kotlin yet.

• T（Task）

  I needed to deliver the ticket within the sprint timeline. At the same time, there were multiple related tickets depending on the same Kotlin APIs, so I had to ramp up very quickly and make sure the implementation was solid.

• A（Action） I focused on learning just what I needed first. I started with basic Kotlin syntax using online resources to get familiar with the language. Then I looked through existing Kotlin services in our codebase and attended internal knowledge-sharing sessions to understand how the team was using Kotlin with DGS. I also scheduled quick syncs with engineers who had prior Kotlin experience to clarify best practices and project conventions. Instead of aiming for a perfect solution at the beginning, I built a working draft first, validated the flow end to end, and then asked for peer reviews to refine and improve the code.

• R（Result）

  I delivered the ticket on time, and the Kotlin integration worked smoothly. The implementation also unblocked other related tickets that depended on the same API.

• L（Learned）

  I learned that when time is tight, it’s important to aim for about 60% understanding first, get something working, and then iterate. Asking for help early and using available expertise is the fastest way to learn and deliver with confidence.

10. What are your greatest strengths and weaknesses? (你最大的优点和缺点是什么?)

Key Points: * Strength: Relevant to the job (e.g., problem-solving, fast learner, collaboration). Give an example. * Weakness: Real but manageable. Focus on "Work in Progress". Show what steps you are taking to improve it (e.g., "I used to struggle with public speaking, so I joined Toastmasters...").