Beekey Cheung is a software engineer with a large amount of enthusiasm for economics and a passion for education. He loves mentoring other programmers and is currently building an application to te...
The way that's worked for me when conducting interviews is to ask open ended design questions (e.g. how to scale a web application, how to implement asynchronous workflows with multiple dependencies, implementing an API for a sample service, etc). No matter what the candidate says, there's always something I can think of that will cause things to not go according to plan. How a candidate adapts to the situation says a lot.
Do they get frustrated when they don't know something? It'll be more frustrating when production systems are having issues than in an interview.
What kind of questions will they ask? Can't Google the answer if you don't know the question.
What are their theories for solutions? This is the best indicator I have for knowing what it's like to work with a person if they're hired. If we can have productive discussions in an interview, then we can have productive discussions when implementing things.
As for micro-services specifically, I have a few things to say. The first is that I have met more people talk about micro-services than I have people who have had experience implementing micro-services. At the moment, just reading about it will put you at the same footing as most devs I think.
The second is that most software design patterns that we use for writing code are also applicable at a much larger scale. You generally want to structure code so that related functionality are grouped together. With micro-services you are taking it to another level so that related code is not even on the same repository or running on the same machine as unrelated code.
Lastly, some things are hard if not impossible to do on your own. You can implement micro-services by yourself as a side project. However, you won't be able to see how the design decisions you made with those services will fare with an organization of 30+ developers. You also won't see how those services will hold up with a million users and hundreds of requests per second. Most of the challenges in micro-services are scaling that development.
I think that's why I always advocate taking a job where you will learn what you want to learn. The benefits from a high paying job will only last so long as you have that job. The benefits from a high learning job will last the rest of your career, which will also open up even more high paying positions later on.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The way that's worked for me when conducting interviews is to ask open ended design questions (e.g. how to scale a web application, how to implement asynchronous workflows with multiple dependencies, implementing an API for a sample service, etc). No matter what the candidate says, there's always something I can think of that will cause things to not go according to plan. How a candidate adapts to the situation says a lot.
Do they get frustrated when they don't know something? It'll be more frustrating when production systems are having issues than in an interview.
What kind of questions will they ask? Can't Google the answer if you don't know the question.
What are their theories for solutions? This is the best indicator I have for knowing what it's like to work with a person if they're hired. If we can have productive discussions in an interview, then we can have productive discussions when implementing things.
As for micro-services specifically, I have a few things to say. The first is that I have met more people talk about micro-services than I have people who have had experience implementing micro-services. At the moment, just reading about it will put you at the same footing as most devs I think.
The second is that most software design patterns that we use for writing code are also applicable at a much larger scale. You generally want to structure code so that related functionality are grouped together. With micro-services you are taking it to another level so that related code is not even on the same repository or running on the same machine as unrelated code.
Lastly, some things are hard if not impossible to do on your own. You can implement micro-services by yourself as a side project. However, you won't be able to see how the design decisions you made with those services will fare with an organization of 30+ developers. You also won't see how those services will hold up with a million users and hundreds of requests per second. Most of the challenges in micro-services are scaling that development.
I think that's why I always advocate taking a job where you will learn what you want to learn. The benefits from a high paying job will only last so long as you have that job. The benefits from a high learning job will last the rest of your career, which will also open up even more high paying positions later on.