Over the past years or so I has the chance to speak with some developers from many different areas and countries. After all those talks and some introspection I came with the conclusion that programming usually involves 6 aspects to varying degrees.
These aspects are in no particular order:
Enterprise applications based jobs usually focus a lot on architecture and software design. But also on technologies related stuff like ORMs or frameworks. They can also imply high performance related things in case you need to make sure that the application can process a lot of requests per second or in any other time interval. And finally they can depend on a lot of logic stuff because they usually have complex processes and a lot of business logic.
Some aspects mentioned above are much harder to gauge and prove during an interview. How can you explain and demonstrate to someone that you have a good logical mind and you are good with logical stuff? How can you prove to him that you can manage a lot of details which are tightly bounded together in your head? This is one thing that a lot of interviewers get wrong from my perspective.
Other aspects like technologies can be easily proven during an interview. But they aren't always relevant. You might have been an expert in a technology at some point in time but if you haven't used it for some time you will most surely become rusted and may have forgotten a lot of things about it. I think a lot of companies put way too much emphasis on how many technologies someone knows without asking themselves these questions: are they a fast learner or are the technologies that we want to use that hard to learn? Or did the interviewee use a similar technology having some experience in it that can be translated back to the one we want to use?
And on the other hand some important aspects like architecture and software design aren't emphasized enough during an interview. This is especially true for big applications which are developed over the course of several years. I have seen it in myself. I still have trouble making maintainable pieces of code sometimes. And I also noticed it in other people too that are really good with technologies and logic related stuff but very bad when it comes to making a maintainable application on which several people can work without trouble. But again, software design and architecture are really hard to prove and to gauge during an interview. At least to me.
Big famous companies put a lot of accent on the algorithm and high performance things. Also they focus a lot on the science stuff. Why do they require these things? Because they are mostly focused on innovation to attract as many people as possible to their products and their company. I kind of noticed this first hand. Some of them are even trying to create new market segments with new kinds of products like virtual reality glasses and so on. I still think this is a mistake on their behalf. They want creative people to come up with ideas but during their interviews they test you if you only can come up with their specific idea which they consider the best. How can you bring someone with new ideas if you filter them from the beginning to have the same ideas as you?
Now at work I mostly focus on the things I like the most: software design and architecture coupled with logic. We have some pretty complex processes that the client explicitly demanded with a lot of small details. And we have to take into account tens or even a couple of hundreds of small parameters. And there are many functionalities that are tightly bounded and need to work together because the client wanted them like that. The end users that our client is trying to satisfy needs these intricate functionalities. So you can't just say that's it's our fault for everything being tightly coupled together because the client wanted them like this. And you can't tell the client you know better because the application is from a completely different domain that most programmers are not familiar with and can't say anything useful and accurate about it.
To do some things you might have to be good in 2 or more aspects mentioned above. For example, a lead developer might need to be good in the logical stuff and the architecture/design stuff. He needs to know how to design a piece of software to be easy to develop and maintain. Also he how to describe and implement a process to build that piece of software which is closely related to the logic stuff. Some designs might be harder to implement than others and might take longer. Some designs can't be implemented by more developers at once easily.
These aspects also come into play during interviews. Bad things happen when there is a great mismatch between the interviewer and interviewee when they don't agree on the same aspects. Even at the same aspect level disagreements can happen often. It's why you see some amazing people that did something amazing get rejected at interviews. They are rejected because of a misfit not because he doesn't know anything.You can't be good at every aspect and most of them are quite complex. You can be good only on a subset of things from one of these. I think there are a lot of misunderstandings here.
These aspects are in no particular order:
- Technologies: This relates to what technologies you use at your job. Some jobs require that you know in depth because most of them have their quirks and pitfalls. Or maybe they are hard to to learn or use in general. Usually I would include here stuff like programming languages, database types, various ORMs, IDEs, frameworks and prebuilt libraries to make your life easier. This doesn't really involve a lot of creativity and thinking but rather knowledge. You don't really need an innate ability and talent for these things. Just curiosity.
- Architecture/Software design: This is related more to object oriented programming and how you structure your code into various modules and components. It is related to how easy an application is to maintain and extend with new functionalities. Or how easy it is to write unit tests for it and test it in general. Or how easy is to split the work for multiple people to work on the project at the same time.It also implies how easily is for other developers to understand how the application works and how it does what it does. You really need to have a knack for these things and some innate ability.
- Algorithms/High performance stuff: I grouped these 2 together because they are tightly bound together. Usually this means you have a very high volume of information or data that you need to process in a short amount of time. Or you need to write real time application that need to respond very fast to user interaction and input. Or you are developing something in a constrained environment with limited resources. This is similar to the logical stuff but the difficulty here is that what the client wants the application to do seems simple to him but very hard to get a computer to do. Usually you have to create some kind of process from scratch and take an indirect approach. The client does not provide you with anything about the process. It can't me mapped directly to a simple piece of code. You need some in depth translation from the client's thoughts and into a computer program that does what the client wants. And it usually results in a complicated process. And proving that the process does exactly what the client wants is another issue. You need to know some concepts here and some creativity. But you can also compensate through a lot of work.
- Logic/Business logic related stuff: This means that you need to execute and manage a lot of complex and intricate processes and functionalities. This is especially true if you have an application with a lot of complex business logic. You also need to get them to work together properly. Usually when you need to make diagrams to understand what and how your application does some things you have landed in this territory. You also need to manage all these complex processes somehow in your mind. You have a lot of details that you need to take into account when making some changes or implementing something new. You also have to always be careful not to break anything which is very easy to do. It is similar to the algorithm related stuff. The difference is that the client wants to do something in a complicated process that he directly explains to you. He is partly responsible for coming up with the process that the computer needs to do. This translates directly into complicated business logic.
- UI/UX related stuff: This related mostly to how user interacts with your application and how the content is presented to the user. Usually there are separate people that do this, but not all projects have these sort of people and you get to do this stuff too. Or at least as a developer you need to validate if a design or use case fits with the business logic. Or if they are feasible to implement and make sense. In some cases it is hard to get the application to present itself to the user in a certain way or to actually make the application respect the use cases or to enable it to be used the way the end user wants it to.
- Science: This includes stuff like machine learning and AI stuff. It usually involves pushing existing concepts to new heights or even coming up with new concepts. A lot of times it involves mathematics or even physics. It usually means studying an existing problem, coming up with a solution and analyzing it but in a more scientific way like in research journals for example. It might involve some other aspects mentioned above but you really try to take them to the next level or actually invent something new related to them. Usually this aspect is heavily related to innovation.Here you probably need innate ability the most but also hard work too.
Enterprise applications based jobs usually focus a lot on architecture and software design. But also on technologies related stuff like ORMs or frameworks. They can also imply high performance related things in case you need to make sure that the application can process a lot of requests per second or in any other time interval. And finally they can depend on a lot of logic stuff because they usually have complex processes and a lot of business logic.
Some aspects mentioned above are much harder to gauge and prove during an interview. How can you explain and demonstrate to someone that you have a good logical mind and you are good with logical stuff? How can you prove to him that you can manage a lot of details which are tightly bounded together in your head? This is one thing that a lot of interviewers get wrong from my perspective.
Other aspects like technologies can be easily proven during an interview. But they aren't always relevant. You might have been an expert in a technology at some point in time but if you haven't used it for some time you will most surely become rusted and may have forgotten a lot of things about it. I think a lot of companies put way too much emphasis on how many technologies someone knows without asking themselves these questions: are they a fast learner or are the technologies that we want to use that hard to learn? Or did the interviewee use a similar technology having some experience in it that can be translated back to the one we want to use?
And on the other hand some important aspects like architecture and software design aren't emphasized enough during an interview. This is especially true for big applications which are developed over the course of several years. I have seen it in myself. I still have trouble making maintainable pieces of code sometimes. And I also noticed it in other people too that are really good with technologies and logic related stuff but very bad when it comes to making a maintainable application on which several people can work without trouble. But again, software design and architecture are really hard to prove and to gauge during an interview. At least to me.
Big famous companies put a lot of accent on the algorithm and high performance things. Also they focus a lot on the science stuff. Why do they require these things? Because they are mostly focused on innovation to attract as many people as possible to their products and their company. I kind of noticed this first hand. Some of them are even trying to create new market segments with new kinds of products like virtual reality glasses and so on. I still think this is a mistake on their behalf. They want creative people to come up with ideas but during their interviews they test you if you only can come up with their specific idea which they consider the best. How can you bring someone with new ideas if you filter them from the beginning to have the same ideas as you?
Now at work I mostly focus on the things I like the most: software design and architecture coupled with logic. We have some pretty complex processes that the client explicitly demanded with a lot of small details. And we have to take into account tens or even a couple of hundreds of small parameters. And there are many functionalities that are tightly bounded and need to work together because the client wanted them like that. The end users that our client is trying to satisfy needs these intricate functionalities. So you can't just say that's it's our fault for everything being tightly coupled together because the client wanted them like this. And you can't tell the client you know better because the application is from a completely different domain that most programmers are not familiar with and can't say anything useful and accurate about it.
To do some things you might have to be good in 2 or more aspects mentioned above. For example, a lead developer might need to be good in the logical stuff and the architecture/design stuff. He needs to know how to design a piece of software to be easy to develop and maintain. Also he how to describe and implement a process to build that piece of software which is closely related to the logic stuff. Some designs might be harder to implement than others and might take longer. Some designs can't be implemented by more developers at once easily.
These aspects also come into play during interviews. Bad things happen when there is a great mismatch between the interviewer and interviewee when they don't agree on the same aspects. Even at the same aspect level disagreements can happen often. It's why you see some amazing people that did something amazing get rejected at interviews. They are rejected because of a misfit not because he doesn't know anything.You can't be good at every aspect and most of them are quite complex. You can be good only on a subset of things from one of these. I think there are a lot of misunderstandings here.
Comments
Post a Comment