The job interview is a stressful situation, usually for both parties. Some time ago, I had to recruit senior developers. I had the idea to ask a set of elementary questions. That type of question you get the solution in the first link after googling about the technology. I hoped that the interviewees would answer them and feel more relaxed, and better show their knowledge when asked more complex questions. You can probably guess where I am going with it: most of those people failed on those basic questions.
Recently, self-help books and biographies have become popular. I don’t read too many of them. I have the impression that there is too much promotion of authors and not enough specific recipes. I prefer good fiction books such as “To Kill a Mockingbird”, “1984”, “Cat’s Cradle”. I believe that you can learn more about life from them than from guidebooks. Some time ago, I decided that maybe it’s time to catch up and check if I’m not mistaken. I managed to find some valuable ones like Atomic Habits or Company of One. However, for most others, I believe that if they were condensed into a longer blog post, they would have much more value than the artificially packed books.
One such book is “Mindset: The New Psychology of Success” by Carol Dweck. For over 200 pages, the author in many ways grinds her theory that people can be divided into two mindsets:
Roughly speaking, fixed mindset people believe that every human being has an inborn set of abilities. They think that if you achieve something, you have a talent for that. Otherwise, you just don’t. They think you are unlikely to change if you don’t have the natural skillset.
People with growth mindset believe that everything can be improved and developed.
- “What do you have to do to play Carnegie Hall?”
- “Practice a lot”.
Of course, they are not dreamers who believe that they can always succeed. They just think that if you work on something regularly, you will be better at it (which coincides with the message of the book mentioned above Atomic Habits). Routine and practice can build your skillset. All 200 pages can be summarised in that paragraph.
Why am I writing about this? There is an interesting observation in the book about people who are “fixed”. If they achieve some level of success, they will want to keep it. What’s wrong with that is the way they will try to do it. People with a “fixed mindset” are terrified of making a mistake. They worry that when others notice that, then they will lose their top-level position. They focus on not being exposed as a fraud. So they will avoid the risk at all cost. They won’t take the opportunity to go beyond the zone where they feel confident because it may appear that they’re not good enough. It may turn out that they have no talent and “all is lost”.
This approach is popular in enterprise corporations. There is no reward for good, just punishment for bad. The only sure strategy is to do nothing. Then you are minimising the chance of doing something wrong and getting a penalty.
I also recently read an article “Why Senior Engineers Hate Coding Interviews”. The author writes why “seniors” do not like to do technical exercises. I would even further and say that they are not keen to answer questions about the technical details.
In my blog post, which I blatantly called “Architect manifesto”, I stated that architects should be active programmers. They should be working on the architecture they designed. Architects should get their hands dirty with the code along with the team.
Quite often, our projects’ “organisational culture” (or, in fact, the lack of it) requires frequent meetings, e-mails, Excel spreadsheets. We’re doing Meeting-Driven-Development and E-Mail Oriented Programming. Quite often, programmers fall into this vicious circle and don’t have time for coding, especially experienced ones.
Nevertheless, is this the only reason why senior programmers and architects don’t want to code? Do they really have such essential tasks always that they can’t sit down and write a few lines of code? Why is adding a form in the UI such a big detraction? Why is it such a problem to add the CRUD endpoint or table? Why do they not want to “waste their time on such simple things”?
I think that each of us had the moment when we thought about getting hands-on helping to deliver some feature. Then we realised that “I have no idea how to style this component” or “How the hell do I do validation in this endpoint?!”. Then many of us were afraid to ask others and admit that we don’t know something. How do we react in this situation? Are we “fixed” and defend our base by taking on “another urgent task”? Or are we focused on growth and ask a junior for help with CSS?