Тир
Чем только по работе не займёшься
Про собеседования
Составил для себя список основных причин, почему программисту полезно лишний раз пособеседоваться на работу, даже если задача о смене работодателя прямо сейчас не стоит. Расположил в хронологическом для себя порядке:
- Проходить собеседования полезно, чтобы быть готовым к чёрному дню. Сюда относится как углубление знаний в предметной области (на интервью задали сложный вопрос → почитал дома что-нибудь по этому вопросу и вокруг него → получил новые знания → повторил), так и общее понимание того, чего на собеседованиях от тебя хотят и что из этого стоило бы подтянуть.
- С каждым собеседованием всё сильнее привыкаешь, страх постепенно уступает уверенности. Это особенно важно, если собеседования проходят на английском языке: постепенно перестаёшь задумываться о том, как понятно формулировать свои мысли.
- Если собеседуешься в иностранную компанию, то есть шанс дойти до очного этапа и съездить в другую страну за их счёт. Например, я таким образом побывал в Лондоне и Тель Авиве, куда сам в ближайшее время точно не поехал бы.
- Понимание текущего состояния рынка труда и своего положения в нём.
- Возможность в конечном итоге пройти собеседование и получить хорошую работу.
За прошедшие 16 месяцев я поучаствовал приблизительно в 15 собеседованиях, технических и не только, по телефону и очно, не менее чем в 5 разных компаний, в основном иностранных. Получил несколько предложений о работе. Коллеги даже шутили, что при очередном перелёте я также собеседовался в лётную бригаду и охрану аэропорта.
Я помню своё первое собеседование (в Microsoft), как был уверен успехе, как негодовал по поводу отказа и, наконец, каким наивным чувствовал себя после подробного изучения заданных вопросов. Время прошло чрезвычайно плодотворно.
Для тех, кто собирается встать на этот нелёгкий путь, я порекомендовал бы начать со следующуей литературы:
- книга Programming Interviews Exposed: Secrets to Landing Your Next Job;
- Hacking a Google Interview: сборник типичных задач и паззлов с собеседований.
Но надо понимать, что это только вершина айсберга, литература, которая почти наверняка будет полезна многим. Всё остальное индивидуально. Для меня самой полезной оказалась книга Стивена Скиены «Алгоритмы. Руководство по разработке» (перевод на русский плох, советую оригинал).
Успехов.
Красный
Чистый код
Дочитал наконец «Чистый код» Роберта Мартина (Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin). Книга является сборником советов и правил написания хорошего и улучшения плохого кода. Она может быть интересна в первую очередь программистам на Java.
Миша про эту книгу говорил, что она какая-то капитанская (то есть в ней написаны очевидные вещи — от Капитана Очевидность). Так оно на самом деле и есть, но это не делает её плохой или бесполезной. По мере прочтения я несколько раз осознавал, что некоторые правила хорошего кода я нарушал и продолжаю нарушать. Поэтому считаю, что, несмотря на малость полученных знаний, перечитывать что-нибудь подобное время от времени очень даже полезно.
Ещё хотел заметить, что Appendix A: Concurrency II совсем не раскрывает темы чистого многопоточного кода. Такое ощущение, что это выдранная глава про concurrency из учебника Java для начинающих.
Понравилось заключение к одной из глав:
It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don’t have time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a develop- ment project than bad code. Bad schedules can be redone, bad requirements can be rede- fined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down. Time and time again I have seen teams grind to a crawl because, in their haste, they created a malignant morass of code that forever thereafter dominated their destiny.
Of course bad code can be cleaned up. But it’s very expensive. As code rots, the mod- ules insinuate themselves into each other, creating lots of hidden and tangled dependen- cies. Finding and breaking old dependencies is a long and arduous task. On the other hand, keeping code clean is relatively easy. If you made a mess in a module in the morning, it is easy to clean it up in the afternoon. Better yet, if you made a mess five minutes ago, it’s very easy to clean it up right now.
So the solution is to continuously keep your code as clean and simple as it can be. Never let the rot get started.
Белки
Фотки #0
Фотки-фотки! Всё кликабельно.
Присел в парке почитать книжку. Получилась очень насыщенная панорама: тут тебе и бомж, и мать с ребёнком, и влюблённая пара, и облака, и голуби. Не стал фотографировать только двух чуваков, которые пили пиво на лавке справа. В такую хорошую погоду трудно избежать чуваков, пьющих пиво на лавке справа.
Сфоткал вчера в Карусели. Не очень удобно искать было грушу красную №21.
Никогда раньше не был в коммуналке. В этой душ находился прямо в коридоре.
Диман сказал, так в Питере довольно много людей живёт. Он когда ремонтировал компьютеры на дому, видел и не такое.
На работе маркерная доска упала на открытый Макбук Про и получила такую вмятину. У ноутбука только краска ободралась на углу крышки экрана. Не сочтите за рекламу.
Мы с Михаилом продолжаем разлагаться в компьютерные игры. В тот раз это были уже первые Герои вместо третьих. Сейчас залипаем по вечерам в Террарию.
Накопилось #0
Разное из интернета, картинки, комиксы и прочее в порядке убывания интересности под катом.
Зубы 2
Хорошо, что в стоматологиях врачи работают строго по расписанию: можно заранее узнать, сколько времени тебя сегодня будут лечить. И тогда уже можно расслабиться и восхищаться достижениями современного анестезирования.
Мой 36-й зуб как новый.