# The Contra questions I participated in a few interview processes during my career and also conducted some more. It is, to me, a very exciting experience where I get to measure my knowledge and a way of gamifying the learning process. In my experience, most of the interviews where I was the answering party, were truly a trigger to either research some new tool or go deeper into what I already had experience in. But the best interviews I did were the ones I got asked about why NOT using X platform. *I am a Cloud Engineer, so most of my examples and quotes come from an Infrastructure background. But this article applies to any field to be fair.* # Traditionally > I have this setup, with these constraints and this expected performance; where do you recommend hosting this? Why? So one would go over the pros of a certain platform and why it is the best suited for the job. And that has value in itself, given a set of requirements, being able to identify and match strong arguments with the expected outcome is, at the end of the day, what makes a good solution. ## But what if you started with cons instead? > I have this setup, with these constraints and this expected performance. Where do you NOT recommend hosting this? Why is that? Can you tell me a couple of deal breakers of X platform? Every solution, platform, tool or any involved process depends on a specific use case. You wouldn't overcomplicate a solution just because it involves a buzzword. Right? Right? ![](https://media.giphy.com/media/dXFKDUolyLLi8gq6Cl/giphy.gif align="center") So maybe a good way of understanding how a platform would actually fit a given problem is what **not** to choose. It will show a couple of good traits. ### The Pros of the Cons * Deep analysis of the problem. * Weighing in the possible outcomes. * Trade-off discussion and affordable compromises. ## What makes this way valuable? If you can articulate against a few solutions, it shows you have the experience to compare different platforms, which not only demonstrates actual practical hands-on but also that you can discuss approaches and disadvantages to get closer to the best solution. # Example: Kubernetes ![](https://media.giphy.com/media/WsNbxuFkLi3IuGI9NU/giphy.gif align="center") Kubernetes is arguably the de facto platform to host and orchestrate most (containerised) applications. I'm not discovering anything. ## Is it technically applicable to anything? Sure, you can use it for 99% of modern use cases and it will just work. Even for a simple API serving a JSON response for a given product metadata? Of course, you can make it happen using a simple setup of required objects (a deployment, [secrets](https://hashnode.com/post/clheoq55700010akydtvd1073), and a couple more). > [Here](https://blog.mariano.cloud/helm-declaration-environments-helmfile)'s an example of a Kubernetes implementation using Helmfile, if you are feeling curious... ## But is it worth the overhead? For **every** use case? Certainly not. On the one hand, Kubernetes is excellent in a distributed environment, HA, autoscaling, resource management, security and 3rd party tools integration. Lots of documentation out there, everyone is using it, battle-tested, reliable and mature. On the other, it also introduces some questions that you will have to deal with and think about, naming a few: * Will you self-host it? Are you using any orchestrator, like Kind? Are you maintaining it yourself? Are you doing it in a cloud provider instead? * Have you considered the (additional) costs involved? * Have you planned a new deployment method? Are you willing to change your current one? * Is the practical knowledge already available in your team? ## Then why would you not use it? Well, if these sounds like your application: * Single instance, no need for high availability. * It serves atomic actions, with no interdependencies or moving parts. * Short-lived processing, no intensive computing requirements. And/or your team: * Does not have Kubernetes experience. * Has a somewhat short budget. Maybe you can consider other options to host your app. Serverless might be a good *candidate*. > Everything is a matter of your use case, completely constrained to your app and business requirements. # Conclusion If you have the chance to conduct an interview, maybe explore this approach. I am sure it will give you much richer information about someone else's experience. But you know, this is not only applicable to interviewing. And as a final takeout, do interviews. It keeps you up to date with the market and pushes your learning forward. It is also a great opportunity to discover new ways of doing things, a new technology you haven't used or new features of a tool you use daily and did not know (because every use case is different, remember?). > But also if you do, be prepared to consider an eventual offer - interview processes are ($$) costly and time-consuming for both parties, so please be mindful of others' work too. # References * The [STAR](https://capd.mit.edu/resources/the-star-method-for-behavioral-interviews/) method. * [The Socratic method](https://en.wikipedia.org/wiki/Socratic_method). --- Thank you for stopping by! Do you know other ways to do this? Please let me know in the comments, I always like to learn how to do things differently.