Thoughts on first-round engineering interviews
Thoughts on first-round engineering interviews
Ideas to help both candidates and technical hiring managers
This is Part II of my 2-part mini-series about hiring and interviewing for Senior Engineers. Check out Part I: The D.E.N.N.I.S. system: Résumé tips for Senior Devs
I’ve been on both sides of the interview table - from a wobbling candidate, choking through disastrous answers, to a hiring manager ruthlessly grokking hundreds of potential team-mates.
I’ve seen countless CVs and conducted 100+ interviews for senior engineers - most frequently during intense post-fundraise hiring sprees at startups. This bursty experience drove me to iterate rapidly and fine-tune my techniques to detect top-tier tech talent.
The hard thing about first-round interviews is that it’s difficult to convey or determine a deep level of technical knowledge with words in a 30-minute interview.
You yourself might have experienced the excitement of a candidate who comes across brilliantly in their first interview, then the disappointment that follows when they fall flat on their face when asked to code FizzBuzz.
In this post, I’ll talk through some of the questions (and model answers!) that I’ve found effective in identifying strong candidates.
Think of it like prompt-engineering for job applicants!
Key Principles
Technical - understand deeply how your stack works
Communication - engage in discussions about trade-offs
Influence - leverage business context to drive decision-making
1. Technical
Technical knowledge, at senior levels, has to be deeper than operating your day-to-day toolkit. Getting under the hood and figuring out how stuff works moulds you into what teachyourselfcs.com calls a Type 1 engineer.
Hiring managers are keen to find these engineers - the kind that rolls up their sleeves to methodically solve a thorny problem vs the kind that spends days copy-pasting from StackOverflow to get a mysterious bug ‘working’ through trial and error.
Essentially, you want to show you understand what’s going on beneath the high-level abstraction of a framework or language:
The mechanics and design choices behind iOS mainstays like Grand Central Dispatch and Automatic Reference Counting, and the complexity they’re abstracting away
A working knowledge of performance characteristics of different data structures to select the right one for your problem - which could lead directly to a 50x improvement in execution speed
Grasping how SwiftUI’s layout engine is rendering views in response to data changes can remove the guesswork, ease your dependence on hot reloads, and allow you to rapidly squash the many visual bugs that crop up in SwiftUI (stay tuned for an upcoming article on this topic!).
Having this under-the-hood technical knowledge means that as soon as you run into these kinds of issues, you know exactly where to start - shaving about 90% off your problem solving time. This might be where the legend of the 10x engineer stems from.
Building up technical knowledge
Cultivating this skill is simple – stay curious.
WWDC talks are great resources; since the very engineers who designed the systems are sharing their insights - some of my recent favourites are Demystifying SwiftUI and Swift Concurrency: Behind the scenes.
Model answer
Q: You mentioned in your CV that you’ve been using SwiftUI professionally for the last 3 years. Can you tell me anything about how it works internally?
A: Sure! SwiftUI’s rendering engine is built on top of Apple’s established frameworks: Core Animation and Metal, which provide hardware-accelerated animation infrastructure and low-level GPU access, respectively.
SwiftUI organises views in a tree-like hierarchy, known as a view tree. Each view in SwiftUI is immutable and lightweight, which means they can be created and destroyed very quickly, and are cheap to allocate. When data changes, the rendering engine uses a diffing algorithm to redraw only those parts of the tree where data has changed.
However, this view diffing algorithm also means that the layout and rendering process applied on redraws can get costly if the views or view models are not designed efficiently - which is why it's important to keep views and view models compact and focused, which helps SwiftUI perform more efficient redraws.
2. Communication
For senior engineers, communication skills are the second critical pillar of first-round interviews. While general communication prowess is evident in a candidate's self-promotion, exploring technical trade-offs tells the hiring manager you’re thoughtful in how you apply your technical knowledge.
For example, less skilled engineers may dogmatically know to use final class and value types in Swift. However, great engineers will understand that their performance benefits stem from static method dispatch, as opposed to table dispatch. Explaining this to other engineers applies positive leverage over your entire team.
Developing communication skills
Learning about Method Dispatch in Swift was a great stepping stone in my own growth journey. I supplemented it with further blog posts and videos, then ran a lunch & learn with my team to spread the knowledge - and consolidate my own.
Model answer
Q: You mentioned on your CV that you led modularisation effort for your company’s app. What approach did you take, and what trade-offs were you making?
A: Single module apps are fine for small projects and teams, but as you scale up, issues can develop related to build times, interface design, and code ownership.
There are several approaches to consider. The basic, often transitionary, “Core” module refactoring; the Clean Architecture Layered style; or an approach combining feature modules on top of shared libraries.
My company was scaling rapidly with two separate product teams already working on the app. Therefore, we opted for feature modules with shared libraries. The downside to this architecture is the higher complexity, particularly around deciding where to draw interfaces for shared feature models and code.
This decision allowed us to seamlessly integrate a third product team; as well as a platform team who owned the shared libraries and dev tooling. Our architecture allowed teams to quickly familiarise themselves with the critical parts of the codebase and get productive.
Regarding implementation, Swift Package Manager, Cocoapods, and Carthage are the main choices. As we were a pure-Swift project, we opted for SPM to take advantage of native Xcode support.
3. Influence
The final leg of our interview barstool is to show your ability to influence decisions. If you’ve been reading my previous work on CV preparation, this covers Driving Initiatives and Impact is King.
You need to find out whether the candidate can put their money where their mouth is. You want to hire engineers who can effectively apply their deep technical knowledge; and their ability to reason about about trade offs; into making the right technical decisions for your business.
The Amazon CTO recently wrote: “Building evolvable software systems is a strategy, not a religion”. Creating great software isn’t about using the approach you know best; it’s about thinking about what approach is best for the business context - every business has different constraints, limitations, and strengths.
Model answer
Q: Can you please talk to me about a time you had to influence a technical decision? How did you navigate the situation?
A: In a recent proof-of-concept project for the UK police force, our team was tasked with developing an app to record crime information for auditing purposes, potentially used millions of times per day by officers in the field.
The team debated between a traditional REST API with a relational SQL backend and a GraphQL API on a NoSQL backend. Some team members and the client, who had a predominantly relational database stack, were hesitant about the NoSQL and GraphQL approach due to its hype.
I explained to the team and client that the decision should be based on the business context and requirements, not hype. Since officers in the field wouldn't have guaranteed network access, an offline-first approach with the automatic syncing provided by a proposed GraphQL client would expedite the proof-of-concept.
Additionally, the eventual read consistency between nodes offered by NoSQL's BASE properties was acceptable in this context since the data would be processed regularly for audit purposes instead of required instantly. The varying data structure required by officers made the schema-on-read feature of NoSQL databases more suitable compared to the inflexible schema-on-write offered by relational databases.
By leveraging my technical knowledge and communication skills, I convinced the team and client that the GraphQL with NoSQL approach would better suit the project requirements. This decision contributed to the successful and early completion of the proof of concept.
Conclusion
These principles build on each other as you become a more senior engineer.
Technical mastery leads you to understand concepts deeply. With a solid mental modal - and lots of practice - you nurture the ability to communicate the trade-offs that exist between potential solutions or architectures. Understanding the context of your own business, you are empowered to wield influence over decisions that shape the technical direction in the best way for your situation.
Oh, and lastly - before your interviews - please fix your mic.