Onsite interview 1/4. The first interviewer, 45 minutes, first asked about my resume, then it was an AI technical interview, since the role is technical marketing for AI Software. The interview had three parts.
Part 1: Deep Learning Fundamentals
Q1: In Machine Learning, what are the high-level trends happening at the framework level?
I answered with the evolution from numpy to PyTorch to Jax. He followed up asking about the difference between PyTorch and Jax. Three differences — 1) Python is numpy-like. Jax is more hardware-accelerator friendly — a compiler-driven approach — good for enabling exotic hardware.
Q2: What are the stages of a model from being defined to running on GPU?
The answer is frontend -> ONNX computation graph -> compile to GPU code.
Q3: What are optimization techniques in compilation?
Answer: kernel fusing, quantization. He then asked, are you familiar with data center hardware or edge hardware?
Part 2: Technical Marketing
Q1: I have a new technique, help me market it. What set of initial questions would you ask that team before you begin helping them draft a blog post?
I answered: have them provide benchmarks like latency and accuracy. He followed up: how do you convince the audience to adopt it?
Q2: What other aspect of the product does the developer care about? The answer is usability.
Q3: What question would you ask the engineer who said this new feature will improve usability?
Not just latency and other technical-level things, but software usability.
Example one, Netflix: 1) Effectiveness — can I complete the task, e.g. finding any TV series and watching it online. 2) Efficiency — how many clicks does it take me to find the video. 3) Satisfaction — NPS, qualitative interviews.
Example two, software like PyTorch: 1) Onboarding time — how many hours to deploy it. 2) Productivity — how much code reduction. 3) Reliability — how many crashes. 4) Satisfaction — NPS. 5) Adoption — how many active users per week? Do developers actually use it and request features?
Q4: What else can we blog about for a piece of software? The answer: 1) Observability — building a flame graph profiler. 2) Learnability — can I use the software without reading 400 pages of documentation. 3) Security — no leaking of training data.
Part 3: Should we compare against competitors?
Do you think an accelerator company should blog about how your software performs versus a competitor's, like AMD?
This was a killer question. I tried to say you could compare against your own previous version instead of comparing against competitors. He said he was just asking whether the company should compare against competitors at all.
Actually you could answer yes — 1) You have to be data-transparent and publish your methodology, to build developer trust. 2) It's not about saying AMD is worse, it's about saying Nvidia is faster on this, and if it can add brand value, then compare. 3) Legal sign-off, reproducible scripts, NDAs respected.
The interviewer's knowledge wasn't limited to compilers and Jax — he also asked about non-technical details like software design and user experience. It seems like this role isn't just an engineer, it's product-focused.
Discussion
Loading comments…