NVIDIA CUDA Software Stack Interview: CUDA Toolkit, Operator Adaptation, and Performance Tuning

Background

Let me start with my situation: 2 years of AI chip software stack development experience. Previously I worked at a domestic AI chip company doing operator adaptation and performance tuning, primarily writing operators in C++, and also worked with CANN (Huawei's AI computing architecture) and CUDA development. When I saw NVIDIA's CUDA software stack team hiring, I felt this was an opportunity to deeply participate in building the AI chip ecosystem and submitted my resume.

To be honest, I was both excited and nervous before the interview. Excited because CUDA is the industry standard for AI computing, and working on such a team would be tremendously beneficial for technical growth. Nervous because AI chip software stack development has a high barrier — you need to simultaneously understand hardware architecture and software optimization, and the interviewers' follow-up questions would certainly be very deep. Fortunately, I had accumulated practical experience at my previous company and was familiar with core work like operator adaptation and performance tuning. Let me walk through the interview process in detail.

Interview Process Review

Round 1: C++ + CUDA/CANN Fundamentals

The first-round interviewer was a senior systems software engineer. He started by discussing project experience, then moved into technical questions. First, he asked about C++ fundamentals — explaining the RAII principle and smart pointer implementation. I explained that RAII manages resources through object lifecycles — acquiring resources during construction and releasing them during destruction, with smart pointers being a classic RAII application. The interviewer followed up on unique_ptr implementation, asking me to hand-write a simplified version. I wrote move constructor and move assignment, deleting copy constructor and copy assignment.

Then came template metaprogramming — explaining SFINAE and type_traits usage. I explained that SFINAE means when template argument deduction fails, no error is thrown but other overloads are selected instead, and type_traits provides compile-time type checking tools. The interviewer asked me to use enable_if to implement a function that only works with integer types. I wrote: template>> void func(T t).

Then came the key part: CUDA/CANN fundamentals. The interviewer asked me to compare CUDA and CANN programming models. I explained that CUDA is NVIDIA's GPU programming platform with a SIMT (Single Instruction Multiple Threads) programming model featuring a grid/block/thread hierarchy; CANN is Huawei Ascend's AI computing architecture with an operator development + graph compilation programming model, featuring the Ascend C programming language and ACL (Ascend Computing Language) interface. The interviewer followed up on the difference between Ascend C and CUDA C. I said Ascend C is more vector-oriented programming where one core processes one data block, while CUDA C is more scalar-oriented where one thread processes one data element.

Next came Ascend AI processor architecture — explaining the core components of the Da Vinci architecture. I described AI Core as the compute core containing Cube Unit (matrix computation), Vector Unit (vector computation), and Scalar Unit (scalar control); AI CPU handling control flow and scalar computation; and DVPP handling image and video preprocessing. The interviewer followed up on Cube Unit's working principle. I explained it's similar to a systolic array that can perform efficient matrix multiplication — the core compute unit for deep learning inference.

He also asked about memory hierarchy, asking me to compare GPU and Ascend memory architectures. I said GPUs have global memory, shared memory, and registers; Ascend has HBM (global memory), L1 buffer (similar to shared memory), L0 buffer (similar to registers), and UB (Unified Buffer, data buffer for vector computation). Round 1 was about 65 minutes — comprehensive coverage of C++ and hardware architecture.

Round 2: Operator Adaptation + Performance Tuning

Round 2 was with the operator development team lead, more focused on practical operator adaptation and performance tuning capabilities. First, he asked about the operator adaptation process, asking me to walk through the complete adaptation pipeline from framework operators to hardware operators. I described several steps: analyzing framework operator semantics and computation logic → determining hardware-supported operator types → writing adaptation code (which may require operator splitting or fusion) → writing test cases to verify correctness → performance tuning.

The interviewer followed up on operator splitting scenarios. I explained that some framework operators don't have direct hardware implementations and need to be split into multiple hardware operators. For example, FlashAttention on Ascend might need to be split into a matmul + softmax + matmul combination. He then asked about operator fusion scenarios. I said multiple consecutive operators can be fused into one, reducing intermediate result memory read/write. For example, Conv+BN+ReLU can be fused into a single operator.

Then the focus shifted to performance tuning methodology. The interviewer asked: "How do you systematically perform performance tuning?" I described my tuning process: first profiling to identify bottlenecks (compute bottleneck or memory bottleneck) → analyzing bottleneck causes → selecting optimization strategies → implementing optimizations → verifying results. The interviewer asked me to detail profiling tool usage. I described Ascend's msprof tool, which can collect operator execution time, memory bandwidth utilization, compute unit utilization, and other metrics.

Next came specific optimization cases. The interviewer asked: "Suppose an operator has only 30% compute utilization — how would you optimize?" I analyzed possible causes: memory bandwidth bottleneck (data can't feed compute units fast enough), unreasonable operator tiling (some cores idle), unfriendly data layout (non-contiguous memory access). Corresponding optimization solutions: optimize data layout (NCHW→NC1HWC0), adjust tiling strategy, use double buffering to hide latency.

The interviewer was very interested in data layout, asking me to detail the 5D format NC1HWC0. I explained that Ascend's AI Core performs matrix computation at C0 granularity (typically 16), so the C dimension needs to be aligned to multiples of C0, with C1 = Ceil(C/C0). The 5D format allows Cube Unit to efficiently read data, avoiding non-contiguous memory access.

He also asked a practical scenario question: an LLM inference task on Ascend achieves only 60% of A100's performance — how would you analyze and optimize? I covered several dimensions: operator adaptation (are there unoptimized operators?), memory management (KV Cache memory utilization), compute scheduling (is Cube Unit fully utilized?), data layout (is the optimal format being used?). Round 2 was about 70 minutes — the most hardcore round.

Round 3: Project Deep Dive + System Design

Round 3 was with the Technical Director, a comprehensive assessment. First, he asked me to detail a previous operator adaptation project from the dimensions of background, challenges, solutions, and results. The interviewer asked many follow-up questions, like "What was the hardest operator adaptation you encountered?" "How did you verify adaptation correctness?" "How much performance improvement? Where's the bottleneck?"

Then came a system design question: design an operator library for an AI chip supporting multiple frameworks (PyTorch, TensorFlow, PaddlePaddle) and multiple model types (CV, NLP, recommendation). I designed the solution from several layers:

Operator layer: define unified operator interfaces, with each operator having a reference implementation (CPU) and optimized implementation (NPU/GPU). Adaptation layer: write adaptation plugins for each framework, mapping framework operators to operator library operators. Compilation layer: support operator fusion and graph optimization, generating efficient execution plans. Testing layer: automated precision verification and performance regression testing.

The interviewer followed up on operator interface design, asking me to define a generic operator base class. I designed OperatorBase with input/output descriptions (TensorDesc), attributes (Attrs), compute method (Compute), and shape inference method (InferShape). He then asked how to handle operator semantic differences across frameworks. I said we need to define a unified intermediate representation (IR) — framework operators are first converted to IR, then mapped from IR to hardware operators.

He also asked about distributed inference design — designing a system supporting multi-card inference. I described model parallelism (splitting the model across multiple cards) and data parallelism (multiple cards processing different requests) modes, plus pipeline parallelism design (splitting the model by layers across cards, forming a pipeline).

Finally, we discussed career planning and views on AI chip development. Round 3 was about 60 minutes. Overall, the interviewers were all very pragmatic — questions stemmed from actual work, not pure theory.

Key Questions Summary

1. RAII principle and smart pointer implementation, hand-write unique_ptr

2. SFINAE and type_traits, use enable_if for type constraints

3. Compare CUDA and CANN programming models

4. Difference between Ascend C and CUDA C

5. Core components of Ascend Da Vinci architecture

6. Cube Unit's working principle

7. Compare GPU and Ascend memory architectures

8. Complete operator adaptation pipeline

9. Operator splitting and operator fusion scenarios

10. Performance tuning methodology and profiling tools

11. Optimization approaches for low compute utilization

12. 5D data format NC1HWC0 principles

13. LLM inference performance optimization on Ascend

14. Design an operator library for an AI chip

15. Operator interface design and intermediate representation IR

16. How to handle operator semantic differences across frameworks

17. Distributed inference system design

18. Model parallelism, data parallelism, and pipeline parallelism design

Insights and Advice

1. Hardware architecture is foundational. Working on AI chip software stacks requires understanding the underlying hardware architecture and compute model. The interview will directly ask about Da Vinci architecture components, Cube Unit principles, and memory hierarchy — without hardware knowledge, it's hard to pass.

2. Operator adaptation requires hands-on experience. Reading documentation isn't enough. You must have done operator adaptation work yourself and understand the complete pipeline from framework operators to hardware operators. The interview will ask about specific adaptation cases — lacking practical experience puts you at a disadvantage.

3. Performance tuning needs methodology. You can't optimize by just trying things randomly. You need a systematic profiling → analysis → optimization → verification process. The interview will give you a performance problem scenario and ask you to analyze causes and propose optimization solutions.

4. Understand competitive differences. The interview will compare Ascend and NVIDIA differences. You need clear understanding across hardware architecture, programming models, and software ecosystem dimensions.

5. Pay attention to AI chip ecosystem development. The interview will discuss your views on the AI chip ecosystem. You need independent thinking and insights. This field is developing rapidly, and people with ideas are more valued.

FAQ

Q: Can I interview for this role without Ascend development experience?
A: Yes, but you need CUDA or other AI chip development experience. Interviewers will assess your learning ability and understanding of hardware programming. Ascend-specific knowledge can be learned after joining.

Q: Is there a big difference between Ascend and NVIDIA programming experiences?
A: Fairly significant. Ascend's programming model is more vectorized and data-block oriented, while NVIDIA is more thread-level programming. However, the core optimization thinking is similar — once you understand the hardware architecture, getting started isn't difficult.

Q: What's the work intensity like on the NVIDIA CUDA team?
A: From my interview experience, the team moves at a fast pace. After all, AI computing is highly competitive, and there's significant task pressure. But the technical atmosphere is great, which helps with technical growth.

Q: What are the career prospects for AI chip software stack development?
A: This is a very promising direction. AI chips are developing rapidly, and demand for software stack engineers is high. The technical barrier for this direction is high, compensation is competitive, and you can later move toward AI systems, chip architecture, and other directions.

Q: Will the interview ask algorithm questions?
A: Some, but they're not the focus. System design and engineering capability are more important. There might be 1-2 medium-difficulty questions, mainly to assess programming fundamentals.