Chris Ward

Head of Mobile Development Empowerment, 1&1 Mail and Media

Chris started coding life as a full-stack developer and moved between all sorts of weird and wonderful disciplines and industries before he settled on Android. In more recent years he moved into management, as both an EM and head of engineering for mobile teams. In addition to coding life, he's been an elected official in the UK, had a key role in legalising same-sex marriage in the UK through his LobbyALord app, and addressed the UN Human Rights Council in Geneva on atrocities against LGBT+ people abroad. He writes and speaks about his experience of being diagnosed with ADHD late in life and how he deals with the unique challenges neurodivergency brings to an individual working in tech. He lives in Berlin with his cat and his husband and has a mid-life-crisis friendship with crows.

Systems Design interviews for people who hate Systems Design interviews

For anyone who moved from being an Individual Contributor (IC) into Engineering Management, systems design interviews are a staple, effectively replacing the live-coding interview. However, there are an increasing number of interview processes where ICs find themselves faced with a full-stack systems design interview. If you’ve been a mobile developer all your career, being suddenly asked to outline the intricacies of individual microservices or to explain why you’d use a certain database paradigm over another can be an entirely new world. This is not a talk for people who hate systems design, but who find the vast potential scope and deeply varying expectations in systems design interviews difficult to overcome. If you thought coding challenges were subjective, wait until you’re doodling diagrams and outlining schemas on an online whiteboard. You can be rejected by one company for going into too much detail, and by another for being too high-level. One interviewer might be impressed with your attempt to delve into an area you don’t understand, whereas the next considers it a cardinal sin and expects you to simply say you don’t know. What you’ll (hopefully) take away from this talk: - How to prepare and which resources are especially useful for doing so. How to decide what to focus on in your preparation based on the role, the company and its product. - What to ask prior to the interview in terms of gleaning the expectations of your interviewer, and how to do it without worrying you sound like you’re asking for the answers. - How to ask the right questions and say the right things during the interview to ensure you’re not drifting astray from the interviewer’s expectations. - A short look into the minimum set of principals you should know that are common to most systems design interviews*. - Some concrete examples of traps Chris fell into, what he learned from them, and how you can avoid them. *NB. Please be aware that this won’t be a deep-dive into the intricacies of systems design itself - there simply wouldn’t be time for that - but we will go through some of the very common basic concepts that come up regularly. There are plenty of excellent resources out there that will help you deep-dive into those concepts, and they’ll be highlighted in the talk.