I'm wondering how are things with picking up new stuff? Usually I expect to learn a few new tricks at every job. E.g. I have no experience with microservices. Then, how does the company test if I can learn that? Suppose I want to learn about microservices, how do I teach it myself besides my job and family? Any book and tutorial can bring me to the beginner level, and then what?
The microservices could be anything else, like Erlang or machine learning. Still, it's unclear for me, how to test for some sort of general learning ability?
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.
Give the candidate a problem not in their area and see how they do with it while guiding them as a good teacher would—with a hands-off approach, seeing what they learn with each step.
This is how Sandia National Labs interviewed me as a college student. They asked straight up if I had any experience in parallel systems. Nope, I said. Then we went through some exercises to see how fast I could learn the material—how well I used the underpinnings of my undergrad and grad work to understand the problems he proposed to me. They were, I later found out, very simple, beginner level questions but ones I could not solve had I not been able to learn on the spot.
I got the job offer. I went with Amazon instead though, a decision I regret immensely, and not just because the interviews were so generic that I had no idea why they wanted me. Turns out they just wanted a cog.
Sandia wanted me because I could learn.
Life would have been different. And I'd probably be doing coding still, instead of burning out after a decade and turning to art.
Yeah I did the same Amazon, but I actually landed a good team at Amazon that would have helped me grow better. Though I took a chance at AWS to learn more. Worse decision for happiness.
Working at places that are way above your experience level does teach you new things quickly, but you don't really master them. Just cramming every day and having a half-assed skillset + burnout.
One of the problems is that the job market pushes you to make a choice quickly in sub 2 weeks (exploding offers). It really takes a while to figure out whats the best element, but then you get marked as a job hopper, etc etc.
AWS's issue was more that it tossed people at fires while needing to create long term solutions. Not that they never did so, it's just that there's something that resulted in them tossing devs into their oncall hell rapidly. My last position at Amazon was at AWS, and also the one that landed me in the hospital and prompted me to quit before the job literally killed me.
Ah Amazon. AWS was the worst. And I spent five years in the trenches of one of the most stressful areas of Ordering, and I still rate AWS as The Worst.
Yeah the on-call sucked, but I find the worse is that human compassion is only given to those who perform. If you are struggling and not "killing it" at all times, your manager doesn't offer a hand or suggest a transfer (until you hand in your 2 weeks).
Which is why I find this article relevant. Companies will hire to fill quotas / on-call bodies, but not all them vet or can vet everyone properly so as a candidate you can't even trust that the process is correct.
Gotta be prepared / have the confidence to quit within a weeks / month if it doesn't work out.
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.
I'm wondering how are things with picking up new stuff? Usually I expect to learn a few new tricks at every job. E.g. I have no experience with microservices. Then, how does the company test if I can learn that? Suppose I want to learn about microservices, how do I teach it myself besides my job and family? Any book and tutorial can bring me to the beginner level, and then what?
The microservices could be anything else, like Erlang or machine learning. Still, it's unclear for me, how to test for some sort of general learning ability?
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.
Give the candidate a problem not in their area and see how they do with it while guiding them as a good teacher would—with a hands-off approach, seeing what they learn with each step.
This is how Sandia National Labs interviewed me as a college student. They asked straight up if I had any experience in parallel systems. Nope, I said. Then we went through some exercises to see how fast I could learn the material—how well I used the underpinnings of my undergrad and grad work to understand the problems he proposed to me. They were, I later found out, very simple, beginner level questions but ones I could not solve had I not been able to learn on the spot.
I got the job offer. I went with Amazon instead though, a decision I regret immensely, and not just because the interviews were so generic that I had no idea why they wanted me. Turns out they just wanted a cog.
Sandia wanted me because I could learn.
Life would have been different. And I'd probably be doing coding still, instead of burning out after a decade and turning to art.
Yeah I did the same Amazon, but I actually landed a good team at Amazon that would have helped me grow better. Though I took a chance at AWS to learn more. Worse decision for happiness.
Working at places that are way above your experience level does teach you new things quickly, but you don't really master them. Just cramming every day and having a half-assed skillset + burnout.
One of the problems is that the job market pushes you to make a choice quickly in sub 2 weeks (exploding offers). It really takes a while to figure out whats the best element, but then you get marked as a job hopper, etc etc.
AWS's issue was more that it tossed people at fires while needing to create long term solutions. Not that they never did so, it's just that there's something that resulted in them tossing devs into their oncall hell rapidly. My last position at Amazon was at AWS, and also the one that landed me in the hospital and prompted me to quit before the job literally killed me.
Ah Amazon. AWS was the worst. And I spent five years in the trenches of one of the most stressful areas of Ordering, and I still rate AWS as The Worst.
Yeah the on-call sucked, but I find the worse is that human compassion is only given to those who perform. If you are struggling and not "killing it" at all times, your manager doesn't offer a hand or suggest a transfer (until you hand in your 2 weeks).
Which is why I find this article relevant. Companies will hire to fill quotas / on-call bodies, but not all them vet or can vet everyone properly so as a candidate you can't even trust that the process is correct.
Gotta be prepared / have the confidence to quit within a weeks / month if it doesn't work out.