How I got a job at Stack Exchange

Original author: David Haney
  • Transfer
From translator
Here is a translation of the publication from the Haney Codes .NET blog . Blog author David Haney works for Engineering Manager at Stack Overflow. A couple of years ago I already translated one article of his authorship: Confusion with job titles .

About a month ago, I found myself talking via video link with Joel Spolsky (author of the famous blog “Joel on Software”, co-founder of Stack Overflow - approx. Transl.). Even now it seems absurd to write like that. For a long time, throughout my career, I regularly read Joel Spolsky, and in many ways agreed with him in my views on development. 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 the time to go through so many interviews. How many, you ask?

Before Joel, I spoke with 5 or 6 other amazing people (including Marc Gravelland Nicholas Larsen). Somehow, I managed to impress each of them enough to get to the final boss. The conversation lasted about an hour, and flew for me 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 Dache issues (my open source cache), and a couple of other topics. Then Joel said something surprising: “Join us on the Stack Exchange!” At that moment I felt such a strong surge of adrenaline that I could lift the car with my bare hands.

A few days later I officially started to work. I am glad about this opportunity and I think that I was very lucky. Up to this point, Stack Exchange has established itself as an incredibly qualified and professional organization that treats employees as people and not as expendables, and I have already managed to love the local customs of communicating with colleagues.

IMPORTANT: First of all, the stated position is solely mine, and not by Stack Exchange, or third parties. The article provides reflections on the interview process, as well as the specifics of my knowledge and professional path that helped to get this job. This is not a “cover slip”, and a hint that does not facilitate the path. If you want to work here, you will have to pass the same tests (details of which I will not disclose) that I passed.

With that caveat, here are my thoughts on how I got a job on Stack Exchange, and how you can do it: The

ego is the mind killer, so kill the ego. Most developers (including myself) still have a massive “I”. Their ego is so large that it barely fits in the room. This is natural, taking into account the fact that all day long we create real-life things that bring solid income, 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.

Thinking that you know everything is the easiest way to screw up as a programmer. Believing in this, you no longer study new products (you already know them). While you have masterfully mastered ASP.NET MVC 3 at your current place of work, the 4th and then the 5th versions of the framework have been released ... only your company will not upgrade because it 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 can not even see them with binoculars. By the way, did I mention those gizmos - Ruby and PHP, or even Java, on which you never wrote a single line? What about MongoDB, Couchbase, Azure, EC2, and thousands of other programming platforms and languages? I hope that now you understand that your knowledge of languages ​​and hardware configurations is a drop in the bucket ... maybe 0.1% of all development knowledge. I know just as much

Do not 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 appropriate payment). Being a rock star sounds great, but it's actually a risky strategy that can grow an incredibly explosive atmosphere in a team. Companies seek out and hire rock stars, and rock stars take it for granted. They inflate their selves and pompously argue in meetings, interrupting and pushing others away. They argue in the spirit of "I am right because you are wrong, because I am right." The rock star is convinced that the rest exist to indulge his whims ... while the rest hate to work with such a person.

The fact is that you can actually be the same, one in a million great developer, a "rock star" - but nobody cares. Words are worthless, and people will say almost anything to make a person the impression they need. Even if you are really good - talking to people only about this, and about nothing else - will make them despise you. A good developer does not need to boast; its results will speak for themselves more eloquently than any words. Naturally, others will appreciate such a person. Leisure conversations on the subject of “wow, he is very smart” or “she did it in an hour, but we thought it would take several days” will grow stronger, which is not bad. Let people talk about you whatever they like, but keep modesty and a sense of realism. You may be the best developer on a team or even a company, but you are still human and you are still at work. No one here has been hired to serve your ego (even those whose daily duties are work 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 workplaces. Out of their total number - an excellent one can stand outand humble developer. This is a very rare combination in my experience, and the limit of dreams for hiring in many companies. Even if you are the most-most (that’s cool!) Of all, stop bragging about others. They do not care how you should be.

Know what you know enough to understand the limitations of your knowledge.(original know that you know enough to know that you don't know enough - approx. transl.). Realize what you know and what 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. By being honest, you build trust and authority. You also develop positive relationships with colleagues and the 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 begin to 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 idea what actually happens “under the hood” when a program runs. 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 the array in the most efficient way? And come up with a scenario where the best option is to use the stack? Please note - you do not 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; combined with rudimentary concepts 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 “ins and outs” 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 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. Explore data structures and algorithms, and suddenly you will be in front of the pack. 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. Explore data structures and algorithms, and suddenly you will be in front of the pack. 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. Explore data structures and algorithms, and suddenly you will be in front of the pack.

Know why your code is working and why your code is not working. Have you seen this image from Reddit and similar sites?

image

This picture may be funny, but its popularity infuriates me. She states that the essence of programming is not to understand why your code is working or not working. For me, this is unacceptable. An excellent developer is eager to find out WHY things work one way or another, and not just HOW to fix it. Does the code not compile? WHY? Race condition? WHY? By asking “why” questions, you will expand your horizons and skill set compared to the pragmatic “how”, which will allow you to become a better programmer. Most great programmers do not repeat the same mistakes over and over 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 the lines from Stack Overflow and similar sites - until the code started to work (although I was not sure how and why this happened). These days are far behind. When my code does not compile, 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 such situations in the future. Having no idea why your code works is like being an attorney with no idea why the client is not to blame: a useless, expensive and funny sight at the same time. Be sure to understand why your code is working ... or not working. In my opinion, this is the main quality of a professional developer. Create a bug or make a mistake - OK,

So I described to you my set of skills and key competencies - what I showed the Stack Exchange team during the interview. I couldn’t give an exact (or optimal) answer to all technical questions, but I was modest and never afraid to ask for help or say “I don’t know” when I was at a loss. My answers had efficient data structures and algorithms, and I was able to explain why this particular structure is the best choice to solve the problem. Having made a mistake, in most cases I was able to determine this and indicate ways to fix it. Having shown my competence and viability as a developer, I ended up getting a dream job.

Also popular now: