24 декабря Архивач восстановлен после серьёзной аварии. К сожалению, значительная часть сохранённых изображений и видео была потеряна. Подробности случившегося. Мы призываем всех неравнодушных помочь нам с восстановлением утраченного контента!
Ниже - список тем, которыми я обычно интересуюсь на интервью. Я не жду, чтобы джуниор знал всё это, но сеньор обязан как минимум уметь поддержать разговор практически обо всём.
В порядке уменьшения важности: • Классы и объекты. Инкапсуляция. RAII и почему оно важно. Наследование и полиморфизм, где и зачем. Хотя бы поверхностное знание, как работают виртуальные функции. Почему виртуальные деструкторы - хорошая идея. Копирование и перемещение. • Как работает стек и чем он отличается от кучи. Управление памятью в целом и буферами в частности. Переполнение буфера. • Исключения и что происходит при их выбрасывании. Как работает раскрутка стека. Взаимодействие исключений с деструкторами. • Опыт с STL и базовыми структурами данных. Опыт с другими популярными библиотеками (например, Boost). Опыт с API ОС (Win32 и т.д.). Кросс-плаформенное программирование. • Когда использовать несколько потоков. Потокобезопасность при нескольких операциях чтения и записи. Блокировки. Взаимные блокировки и как их избежать. Пулы потоков. Futures и promises. • Разница (преимущества and и недостатки) между C++ и языками со сборкой мусора (C# или Java). Как эта разница влияет на построение программ. • Фреймворки для тестов. Знакомство с основными IDE и платформами. Контроль версий, branching и merging. Гибкая методология разработки, опыт с ней, её преимущества и недостатки. • Сетевое программирование. Разница между блокирующим и неблокирующим вводом-выводом. Messaging. Как TCP разбивает сообщения (подсказка: он этого не делает). ASIO-style асинхронный ввод-вывод с callback'ами. HTTP. REST. OpenSSL. • Файловые системы. Строки и кодировки. • SQL и базы данных, XML, Json парсеры.
Итак, анон, если ты не знаешь хотя бы чего-нибудь из списка - ты не программист, а ничтожество. И да, ты обязан знать всё это, даже если ты не пишешь на C++. Это элементарные и основные знания.
Многие начинающие программисты, особенно обучающиеся в провинциальных вузах, часто не знают, в какую сторону им развиваться, и что они должны знать для того, чтобы эффективно работать по специальности. Удивительно, но каждый день используя продукты и технологии, созданные другими программистами на основании развитых областей знания, они даже не догадываются о том, как они устроены.
Построенные на теории массового обслуживания и стандарте GSM сети мобильной связи; PHP-скрипты, исполняющиеся на удаленных серверах и передающие свою выдачу через Ethernet по TCP/IP на компьютеры с NDIS-драйверами; процессоры, переупорядочивающие и спекулятивно исполняющие наборы инструкций для того, чтобы скомпенсировать вызванную ограничениями полупроводниковой электроники и скоростью света остановку роста тактовой частоты; рассчитанные на ЭВМ корпуса самолетов и автомобилей, лекарства и структуры ДНК; компьютерные игры, ради крохотного блика в которых пишутся мегабайты заполненных интегралами Френеля статей; электронные фильмы и книги; алгоритмы NLP и TreeNet, вызывающие нам из огромных баз данных поисковую выдачу — вот то, что окружает нас каждый день благодаря программистам, благодаря оригинальным подходам и фундаментальным знаниям, благодаря продуманной и отточенной десятилетиями методологии разработки и управления сложностью ПО.
Я и мои единомышленники взяли на себя труд составить теоретический минимум для программиста на основании наиболее ярких отраслей IT, вошедших даже в программы нормальных университетов, на основании собеседований и постоянно пригождающихся на практике знаний. Часть из пунктов этого минимума можно изучить за 5 минут по википедии, часть же потребует серьезного труда на протяжении нескольких месяцев, но это именно то, что обязательно следует знать и чем следует свободно владеть. В комментариях приветствуются исправления и дополнения.
C++, стандарт, Comeau, 1TBS, Страустрап/D&E/Джосаттис/Вандервуд, Дьюхэрст/Мейерс/Саттер, RAII/copy-and-swap/exception-safety, правило пяти, Александреску/Абрахамс-Гуртовой, type erasure, CRTP, NVI, SFINAE, Koenig lookup, Duff's device, Boost, Сик-Ламсдейн/Карлссон, TR on C++ performance, тест Степанова, forwarding problem/move semantics, SPECS
Компиляторы, особенности реализации стандарта, ограничения реализации, интринсики, отличия стандартных библиотек (контейнеры, rand), ABI, реализация виртуальных функций, виртуального наследования, исключений, RTTI, switch, указателей на функции и методы; оптимизации, copy elision (RVO, NRVO), sizeof на различных платформах, дефайны компилятора и среды, __declspec, ключи компилятора, empty-base optimization, статическая и динамическая линковка, манглинг, распределенная компиляция, precompiled header, single compilation unit, (strict) aliasing/restrict, inline/_forceinline, volatile
Мультитредность, обедающие философы, deadlock/livelock/race condition/starvation, атомарность, lock инструкции процессора, memory model/barrier/ordering, CAS или LL/SC, wait/lock/obstruction-free, ABA problem, написание lock-free контейнеров, spin-lock, TLS/per-thread data, закон Амдала, OpenMP, MPI, map-reduce, critical section/mutex/semaphore/condition variable, WaitForSingleObject/WaitForMultipleObjects, green thread/coroutine, pthreads, future/deferred/promise, модель акторов
Язык ассемблера, Зубков/Хайд/Дреппер/Касперски/Фог/Абраш, x86, FPU/MMX/SSEn/AVX, AT&T и Intel-синтаксис, masm32, макросы, стек, куча/менеджеры кучи, соглашения вызова, hex-коды, машинное представление данных, IEEE754, little/big endian, SIMD, аппаратные исключения, прерывания, виртуальная память, реверсинг, срыв стека и кучи, return oriented programming, alphanumeric shellcode, L1/L2/RAM/page fault и их тайминг, язык ассемблера ARM
Аппаратное обеспечение, Хоровиц-Хилл/Титце-Шенк/От физики к Си от panchul, полупроводниковая электроника/спинтроника/фотоника, транзистор, триггер, схемотехника, микрокод, технология создания процессоров, logic synthesis, static timing analysis, FPGA, Verilog/VHDL/SystemC, SISAL, Arduino, устройства памяти (ROM → EEPROM, RAM, SSD, HDD, DVD), RISC/CISC, Flynn's taxonomy ([SM]I[SM]D), принстонский и гарвардский подход, архитектуры процессоров, архитектуры x86, VID/PID
Процессоры, конвейеризация, hyper-threading, out-of-order execution, спекулятивное исполнение, static/dynamic branch prediction, префетчинг, множественный ассоциативный кэш, кэш-линия/кэш-промах, такты, кольца защиты, память в мультипроцессорных системах (SMP/NUMA), тайминг памяти
Вычислимость, машина Тьюринга, нормальные алгоритмы Маркова, машина Поста, диофантовы уравнения Матиясевича, лямбда-функции Черча, частично рекурсивные функции Клини, комбинаторное программирование Шейнфинкеля, Brainfuck, эквивалентность тьюринговых трясин, проблема останова и самоприменимости, счетность множества вычислимых функций, RAM-машина, алгоритм Тарского, SAT/SMT-солверы, теория формальных систем
Языки программирования, грамматики, иерархия Хомского, теорема Майхилла-Нероуда, лемма о накачке и лемма Огдена, алгебра Клини, НДКА → ДКА, алгоритмически неразрешимые задачи в формальных языках, Драгонбук, Фридл, регекспы и их сложность, PCRE, БНФ, Boost.Spirit + Karma + Qi/Ragel, LL, LR/SLR/LALR/GLR, PEG/packrat, yacc/bison/flex/antlr, статический анализ кода, компиляция/декомпиляция/обфускация/деобфускация, Clang/LLVM/XMLVM/Emscripten, GCCXML, OpenC++, построение виртуальных машин, JiT/AoT/GC, DSL/DSEL
Алгоритмы и комбинаторная оптимизация, Кормен/Скиена/Седжвик/Кнут/Ахо-Хопкрофт-Ульман/Пападимитриу/Шрайвер-Голдберг/Препарата-Шеймос/e-maxx.ru, структуры данных, алгоритмы, сложность, символика Ландау, теорема Акра-Баззи, time-space tradeoff, классы сложности, NP-полные задачи, КМП, графы и деревья, потоки в сетях, матрица Кирхгофа, деревья поиска (особенно RB-дерево и B-дерево), occlusion detection, куча, хэш-таблицы и идеальный хэш, сети Петри, алгоритм русского крестьянина, метод Карацубы и матричное умножение Винограда-Штрассена, сортировки, жадные алгоритмы и матроиды, динамическое программирование, линейное программирование, diff-алгоритмы, рандомизированные алгоритмы и алгоритмы нечеткого поиска, псевдослучайные числа, нечеткая логика
Численные методы, дихотомия/метод Ньютона, интер- и экстраполяция, сплайны, метод Гаусса/Якоби/Зейделя, QR и LU-декомпозиция, SVD, МНК, методы Рунге-Кутты, метод Адамса, формулы Ньютона-Котеса, метод Ритца, метод Бубнова-Галеркина, метод конечных разностей/элементов, FFT/STFT, сходимость и устойчивость
Машинное обучение, Рассел-Норвиг/Bishop, подходы к моделированию AI, переобучение/кроссвалидация, байесовские сети, нейросети, сети Кохонена, Restricted Boltzmann machine, градиентный спуск/hill climbing, стохастическая оптимизация (метод Монте-Карло, метод отжига, генетические алгоритмы, муравьиные алгоритмы), SVM, gradient boosting, кластерный анализ, метод главных компонент, LSH, обучение с подкреплением, MDP, information retrieval/data mining/natural language processing, машинное зрение, Szeliski, OpenCV, image processing, OCR, фильтры Собеля, каскад Хаара, Viola-Jones framework, SURF, введение в психофизиологию зрения, IPython/pandas/scikit-learn
Теория информации, сжатие, Хаффман, RLE, BWT, LZ, коды коррекции ошибок, сжатие с потерями (изображения, аудио, видео), информационная энтропия, формула Шеннона, сложность Колмогорова
Криптография, Шнайер/Ященко, Принцип Керкгоффса, симметричная (DES, AES), асимметричная (RSA), качество ГПСЧ, алгоритм Диффи-Хеллмана, эллиптические кривые, хэширование (MD5, SHA, CRCn), DHT, криптостойкость, криптоатаки (атака гроссмейстера), WEP/WPA/WPA2 и атаки на них, цифровая подпись и сертификаты, PKI, HTTPS/SSL, доказательство с нулевым разглашением, пороговая схема
Инструментальные средства разработки, IDE, IntelliSense, отладчики (VS/Olly/WinDbg/kdb/gdb) и трейсеры (strace/ltrace), DWARF debug information format, дизассемблеры и декомпиляторы (IDA/HexRays/Reflector), системы контроля версий (SVN, GIT), merge/branch/trunk, системы именования файлов и бранчей, continuous integration, ant, code coverage, статический анализ (lint, cppcheck), динамический анализ (valgrind, фаззинг), верификация и валидация ПО (Frama-C, RAISE (RSL), Coq), профайлинг, багтрекеры, документирование кода, системы сборки (CMake), пакетные менеджеры (NuGet)
Фреймворки, Qt, moc и метаинформация, концепция слот-сигнал, Саммерфилд-Бланшет/Шлее, PoCo, промышленные библиотеки: GMP, i18n, lapack, fftw, pcre
Операционные системы, Silberschatz/Рихтер/Соломон-Руссинович/Робачевский/Вахалия/Стивенс/Love/Linux Kernel Internals, менеджер памяти, менеджер кучи и ее устройство (LAL/LFH/slab), менеджер устройств, менеджер процессов, context switch, реальный и защищенный режим, исполнимые файлы (PE/ELF/Mach), объекты ядра, отладочные механизмы (strace/ptrace/dtrace/pydbg, Debug API) и минидампы, bash, сетевой стек и высокопроизводительные сервера, netgraph, CR0, IPC, оконная подсистема, система безопасности: ACE/ACL и права доступа, технологии виртуализации, RTOS (QNX), программирование драйверов, IRQL, IRP, файловые системы, BigTable, NDIS/miniport/FS drivers/filter driver, Mm-, Io-, Ldr-функции, DKOM и руткиты, GDT/IDT/SDT, ядра Windows/Linux/BSD, POSIX
Функциональное программирование, Haskell/Ocaml/Scheme/Alice или Oz, SICP/TaPL/YAHT/Purely Functional Data Structures/Харрисон-Филд, HOF (map/fold/filter), система типов Хиндли-Милнера, монады, тайпклассы, АТД, dependent types, ленивость/энергичность, логическое программирование (Prolog или Mercury), конкурентное программирование (Erlang или Oz)
Веб-программирование и скриптовые языки, Фланаган/Zend PHP5 Certification Course + Study Guide, Apache/nginx, CGI/FastCGI, PHP/Zend Framework/ReactPHP/Zend Engine/Doctrine или Propel/CodeIgniter или Symphony или Yii, Python/Django/Twisted, Ruby/RoR, ASP.NET MVC, JavaScript/jQuery/React/Google Closure/ExtJS/node.js, ООП в JavaScript, HTML5, CSS3/табличная и блочная верстка, RSS, canvas/WebGL, Ajax/WebSockets, вопросы безопасности (XSS, SQL injection, CSRF), highload, C10k problem, SWIG
Проектирование GUI и представление информации, Раскин/Тафти, юзабилити, основы дизайна и типографики, закон Фиттса, основы верстки, LaTeX
>>852113 (OP) Очередная личинка программиста составляет свой компендиум знаний программиста. Откуда вы лезете блядь со своими ебучими схемами? Есть один лишь верный манифест - http://macode.ru/
>>852113 (OP) Мне больше нравится правило: Напиши 10 таких-то программ с использованием ООПиOOD прежде чем назвать себя таким-то программистом. Каждая последующая программа должна исправлять ошибки предыдущей и добавлять новый функционал.
10 вопросов, которые мы даем на собеседовании на PHP джуна. Пока ни один петушок на все правильно не ответил (таких не берем), думаю, что и местные тоже соснут. При этом все выебываются и считают себя гениями.
1. Основные отличия PHP 5 от PHP 7 (5-10 новых возможностей, ключевые различия). 2. Основные отличия HTML от HTML 5 (5-10 новых возможностей). 3. Основные отличия CSS от CSS 3 (5-10 новых возможностей). 4. Какие существуют паттерны проектирования, их основные различия, плюсы и минусы. 5. Какие существуют методологии программирования, их основные различия, плюсы и минусы. 6. Назвать основные ключевые отличия InnoDB от MYISAM. Что лучше использовать для вставки/селекта. 7. Как сделать репликацию баз данных MySQL, зачем делать репликацию. 8. Описать процесс отладки медленных MySQL запросов через консоль UNIX. 9. Что такое MySQL транзакции, как они работают, где и как их лучше использовать. 10. Сервер находится в Калининграде, нужно прозвонить номера в РФ, Украину, Беларусь ровно в 19:00 по времени получателя, с учетом часовых поясов летнего/зимнего времени, государственных актов об изменении часовых поясов. Что где и как нужно хранить в MySQL, PHP для этого? Какие настройки сервера UNIX нужны?
>>852115 >>852116 Для того, чтобы зарабатывать, нужно от силы 5% в зависимости от специализации работы Всё остальное — дрочево на то, какой я охуенный программист.
>>852267 То, что вброс, уже можно понять на этом >процессоры, переупорядочивающие и спекулятивно исполняющие наборы инструкций для того, чтобы скомпенсировать вызванную ограничениями полупроводниковой электроники и скоростью света остановку роста тактовой частоты
>>852156 Какие то петушиные навыки. В нормальных компаниях подобные компетенции получают и обменивают по необходимости, у вас это похоже на какие-то ёба-техники для повышения фактора автобуса и джобсекьюрити.
>>852156 >2016 >MySQL >UNIX А если по делу, то не факт, что человек знает устаревшие версии этих ваших HTML, PHP, CSS. Так нафига спрашивать отличие старых от новых? Вы на них одновременно пишите? Мимо системный программист.
>>852330 Скорость света ограничивает частоту возможных событий в системе последовательных вычислений, построенной из атомов. Можно даже посчитать теоретические пределы для разных моделей. Конвейер по сути борется с этой проблемой с помощью частичной параллелизации работы, но возможности этого подхода ограничены.
>>852316 Стандартные вопросы для джуна, но никто не может правильно ответить.
>>852321 > Мимо системный программист. О, байтоебов унижать особенно приятно, они абсолютно ни хрена не знают. Таких петушков я сразу начинаю гонять по операциям сравнения в PHP и JavaScript и регуляркам. Опускать в говно этих бомжей, считающих себя великими мегахацкерами, ставить их на уровень ниже самой тупой макаки и наблюдать за их обосрамсом - что может быть лучше?
>>852156 1. Тоже спрашиваю, если человек утверждает, что знает PHP (если не знает, то похуй — по ходу дела научится, не ракетная наука) 2-3. Вопросы для быдла. 4. Хуяттерны. Нет, ну я ожидаю, что мой собеседник знает, что такое синглтон или фабрика, но требовать знать об этой хуйне?.. 5. Вопрос ок, но слишком абстрактный. Я перестал спрашивать о таких вещах, потому что люди обычно не понимают, чего я от них хочу. 6-7. Ок, но специфично. Я могу рассказать это человеку минут за 10-20, если так случилось, что он никогда не работал именно с MySQL — а не похуй ли? Опять же, не ракетная наука. 8. Ок, тоже иногда спрашиваю. 9. Сойдёт, может быть попробую как-нибудь спросить. 10. Ну хз даже. Задача в самом деле довольно показательна, но я подозреваю, что буду часто слышать какую-то хуету и ответы в стиле "вода — мокрая" и будет трудно понять, проблема в человеке или в вопросе.
>>852462 > 2-3. Вопросы для быдла. Большинство из HTML 5 слышали только про canvas, а про CSS 3 вообще не могут внятно ответить. На тестовое задание даю небольшой сервис, где нужно записывать звук из браузера и отправлять на сервер, пока справился только один человек (его взяли, если интересно). > Нет, ну я ожидаю, что мой собеседник знает, что такое синглтон или фабрика Многие, как это ни странно, не знают. Среди системных программистов - абсолютно никто. > если так случилось, что он никогда не работал именно с MySQL Не понимаю, зачем нам такие, если мы работаем именно с MySQL? В требованиях к вакансии это указано. > Ну хз даже Что не так? Очень хороший вопрос, позволяющий отсеять мамкиных хацкеров, прочитавших книжку "PHP для чайников за 21 день" и мнящих себя гуру-спецами.
>>852464 Маня, программист должен постоянно учиться. Твой дельфи 7 нахуй никому не сдался в 2016 году.
>>852480 >должен постоянно учиться. Ой клован, не смеши. Ты еще будешь учиться по учебникам, которые я когда - то переводил, когда я уже выйду на пенсию где-нибудь на Карибах.
Мило смотреть, как какой то анон рассуждает, что за технологии я я использую.
>>852480 > Не понимаю, зачем нам такие, если мы работаем именно с MySQL? Мы тоже. Но если есть нормальный программист, который работал в основном с postgresql — мне как-то похуй, знает он MySQL или нет. За 20 минут можно объяснить человеку (если он в общем и целом знаком с архитектурой СУБД, знает, что такое транзакции и т.п.) что к чему в этой конкретной БД, чем отличаются разные движки и т.д. Настраивать репликацию я его вообще никогда не попрошу, для этого у нас есть админы. Достаточно, чтоб в общих чертах понимал, как она у нас работает. > Что не так? Очень хороший вопрос Я же сказал, что. Задача в самом деле показательна, но вот вопрос — хз. Бывает, что человек тупо не понимает, чего ты от него хочешь и что надо сказать, а что говорить стыдно, потому что это "слишком очевидно, наверное вопрос не в этом". Я попробую его задавать, но не уверен, что это хорошая идея. >>852509 Не доёбывайся до формулировки. Есть sql запрос, он тормозит, как человек будет в общем случае решать проблему?
Нет, я буду доебываться до формулировок. Потому что, нет ничего хуже тим-лида который не может объяснить чего он хочет. Итак при чем тут консоль? зачем ты о ней вообще сказал? Сформулируй свой вопрос, так чтобы было понятно, или извинись и отбрось шелуху. Иначе это будет минус баллы уже с моей стороны, которые в конечном итоге выльются в то, что я буду просить много бабла у тебя, или пошлю на хуй эту работу, и начальника-придурка который не может описать проблему.
>>852156 >2. Основные отличия HTML от HTML 5 (5-10 новых возможностей). >3. Основные отличия CSS от CSS 3 (5-10 новых возможностей). Ох, как я рад, что мне удалось свалить из вебо-параши в системное тестирование. Да, блядь, тестирование. Лучше заниматься тестированием ОС, чем долбиться в это программирование формочек.
P.S. Ты, кстати, в вопросах не указал предыдущие версии ни для CSS, ни для HTML.
>>852113 (OP) Итак, анон, если ты не знаешь Haskell и теорию категорий в совершенстве - ты не программист, а ничтожество. И да, ты обязан знать всё это, даже если ты не пишешь на Haskell. Это элементарные и основные знания.
>>852363 Не частота ограничивается скоростью света, а общая скорость работы системы. При частоте в 3 гигагерца за один такт свет успевает пройти 10 сантиметров. То есть например физически невозможно сделать память со скоростью чтения данных за один такт, если она расположена дальше 10 см от ядра. Увеличь частоту еще на пару гигагерц, и за один такт у тебя электрический сигнал будет даже не успевать дойти от одного края процессора до другого.
>>852156 >>Сервер находится в Калининграде Это задачка с закавыркой? Нужно учитывать скорость света чтобы позвонить ровно в 19:00 и не наносекундой ранее или позднее?
>>852551 Я бы поставил время на сервере UTC + 0, все три страны правее от него и имеют пояса UTC + n, в том числе и чукотка, с местными поправками разбросы в час, и всё равно везде +, максимум на чукотке +12/+13. Чтобы позвонить вовремя по местному, нужно отнять то n, получается нужно просто хранить одно n для каждого получателя.
А проще наверное сразу отнять это n и записать новое время, чтобы не считать его постоянно серверу. Я совсем тупой?
>>852156 Придет к тебе человек, написавший свой компилятор, свою никому, в том числе ему, ненужную ос, решивший по-быстрому вкатиться в твой макакинг ради бабла, а ты завернешь его и посмеешься "ахахах он не шарит в моих инструментах для макак"?
>>852923 >написавший свой компилятор, свою никому, в том числе ему, ненужную ос Простой форт и маленькая ОС с кооперативной многозадачностью пишутся за пару недель. Это уровень третьекурсника. Хотя для пыхомакаки слишком высокий уровень, конечно.
Начинаю читать посты, немного хуею, и половины этих ваших баззвордов не знаю. А ведь работаю уже почти десяток лет.
Одно понимаю точно: каждая из таких проверочек это чей-то личный катарсис, например ОПа осенила какая-то хуета, когда он её осилил, теперь он всех спрашивает на собеседованиях именно эту штуку и ожидает определённый чуть ли не с точностью до слова ответ. А для меня это было что-то совсем обыденное, на что я даже времени особо не тратил. Всё, хуяк, я не прошёл собеседование.
Спрашивайте блядь что-нибудь из официально признанной теории. Почитайте книжек блять. Поймите, что есть широкие пределы применимости, и разные люди по-разному делают одни и те же вещи. Тогда сможете собеседовать нормально.
>>852113 (OP) Но даже если ты знаешь все это, я обоссу тебя на собесе. Потому что могу. Потому что Я это Я, Я, Я, Я, Я!!! А ты говно. Моча. Хуй, Попугай. Хомяк. Утырок. Тьфу на тебя, тьфу!
Злой и агрессивный вы народ, кодеры. Противно иногда с вами общаться.
>>853034 Не все и не везде, по крайней мере если не культивируется, а поощряется уважительное и профессиональное отношение друг другу. А так и есть в компаниях/проектных группах, о которых я говорю.
>>852113 (OP) > Разница между C++ и языками со сборкой мусора как существо, выбравшее дотнет, сиравно не до конца догоняю, в чем такая невероятная крутость от автоматического GC. по крутейшему совпадению моей головной болью последние несколько дней на работе является катастрофическая утечка памяти приложения
>>853099 >катастрофическая утечка памяти приложения В джаве стандартными средствами очень легко посмотреть, где течет, кто на истанс ссылается и т.д. Для дудки тоже что-то подобное должно быть.
>>853030 Увы на собеседовании это не проверишь. Напиздеть о своем опыте можно с три короба, ответы на типичные вопросы зазубрить заранее. А потом выясняется что нихуя человек на деле и не может, но выясняется уже только по ходу работы.
Тестовое задание это неплохо, но опять же сложное и длинное никто забесплатно делать не захочет (хотя есть фирмы которые за него даже платят, но это единицы), а короткое и простое опять же мало что показывает.
>>853113 В managed языках утечки обычно обусловлены какими-нибудь архитектурными проблемами и встречаются в количестве пары штук на приложение (ну сколько у тебя там может быть каких-нибудь кэшей, из которых ты забываешь удалять ссылки на объект и он потому не очищается?). А в С++ утечку может сделать каждый сраный new, для которого ты забыл delete. Посчитай сколько раз ты в коде new используешь - вот столько у тебя может быть утечек. При этом благодаря арифметике указателей и прочей еботе ты даже не можешь точно посмотреть, кто и откуда ссылается на твои участки памяти, и какие из них используются, а какие утекли. Приходится городить какие-то костыли типа умных указателей и кастомных дебажных менеджеров памяти, которые умеют записывать коллстеки аллокаций.
>>853148 >встречаются в количестве пары штук на приложение Если ты не используешь библиотеку, которая работает с нативом, OpenGL какой-нибудь. Тут все может быть гораздо печальнее, и с количеством утечек, и с их контролем. >даже не можешь точно посмотреть Могу, конечно. Куча инструментов для этого.
>>853004 Успокойся, это маняфантазии очередного студентика. Везде, где я устраивался -спрашивали базовые вещи без всяких выебонов. В собеседовании важно несколько другое - насколько хорошо ты сможешь работать с теми людьми. которые уже работают.
В общества всяких весёлых социоблядей меня не брали, и понятно почему, зато к людям иной формации я вписывался отлично.
>>853088 Но-но-но-но-но... Я же греб на галерах вне России, а там трудовой нет! А если я греб на галерах в России, то мне и не попасть в эту компанию, нет International Experience же!
>>853051 Шутничок. Частоту конечно можно делать большой, но на одном-двух транзисторных каскадах. Дальше пиздарики. Попробуй в майнкрафте на красной пыли заебенить счётчик хотя бы на четырёх триггерах. Увидишь как старший разряд охуенно отстаёт от изначального клока.
>>852113 (OP) > Каждый программист > Опыт с STL и базовыми структурами данных. Опыт с другими популярными библиотеками (например, Boost). Опыт с API ОС (Win32 и т.д.). Кросс-плаформенное программирование. Ну и нахуя?
>>853457 Видим, не доучился. Ладно, шучу, анон. На самом деле, если бы мне на 4-м курсе не задали сделать доклад по параллельным вычислениям, я бы тоже не знал, что скорость света ограничивает производительность. Да и вообще я в вузе мало что усвоил.
>>853585 STL - это прекрасный пример реализации базовых структур данных. А базовые структуры (дерево, список) должен знать каждый. Буст даёт аналогичный опыт, но в большем числе тем. API ОС - чтобы понимать, что умеет средняя операционная система. А то потом появляется что-нибудь уровня питона, который вроде бы и многопоточный, но выполняется на одном ядре.
>>852156 >10. Сервер находится в Калининграде, нужно прозвонить номера в РФ, Украину, Беларусь ровно в 19:00 по времени получателя, с учетом часовых поясов летнего/зимнего времени, государственных актов об изменении часовых поясов. Что где и как нужно хранить в MySQL, PHP для этого? Какие настройки сервера UNIX нужны? Вы там ебанулись писать такую хрень на пхп?
Напишите консольную программу (без GUI), которая соединяется с СУБД MySQL, и во всех базах (кроме служебных "mysql" и "information_schema"), во всех таблицах, находит текстовые поля, 90% непустых значений в которых после отбрасывания пробелов (операция "trim") удовлетворяют условию: состоят только из цифр и имеют длину 10 или 12. (90% непустых значений таблицы в этом в поле должны удовлетворять этому условию). Пустые и NULL-значения при этом вообще не учитывайте. Результатом работы программы должны быть наборы: { БАЗА, ТАБЛИЦА, КОЛОНКА (то есть название колонки) } а лучше: { БАЗА, ТАБЛИЦА, КОЛОНКА, % соответствия значений (от 90 и выше) }
>>853148 > А в С++ утечку может сделать каждый сраный new, для которого ты забыл delete. макак, ты не можешь в принципе забыть delete, ибо ты пишешь new в конструкторе и delete в деструкторе. RAII ёпта
>>857855 А потом понимаешь, что в классе нужно ещё пару полей добавить, инициализируешь их в конструкторе, но вот в деструкторе delete забываешь прописать.
>>852113 (OP) хочу вкатиться в функциональное программирование, на уровне "так, чисто для себя" и "шоб посмотреть, шож там форсят", решил выбрать F#. не могу найти ни одной задачи, которая не свелась бы к тому, чтобы я не начал писать максимально приближенно к ООПу. Может знает кто хороший ресурс, на основе которого можно было бы безболезненно вкатиться в функциональщину?
>>857942 >решил выбрать F# >начал писать максимально приближенно к ООПу Это нормально. Сколько я видел настоящего кода на этом (не из статей и туториалов про функциональщину) - все на нём писали как на сишарпе с нескучным синтаксисом.
>>852113 (OP) Это нормальные список, если им интересоваться, а не спрашивать конкретные вопросы про какие-то тонкие механизмы, да ещё и с подвохом. Никому это нахуй не нужно, потому что никто это нахуй не использует.
Хотя пару пунктов я бы вычеркнул, он как будто ищет петуха, который ему работу 2.5 других заменит. Сколько же он ему платить собрался?
>>858481 Кто спорит что В ИДЕАЛЬНОМ МИРЕ где никто ничего не забывает и никогда не ошибается утечек памяти тоже не будет. Но живем-то мы в мире реальном.
>>857855 Чего только плюсовики не придумают чтобы решать проблемы своего языка. Твой RAII это вещь хорошая, конечно, но хуево работает если время жизни одного объекта трудно прогнозируемо.
>>857994 Да, да, конечно, я мудак и все вокруг мудаки, что у всех все утекает.
>>852113 (OP) Мои минусы: Фреймворки для тестов. Сетевое программирование. Потоки. WinAPI ибо я свободный человек и пользовался linux-api. Самое забавное, что я не работаю. Сижу сутками читаю всякую околохакерскую лит-ру. Могу я устроиться на удаленку с такими знаниями? English is ok.
и вы должны гордится что работаете в нашей компании! И да, я не программист, и не работаю на контору, но видел тех, кто работает на крупные конторы и пишет код, трахается со scrum / kanban, и видел качество этого говна.
Почему-то я там не заметил ничего такого заумного, чего я самоучка с 2 годиками самообразования в этой сфере не смог бы реализовать лучше, и без багов, и макаронного кода который есть у вас. Такое впечатление что контора с 40 макаками не может написать код лучше одного меня блядь, для реализации тех же задач и фикса тех же проблем. Причем проект открытый, и форки имеются. Но блядь как же все хотят считать себя такими умными и красивыми, и да - я говнопрограммист, но по КД ору в github issues с говна в коде у этой конторы уебанов, которые, кстати, очень хорошо посасывают бабла из кормушки месяцами за то, что я на коленке за 2 дня делаю, и это работает так, как и задумывалось, а не с утечками памяти, faultами, и прочими крашами. И да, всегда забавляют эти чуваки которые интервью берут, такое впечатление что я иду на работу в разработку матрицы по тому бреду, который они спрашивают, да, он нужен, но блядь я почему-то и более 5% от того, что у меня спрашивают - не вижу как используется в коде проекта. Так нахуя выебываться и строить из себя ахуенную контору и требовать от кандидата скил на овердохуя денег, когда сами пишите говно, и платите говнокопейки, и когда на фрилансе зарабатываю больше, чем вы платите мне за объем работы, в разы больший в офисе чем дома? (но единственный плюс из этого говна в том, что за меня организационную работу что и как делать решает кто-то другой на работе, на фрилансе по кд приходится с даунами разговаривать и по слову выдерать конечную модель того, что они хотят, а потом на основе этого составлять ТЗ.
>>860972 Да нихуя. Банально если предположить что время жизни объекта (какая-нибудь сессия или еще чего-нибудь) зависит от внешних действий (например сетевых запросов). В таких случаях очень легко утечку соорудить которую тебе никогда никакой статический анализатор не найдет.
а разве за тебя этого не делают? Там же все просто, виденье проекта, цели, и как достичь цели определяет тимлид\заказчик\твойбосс, тебе же от kanban нужно лишь определить что ты исходя из своих возможностей (которые в 80% случаев уже определены за тебя твоим начальством) будешь делать. Вся суть заключается в чеканье доски и карточек которые ты можешь взять и заасигнуть список конкретных задач на себя, либо карточку взять под себя - а какие-то уж очень простые задачи отдать джунам.
Че там ахуевать я не понимаю? Ахуевать ты бы ахуевал если бы на себя пахал, либо был бы боссом конторы и делал то, что хочет клиент (а как мы все знаем клиент сам не ебет в помине что он хочет, и к чему он стремится, ему нужно - сделай мне так, что бы я тут нажал одну кнопочку и у меня деньги рекой полились, шлюхи в очереди отсасывали член, и у конкурентов горели жопы от того, какие мы ахуенными стали, и все клиенты бежали с полными кошельками бабла и с радостью отдавали деньги нам, при этом обожествляя и благословляя).
Со скрумом немного по другому, там больше пиздежа, но снова таки, Если ты не "босс" или чувак который принимает откровенные решения по проекту - то тебя это ебать особо не должно, так подключайся и подкидывай идейки во время брейншторма, и помогай их оценивать после брейншторма, да и улыбайся и корчи из себя крутого спеца.
Вот основные качества на которые следует обратить внимание при наборе персонала на работу, а не ебать мозг как себе так и человеку которого интервьюируете:
1. Знание того, на какую должно его берут, и того, что конкретно используется. Причем вопросы не из разряда знания фреймвёка от корки до корки, а конкретные ЛОГИЧЕСКИЕ реализации поставленной проблемы, и желательно попросить описать что и как будет делать, и т.п. и т.д. Желательно спрашивать сразу то, что не из курса обучения этой специфической хрени, а что-то более абстрактное и глобальное касающееся вашего разрабатываемого проекта. Банальный пример: есть АААА, нам нужно внедрить БББ, имеем следующий стек технологий х1 х2 х3, твои действия, и почему? А есть другие варианты этого? Если да - то какие, и почему хуже?
2. Умение логически рассуждать - это выходит из первого вопроса, многие могут решить очень сложные зазубренные хуйни, но на банальном вопросе сколько будет 2+2*2 застрянут. Только не нужно задавать вопросы, которые НЕ КАСАЮТСЯ вашей темы, из разряда известных головоломок, которые блядь НЕ ИСПОЛЬЗУЮТСЯ в вашей конторе. Вы же блядь не ПО для колодцев, речек и коз и капуст пишите? Заебали уже с этим говном блядь. Вы никогда задавая эти головоломки не узнаете ничего того, зачем собственно вы задаете ее (проверить логику будущего сотрудника), ведь: а) человек пришел к вам под стрессом, и сейчас у него стресс потому что блядь он хочет попасть на работу, это очевидно же. б) под стрессом человек не может думать в полную силу, человек хорошо думает в состоянии покоя без временных рамок и ограничений, или когда кто-то от него прям вот сейчас ждет ответ на вопрос. в) усугубляет ответ на вопрос и блокирует процесс мышления и рассуждения незнакомые люди, и то, что твой ответ будет блядь НЕ ПРАВИЛЬНЫМ, и на тебя будут смотреть как на говно, и это является триггером для бредогенерации и выдавания перлов, от которых чел даже если ему перезвонят не захочет идти на работу, Потому что чел с которым они интериировался знает какой он долбоеб, и как глупо выглядил (из-за ситуации которую он же мразь и создал).
Поэтому, дорогие уебаны которые берут на работу людей, делайте следующее:
1.) выпить \ закусить + пожрать завернуть 2.) шутки, анекдоты, девочки, и "дружеский круг" к тому ,кого берете на работу (только смотри условия ниже) 3.) после того, как в "дружеской" обстановке пообщались, познакомились, поговорили о всяком - только тогда блядь на основании: а) скила чела кого берете на работу, б) его коммуникационных качеств, в) личных предпочтений - берите на работу, и не ебите себе мозг. Я знаю даунов, которые создают себе и проблемы своим подчиненым потому что тайно хейтят мидлов которых набрали, Потому что как оказалось мидлы круче чем синьоры по всем параметрам, и эти уебищные "боссы", ссутся потерять свой авторитет, место под солнцем - и создают сладкую жизнь своим подчиненным завалами, либо другим сливам (варианты как слить подчиненного я думаю многим известны).
Ну и самое главное: - bitbucket / github с опытом работы, и попросить описать и пооткрывать что делал чел, как делал чел, если вы в теме того что вы разрабатываете и проекты схожи с тем что нужно делать - задавайте тупые вопросы почему и как и зачем чувак это залепил, если ответы удовлетворят, и видишь что чел не содрал откуда-то код а сам писал, и душу вкладывал, и понимает зачем и нахуя собственно он это все делал - смело бери. Если не шарит - шлите интелегентно нахуй, и назначайте ему перезвон который произойдет когда солнце взайдет на западе, и сяден на востоке - о моя Кхалиси.
>>861064 > Ну и самое главное: > - bitbucket / github с опытом работы бля, а если у меня нет ничего на этих ваших гитхабах? Ту хуету, что для себя пишу, я не хочу выкладывать, т.к. она нахуй никому не нужна, кроме меня. Или мне нужно в обязательном порядке иметь свой опенсорс проект или делать пул-реквесты в другие проекты?
>>861064 >bitbucket / github с опытом работы, С этого вот проигрываю всегда. Как правило все программисты сидят под NDA и не могут показывать свой код, созданный на прошлых местах работы. Откуда у меня возьмется битбакет? Я типа должен еще и в опенсорс коммитить? А когда? В рабочее время? А как к этому на работе отнесутся? В свободное? А может я все свои силы работе отдаю, вам же это даже лучше будет, не?
ну и дурак если ты не выкладываеьш даже уебищную хуйню. Надеюсь хотя бы участние в других проектах в резюме есть? Если нету, то пора бы задуматься если цель - зарабатывать деньги. Ведь все шляпы, которые даже толком нихуя не понимают набирают побольше резюме, что бы на большую ЗП претендовать. Это блядь только в кацап-хохло-бульбашо-стане резюме редко решает, а вот если за бугор уехать, то для них банальный очередной пунктик значит овер дохуя, ведь в этих нормальных странах, банальный такой проект (а если он еще и успешный в своем роде, и им пользуются люди) дороже любых слов.
Проверял так же и на себе неоднократно, хоть и не являюсь даже "нормальным программистом", уровень чека от клиента который видит весь послужной список, и который не видит его - разный, разный в раза 2, иногда и больше. И отношение совершенно другое (по умолчанию тебя считают за обезъяну, но если у тебя есть норм портфолио, то и разговаривают с тобой как с человеком, девелопером)
По поводу NDA, ну ты знаешь, NDA NDA рознь. Ведь в договоре указывается прямо что запрещено и как. И ты должен сознательно головой понимать и внимательно читать что подписываешь. Код то разный бывает.
>>861051 > виденье проекта, цели, и как достичь цели определяет тимлид\заказчик\твойбосс суть в том, что их видение работы над продуктом - это болото, в которое ты просто погрязаешь по уши и чем дальше, тем тяжелее себя вытянуть. и "болото" - это не ёрничание: технологии (в лучшем случае) 2007го года, бесконечные митинги о том "как бы нам на словах сделать так, чтобы там было лучше, и вы в итоге делали наше говно чуть краше, но на самом деле мы просто тратим тут время и ничего менять не будем потому, что нам и так хорошо, а на все остальное нам, ожидаемо, сереть", митинги митингов и митинги скрамов
> ты бы ахуевал если бы на себя пахал охуевал бы в каком смысле? в смысле нехватки времени, сложности задач в кратчайшие сроки, попытки грамотного построения работы команд(ы)? ну да, а чего нет? зато сейчас я не занимаюсь этим ничем, уже посмотрел весь Watch later в ютубчике, прослушал всю музыку в контактиках и уже тошнит от нее, начал играть в открытую на работе, но и это уже надоедать начинает. ну, а прикол в чем накой хуйни? я лучше буду дома сидеть 23 из 24 часов, а ради одного часа, которое я посвящаю с позволения сказать работы могу уже и оторвать жопу и приехать в офис. но так нельзя потомушто стэндап-митинг-хардворкингпроцессимитэйшн-митинг-документация-таймтрекинг с 9-00 до 18-00
ну если босс не шарит что он хочет, и все оставляет на отъебись своему низшему звену (девелоперам) хотя с клиентом обсуждают одну стратегию разработки ПО, а по факту делаете совершенно по другому, то это повод задуматься где ты работаешь и нахуй оно тебе нужно.
Суть kanban / agile / scrum в облегчении разработки и поставки нужного функционала в срок. Я не офисный работник, работаю сам на себя, но иногда работаю в командах над разными более-менее крупными проектами (опенсорс), и если честно из 100% сталкивался с 20% команд, которым agile / scrum / kanban наоборот облегчал разработку, остальных же 80% тащили тимлиды на своих плечах (в прямом смысле слова писали хуеву тучу всего и вся, и тем самым мотивировали других работать так же как и они), в итоге благодаря лишь вот этим отдельным личностям конторы \ стартапы \ опенсорс не выгорал. Но после того как такие тимлиды покидали разработку - они оставляли после себя наследие, чистый хороший код, кучу фич и т.п. и т.д., и дохуя мелких задач который бы лучше решить, так вот в этих самых 80% командах эти дауны после тим-лидов пересрались друг с другом о том, что кто-то кого-то не упомянул в комменте, или кто-то замержил раньше чем нужно фичу, либо кто-то просто бомбит от того, что у кого-то навыки лучше чем у него, и тем самым срачь продолжается. В резальтате с тимлидом были и канбаны и agile / scrum (в зависимости от проекта (но в основном kanban) а после него канбаны остались, методология проводится, но каждый сам выбирает что ебу ебашить - и делает. В результате получается нихуёвая такая каша из говна с разных ресурсов, и вроде бы какой-то прогресс есть - но никаких результатов и фич, которые достигались с тимлидом - уже нет.
Этим я хотел сказать что если главарь банды хуёвый - все будет хуёво. Если главарь банды заядлый маньяк и своей работой мотивирует других - все будет заебись, и agile / kanban только в плюс.
И да, в любом случае либо ебашит голова рыбы, либо тушка рыбы идет на дно.
>>861206 >Надеюсь хотя бы участние в других проектах в резюме есть? У меня нихуя нету. А у тебя есть? Скинь проекты, куда ты сам коммитил для примера. Чисто, чтобы заценить уровень, который котируется.
>>861792 Хуй знает насчет апача, но вообще можно настроить бридж из гита в свн, локально у себя работаешь как с гитом, а когда делаешь пуш в центральный репозиторий - он превращает это все в свн коммит.
Ниже - список тем, которыми я обычно интересуюсь на интервью. Я не жду, чтобы джуниор знал всё это, но сеньор обязан как минимум уметь поддержать разговор практически обо всём.
В порядке уменьшения важности:
• Классы и объекты. Инкапсуляция. RAII и почему оно важно. Наследование и полиморфизм, где и зачем. Хотя бы поверхностное знание, как работают виртуальные функции. Почему виртуальные деструкторы - хорошая идея. Копирование и перемещение.
• Как работает стек и чем он отличается от кучи. Управление памятью в целом и буферами в частности. Переполнение буфера.
• Исключения и что происходит при их выбрасывании. Как работает раскрутка стека. Взаимодействие исключений с деструкторами.
• Опыт с STL и базовыми структурами данных. Опыт с другими популярными библиотеками (например, Boost). Опыт с API ОС (Win32 и т.д.). Кросс-плаформенное программирование.
• Когда использовать несколько потоков. Потокобезопасность при нескольких операциях чтения и записи. Блокировки. Взаимные блокировки и как их избежать. Пулы потоков. Futures и promises.
• Разница (преимущества and и недостатки) между C++ и языками со сборкой мусора (C# или Java). Как эта разница влияет на построение программ.
• Фреймворки для тестов. Знакомство с основными IDE и платформами. Контроль версий, branching и merging. Гибкая методология разработки, опыт с ней, её преимущества и недостатки.
• Сетевое программирование. Разница между блокирующим и неблокирующим вводом-выводом. Messaging. Как TCP разбивает сообщения (подсказка: он этого не делает). ASIO-style асинхронный ввод-вывод с callback'ами. HTTP. REST. OpenSSL.
• Файловые системы. Строки и кодировки.
• SQL и базы данных, XML, Json парсеры.
Итак, анон, если ты не знаешь хотя бы чего-нибудь из списка - ты не программист, а ничтожество. И да, ты обязан знать всё это, даже если ты не пишешь на C++. Это элементарные и основные знания.