How I got a job at the Stack Exchange

About a month ago, I found myself talking to a video link with Joel Spolsky (co-founder of Stack Overflow - approx. Transl.). Even now it seems absurd to write like that. For a long time, throughout my career, I read Joel Spolsky regularly, and in many respects I agreed with him on development views. And suddenly I talk face to face.

To achieve this conversation was far from easy. The process took several weeks, and, frankly, it was difficult to find time for the passage of so many interviews. How many, you ask?

Before Joel, I spoke to 5 or 6 other amazing people (including Marc Gravell and Nicholas Larsen). Somehow I managed to make enough impression on each of them to get to the final boss. The conversation lasted about an hour, and for me, flew in 5 minutes - probably because of the excitement. We discussed the pros and cons of various software development methodologies, our past career mistakes, some of the problems of Dache (my open source cache), and a couple of other topics. Then Joel said something amazing: “Join us at the Stack Exchange!” At that moment I felt such a strong adrenaline rush that I could lift the car with my bare hands.
')
A few days later I officially began work. I am glad of this opportunity and I think that I was very lucky. Until now, Stack Exchange has established itself as an incredibly qualified and professional organization that treats employees as people, not as expendable resources, and I have already managed to fall in love with the local customs of communication with colleagues.

IMPORTANT: First of all, the stated position is exclusively mine, and not the Stack Exchange, or third parties. The article provides thoughts on the interview process, as well as on the specifics of my knowledge and professional path that helped me get this job. This is not a "cover breaking", or a hint that makes it easier. If you want to work here, you will have to pass the same tests (the details of which I will not disclose) that I passed.

With this reservation, here are my thoughts on how I got the job in the Stack Exchange, and how you can do this:

The ego is the killer of the mind, so kill the ego. Most developers (including myself - the former) have a massive "I". Their ego is so big that it barely fits in the room. This is natural, given the fact that we create whole days of bringing in a solid income things of divine quality literally from nothing. We begin to feel very powerful. Having thoroughly studied the technological stack of the company, we conclude that we know everything about any software and hardware.

To think that you know everything is the easiest way to screw up as a programmer. Believing in this, you no longer study the novelties (you already know them). While you masterfully mastered ASP.NET MVC 3 at the current place of work, the 4th and then the 5th versions of the framework came out ... that's just your company will not upgrade, because this is too risky and therefore you will never learn the new version. After a couple of years, you will be so far behind modern technology that you cannot even see them through binoculars. By the way, I mentioned those things - Ruby and PHP, or even Java, on which you never wrote a single line? What about MongoDB, Couchbase, Azure, EC2, and thousands of other platforms and programming languages? I hope you now understand that your knowledge of languages ​​and hardware configurations is a drop in the ocean ... maybe 0.1% of all knowledge about development. I know as much, and that's fine.

Don't be a rock star. I have been doing this for several years, which only hurt my career. Many companies deliberately feed the ego of their employees so that they feel valuable (often without adequate payment). Being a rock star sounds great, but in reality it is a risky strategy that can create an incredibly explosive atmosphere in a team. Companies are looking for and hiring rock stars, and rock stars take it for granted. They fan their “selves” and arrogantly argue at meetings, interrupting and pushing others apart. They reason in the spirit of “I am right because you are wrong, because I am right.” The rock star is convinced: the rest exist to indulge his whims ... while the rest hate working with such a person.

The fact is that you can actually be one, one in a million, a great developer, a "rock star" - but nobody cares. Words cost nothing, and people will say almost anything to make the right impression on a person. Even if you are really good - talking to people only about this and nothing else will make them despise you. A good developer does not need to brag, his results will speak for themselves more eloquently than any words. Naturally, others will appreciate such a person. Idle talk on the topic “wow, he's very smart” or “she managed in an hour, and we thought it would take a few days” will get stronger, which is not bad. Let people say whatever they like about you, but keep modesty and a sense of realism. You may be the best developer in a team or even a company, but you are still a person and you are still at work. Nobody here was hired to serve your ego (even those whose daily duties are working for you). The fact that you are a good developer does not make you better as a person; it just makes your career more successful. Never forget that thousands of other developers also shine in their workstations. From their total number - an excellent and modest developer will be able to stand out. This is a very rare combination in my experience, and the ultimate dream for hiring in many companies. Even if you are the best (which is cool!) Of all, stop bragging around. They don't care how you should be.

Know that you know enough to understand the limitations of your knowledge . Be aware of what you know and what you do not. Never be afraid to say “I don't know” when it’s true. A developer who is not afraid to say: “I don't know” in front of a room full of people is a rarity. Being honest, you create trust and credibility. You also develop positive relationships with colleagues and company. If you have never heard of Angular.js or Couchbase - no one will remember this, but people will always be grateful if you did not waste their time and money.

Know your data structures and algorithms. High-level programming languages, such as C #, are so abstract that many of us have no clue as to what is actually going on under the hood when executing a program. It's great to use LINQ everywhere, but do you know the computational complexity of what you wrote? Do you know what hash tables are, and why are they needed? Can you sort an array in the most efficient way? And come up with a script, where is the best option to use the stack? Note that you don’t need to memorize things like sorting algorithms (hell, I couldn’t even if I tried), but knowledge of data structures is very valuable: trees, hash, lists, queue, stack; in combination with rudimentary notions about sorting, searching and caching. Here is the difference between good and excellent programmers. Everyone can write in C #, but only those who understand the low-level "background" of each method called will write good, clean, efficient code. You need a fundamental understanding of how data structures work, such as the stack and the heap, how addressing by value and by reference works. These basic principles apply to ALL programming languages. Too many developers ignore the complexity of the algorithms and simply call ready-made methods without understanding the consequences. Study the data structures and algorithms, and suddenly you will be ahead of the pack.

Know why your code works and why your code does not work. Have you seen this image from Reddit and similar sites?



Let this picture and funny, but its popularity infuriates me. She states that the essence of programming is not to understand why your code works or does not work. As for me, it is unacceptable. An excellent developer seeks to know WHY things work anyway, and not just HOW to fix it. Is the code not compiling? WHY? Race condition? WHY? By asking why, you will expand your horizons and skills as compared to the pragmatic “how”, which will allow you to become a better programmer. Most great programmers do not repeat the same mistakes again and again, although they, of course, are wrong ... They just make new and interesting mistakes!

I remember the days of writing crappy code, and then copying lines from Stack Overflow and similar sites, until the code started to work (although I was not sure how or why this happened). These days are far behind. When my code is not compiled, in 99% of cases I immediately know how to solve the problem. When in my code a bug, as a rule, I know how to track and fix it, and at the same time I learn to avoid similar situations in the future. Having no idea why your code works is the same as being a lawyer, having no idea why the client is not to blame: a useless, expensive and funny show at the same time. Make sure you understand why your code works ... or does not work. In my opinion, this is the main quality of a professional developer. Create a bug or make a mistake - OK, but to repeat the same mistake several times - not OK!

So I described to you my set of skills and core competencies - what the Stack Exchange team showed to the interview. I couldn’t give an exact (or optimal) answer to all the technical questions, but I behaved modestly and was never afraid to ask for help or say “I don’t know” when I found it difficult to do something. My answers had efficient data structures and algorithms, and I was able to explain why this particular structure was the best choice for solving the problem. Having made a mistake, in most cases I was able to identify it and point out ways to correct it. Having shown my competence and consistency as a developer, I ended up getting a dream job.