Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Тупые вопросы от рекрутера

Всем привет, это снова я. Человек, который пытается освоить профессию IT рекрутера.
В последнем топике вы мне помогли оценить классификацию позиций в IT, большое спасибо, было много ценных советов.
У меня несколько новых тупых вопросов.

Сегодня я набрала 6 пунктов из 10 в тесте на thecode.media/js-test, (как сказал мой знакомый програмист, такие достижения до 40 лет это «fucking amazing» :) ну и такой успех придал мне смелости для публикации, так что не судите строго

Итак, вопросы
1. Правильно ли я понимаю, что сейчас уже никто не занимается процедурным програмированием, и все происходит с помощью ООП? то есть спрашивать кандидата об этом — верх тупости?
2. Правильно ли то, что (грубо) фреймворки — это скелет, а библиотеки — куски мяса?
3. Правильно ли то, что в разных языках могут использоваться одни и те же фреймворки и библиотеки? Или для каждого языка свои библиотеки?
4. Правда ли то, что тесты от работодателя — это отстой, никто их не делает и все вопросы нужно решать на техническом собеседовании?

До встречи в следующих сериях «тупые вопросы от рекрутера», всем хорошего дня!

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Видимо, знакомый программист очень сильно хотел Вам польстить ;-) Не сильно обольщайтесь. Я за свою жизнь не написал ни строчки на JavaScript и мне выдало 8/10. Тест слишком простой.
Если хотите совета, завязывайте с техническими вопросами. Оставьте это дело техническим интервьюерам. Мне кажется, что Вы сейчас где-то на пике этого графика:
medium.com/...​ruger-effect-7934eb6fcf3c

Обидеть не хотел. Просто уверен, что у Вас некоторое опьянение от успехов и вам просто необходимо некоторое протрезвление.

Самое худшее в том, что вы будете ожидать однозначных ответов на свои вопросы. В то время как по мере понимания и получения опыта, все решения становятся все менее однозначными и более контекстно-зависимыми. В итоге, вы будете хорошо подготовленного интерна оценивать выше, чем реального синьора.

Правильно ли я понимаю, что сейчас уже никто не занимается процедурным програмированием, и все происходит с помощью ООП? то есть спрашивать кандидата об этом — верх тупости?

Спрашивать кандидата о вещах, в которых вы сами ниц не понимаете — верх тупости.

грубо) галеры — это скелет, а гребцы — куски мяса

:-)))

процедурным програмированием, и все происходит с помощью ООП?

Holywar mode unlocked

Сюжетный поворот: Елена — это на самом деле сорокалетний таксист-вайтишник Володя, который прикидывается блондинкой, чтобы ему толпа синьоров на DOU расписывала разницу между библиотекой и фреймворком, процедурным программированием и ООП.
Гениально!

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Есть еще тупой вопрос — сколько лет работы в Х. Та я может 3г назад сел почитать X, а потом формошлепил на Y, и решил снова взять за Х. Один кодер просто целый год просиживал штаны и высиживал время на галере, потом его выгнали, то что 4-й проект завалил, а другой кодер успел за год написать свой фреймворк на Х, и реально поднялся в области Х

Но нахрена только эти ритуальные танцы

ага говорят в Харькове было... ))

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

1. Рейтинги мов за останнй рік:
www.tiobe.com/tiobe-index
stackify.com/...​ogramming-languages-2018
Бачите, яка мова на другому місці? Це — C, чисто процедурна мова, без жодних натяків на ООП :)

2.Ні.

3. Це залежить від того, як написані бібліотекі. Можуть бути заточені під одну мову, можуть бути багатомовні.

4. Залежить від кандидата. Комусь подобається робити завдання, комусь — ні. Мені, наприклад, нудно витрачати час на нікому не потрібну фігню, тож просто перестав приймати пропозиції від роботодавців, які вимагають робити тестове завдання.

На самом доу ж был рейтинг языков. В Укр реалиях картинка несколько другая чем на тиобе

А что если это такой завуалированный кликбейт тестика по джс? conspiracy_keanu.jpg

1) Процедурное программирование живо в микроконтроллерах. Остальное на ООП/ФП.
2) Фреймвёрк — это хребет. Библиотеки — отдельные кости.
3) Не совсем. Некоторые популярные библиотеки портируют под другие языки, но порт почти всегда имеет некоторые отличия (и букет багов).
4) Отстой, но их иногда делают. А иногда отказываются от собеса сходу.

Тест ваш — ерунда полнейшая. 9/10, а я с ДжаваСкриптом не работаю и вообще мало знаком.

1) Процедурное программирование живо в микроконтроллерах. Остальное на ООП/ФП.

Расскажите это Линусу, потом напишете, куда он Вас пошлет)

2) Фреймвёрк — это хребет. Библиотеки — отдельные кости.

Нет, фреймворк — это экскаватор, библиотеки — это лопаты. Экскаватор не является набором лопат.

3) Не совсем. Некоторые популярные библиотеки портируют под другие языки, но порт почти всегда имеет некоторые отличия (и букет багов).

Часто порты — прозрачная обертка. Например, WxPython даже не имел отдельной доки — надо было по плюсам доку смотреть.

Расскажите это Линусу, потом напишете, куда он Вас пошлет)

Мнение Линуса меня мало волнует, как и Линуса — мнение Тененбаума.

Нет, фреймворк — это экскаватор, библиотеки — это лопаты. Экскаватор не является набором лопат.

Пример паршивый. Фремвёрк сам по себе — большая специфическая библиотека.

Часто порты — прозрачная обертка.

Но не всегда. Я к портам отношусь с подозрением. Имел печальный опыт.

Сегодня я набрала 6 пунктов из 10 в тесте на thecode.media/js-test, (как сказал мой знакомый програмист, такие достижения до 40 лет это «fucking amazing» :)

То ли это сарказм, то ли попытка добыть секс.

поскольку нас разделают полторы тысячи километров — первое:)

нас разделают полторы тысячи километров

ой да прям- некоторые кодеры готовы участвовать в миссии на Марс, если там обломится с марсианками, укомплектованными 3-мя выпуклостями :D

так может Ваш друг будет случайно в Вашем городе)

скелет и мясо? никогда не встречал такого сравнения

да, уже поняла, что оно неудачное. Я думала, что фреймворк — это такая основа, в рамках которой можно писать код, а библиотека- набор кусков такого кода, чтобы каждый раз не писать все с нуля. Мне тут уже обьяснили, что это не совсем так.

думала, что фреймворк — это такая основа, в рамках которой можно писать код, а библиотека- набор кусков такого кода

А вот кстати да, как то так и есть.

вот теперь я запуталась :) если скелет — это основа для кода, а мясо — куски кода, которые крепяться к скелету, то о чем вообще весь сыр бор, выходит, изначально я правильно все поняла.
Или же. Библиотека и фреймворк суть одно и тоже, фреймворк — это «разжиревшая» библиотека просто.

фреймворк — это «разжиревшая» библиотека просто.

По-моему для простоты Вам легче всего думать именно так.
Библиотека — это нечто готовое, что ты используешь для решения задачи.
Фремворк — такая разжиревшая библиотека которая задает тебе структуру твоей программы.
Аналогия со скелетом не очень точная, но вобощем близкая. Ниже писал, что фремворк переводят и как «каркас».
Но тут тоже грань немножко зыбкая.. И фремворки бывают разные вот .Net фреймворк и Qt тоже вроде фреймворк, а вот внизу Виктор в этом сомневается..

«вам легче думать именно так» это супер фраза, буду пользоваться, спасибо

Ну так если сами договриться не можем то чего вам этим голову сушить?
И то же самое будет если спрашивать про ООП. Человека у которого хоть один из основных языков объектно ориентированный (а таких большинсво) это то же самое что и спрашивать «а ты точно програмист». С другой стороны можно и нарваться на ответ «ООП ничто — монады все» или на рассказ про то что JS на самом деле не объектно ориентированный а объектный язык и програмирование там тоже объектное, но не такое как в ObjectC, который таки объектно-ориентированный. Вам оно точно не надо ибо ответ оценить не сможете, да и поддержать такой разговор вообщем-то не каждый девелопер сможет.

а ты точно програмист — запишу в свой список вопросов, этого должно хватить на первое время

да я выходит прям генератор полезных цитат..

Мне? не ну я польщен конечно, но с какими вопросами я мог бы обращаться?

Это, скорее, Вам может быть приятно или познавательно.

Возможно, но пока йоги мне хватает и лень.

Каждый понимает по-своему, поэтому холивор, но ленивый, потому что настоящим холиворщикам не интересно читать про рекрутеров.

Библиотека и фреймворк суть одно и тоже, фреймворк — это «разжиревшая» библиотека просто.

Нет, дело тут не в размере. Давайте попробуем на отвлеченном примере, может?

Если вы откроете холодильник, вы там найдете кучу всяких компонентов, из которых можете приготовить кучу всяких ништяков. Эти компоненты — аналог библиотек в обсуждаемом контексте. Вы вольны выбрать любые и попробовать из них что-то собрать удобоваримое.

Но вы можете также заказать себе на дом recipe box — и вам привезут а) четко отобранные компоненты и б) рецепт (реже несколько) блюда, которое можно приготовить из этих компонентов. Вам не нужно даже думать что и как с этим делать — все придумано за вас. Бери и делай по инструкции. Вот это и будет аналогом фреймворка в обсуждаемом контексте — не просто набор компонентов, но набор компонентов, кем-то отобранных и «заточенных» для решения конкретной задачи или класса задач.

Причем заметьте, что дело в размере. Скорее всего, в вашем холодильнике найдется сильно больше компонентов, чем в среднестатистичском recipe box, а отдельные компоненты могут превышать весь бокс и по массе, и по объему. Дело в фокусе, специализации если хотите.

З.Ы. Аналогия хромает как минимум в том смысле, что компоненты в моем примере — де-факто расходники, а в обсуждаемом контексте суть в повторном использовании компонентов/библиотек; но думаю что этим различием можно пренебречь :)

По классике до-тотально-фронтэндовских времён, да термины использовались в основном именно в таком смысле. Фреймворк — это когда уже есть всё для создания хоть и пустого, но работающего продукта минимальными усилиями, а дальше нужно в него встраиваться (метод уже зависит от реализации) и наполнять своим содержанием. Библиотека — это когда есть достаточно компонентов для реализации функциональности, но как именно их склеить во что-то работающее — дело уже сборщика. Например, автомобильная аналогия (с огрехами, но для старта пойдёт): фреймворк — купили автомобиль, он уже ездит, но можно переоборудовать под себя; библиотеки — можно брать кузов, двигатель и т.п. раздельно и соединять как хочешь.
Сейчас, похоже, эти термины сдвинулись, но не до конца.
И ещё есть претензии некоторых авторов называть «фреймворками» свои разработки для понтов (типа, у нас есть всё).

ru.stackoverflow.com/...​мворком-библиотекой-и-api — вот подробное описание отличий фреймворка библиотеки и API

В старых-старых книгах, слово фреймворк иногда переводили как «каркас»..

Каркас, скилет, экзоскилет, костыль... какая разница..

Стройная система костылей и подпорок ©

До встречи в следующих сериях «тупые вопросы от рекрутера»

Ну правда интересно, вы стали бы задавать эти вопросы на интервью? И что делать с развернутыми ответами, а ещё хуже — встречными вопросами? :)

Если это желание разобраться с требованиями к вакансии с которой будете работать, то почему не спросить заказчика вакансии по всему что там желают?

Я думаю, беседы рекрутеров с соискателями вообще нельзя называть интервью или собеседование. Это разговор за жизнь. Если условия, которые предлашает компания, интересны соискателю, он рассматривает релокацию, и его стек подходит — все, что мне остается, это узнать получше его потребности, пожелания, наличие времени на поездку на тех интервью, пожелания по билетам, да и просто познакомится с человеком. Я не планирую делать вид, что что-то понимаю в стеке. Но это не мешает мне стараться понять. Чтобы человеку не совсем с дубом разговаривать.

Вот пока вы не лезете в не свою область, вы производите впечатление профессионала. А вот когда начинаете беседовать о том, чего не понимаете, как раз и можете показаться «дубом».

у меня нет цели производить впечатление. И в жизни, и в работе лучше всего быть собой. И учиться.

Сюжетный поворот: Елена — это на самом деле сорокалетний таксист-вайтишник Володя, который прикидывается блондинкой, чтобы ему толпа синьоров на DOU расписывала разницу между библиотекой и фреймворком, процедурным программированием и ООП.
Гениально!

Да пруфов не будет, расслабься :)

1. Нет, нет, да, верх тупости.
2. да
3. Нет. За редким исключением.
4. да.

Кста, а что такое процедурное программирование?

Чет кажедться что имееться ввиду вовсе не олд-скул лапша написанная на пехехпе, где в одном файле хтмл, бизнас логика, квери в таблицу и еще черти что.

процедурное представляю именно как лапшу, написанную без особой структуры с нуля, не знаю, правильно ли это мое представление

Правильно ли я понимаю, что сейчас уже никто не занимается процедурным програмированием, и все происходит с помощью ООП? то есть спрашивать кандидата об этом — верх тупости?

Спрашивать кандидата о вещах, в которых вы сами ниц не понимаете — верх тупости.

план мой хитер — я не собираюсь делать вид, что что-то понимаю, расчитываю, что сами кандидаты в процессе беседы меня чему-нибудь и научат. Глядишь, через пару лет я начну лучше во всем этом разбираться.

Смотрите: не зная или поверхностно зная предмет, во время собеседования можно невзначай сморозить какую-то глупость. В результате у кандидата может сформироваться негативное мнение не о Вас, а о компании, которую Вы представляете. Оно Вам нужно?

Во-первых, другого пути нет, все начинают с того, что морозят глупости, во-вторых, мне кажется, когда прям сразу говоришь — я только учусь, не разбираюсь пока в этом, то можно рассчитывать на более лояльное отношение, нет?

Не всегда. Все люди разные. Кто-то будет более лояльно относиться, кто-то — нет. Мне, например, коллега говорил, что устраивался в компанию, и ему рекрутерка говорила ересь о технологиях, которые он использовал в прошлом.

Надеюсь, ваш коллега выжил после такого шока :) Если серьезно, то, скажи ему рекрутерка что-то вроде:"Смотрите, вот такой вопрос к вам по таким-то технологиям. Я очень извиняюсь, но не ересь ли это? А то я пока не разобралась с вопросом" , то, возможно, его шок был бы поменьше

:)
Да, это нормальный вопрос. Только ... ответ на него тоже может зависеть от того, кому его задали. Подавляющее большинство правильно поймут ситуацию и адекватно ответят. Но найдутся индивидуумы, которые сочтут этот вопрос ловушкой, психологическим тестом — да чем угодно, и отвечать будут уже исходя из такого превратного понимания. Вообще, оставайтесь собой. Спрашивайте так, как если бы разговор был бы не с кандидатом, а с новым знакомым на дне рождения Вашей колежанки.

Есть другой путь. Прочитать 3 статьи в википедии.

1. Правильно ли я понимаю, что сейчас уже никто не занимается процедурным програмированием, и все происходит с помощью ООП? то есть спрашивать кандидата об этом — верх тупости?

ООП — это расширение процедурного для лучшего понимания и читабельности кода. Никакого влияния на сам функционал ПО разница между ООП и процедурным не несет. Более того на базе чистых ООП языков, таких как Java можно реализовать процедурный подход при желании (у меня получилось когда я был студентом, но этот код я никому не покажу).

А вообще есть два основных класса программирования: императивное и функциональное. Только на собеседовании кандидатам это не упоминайте, а то посмотрят как на блондинку с пятым размером, которая PhD по квантовой физике.

2. Правильно ли то, что (грубо) фреймворки — это скелет, а библиотеки — куски мяса?

А правильно что DVD — это фильмы, а Blu-ray — это блокбастеры? Фреймворки и библиотеки — это одно и то же, но фреймворк — это совокупность библиотек, подчиненная определенной архитектуре.

3. Правильно ли то, что в разных языках могут использоваться одни и те же фреймворки и библиотеки? Или для каждого языка свои библиотеки?

Да, мы предоставляем библиотеки на несколько языков(C#, VB.NET, Java, C++). Хотя бывают специализированые библиотеки, под одну технологию. Например библиотека Task Parallel Library работает только на всех языках .NET (C#, VB.NET, F#, C++/CLI).

4. Правда ли то, что тесты от работодателя — это отстой, никто их не делает и все вопросы нужно решать на техническом собеседовании?

У нас дают тестовое задание, на собеседование приглашают только после его выполнения. Может это и неправильно, но работает.
PS
Те кто на собеседовании предлагает психологические тесты — должны гореть в аду.

Ну почему, инкапсуляция нужна только для того чтобы шаловливые ручки пользователя класса не залезли туда куда не нужно, полиморфизм вместо VMT можно реализовать на switch..case.

PS
Когда я говорил что реализовал процедурный подход на лабах на java я не шутил...

Никакого влияния на сам функционал ПО разница между ООП и процедурным не несет.

Лол, да любая парадигма, язык, пиши ты хоть на джаваскрипте, асамблере или на брейнфаке — никакого влияния на функционал это не несет.

того на базе чистых ООП языков, таких как Java можно реализовать процедурный подход

Джава не чистый ООП язык. Но тону лапши с кашой с шеред стейком можно таки на чем угодно написать.

Так и на ООП можно написать нечто такое, что процедурная парадигма эталоном изящества окажется.

Для читаемости лучше все свои сущности представлять в виде стандартных паттернов, а реализация уже дело такое. Например тот же синглетон можно реализовать 6-ю способами, но для использующего это неважно.

Слово синглтон в ооп с класами, в ооп без класов, в процедурном, в функциональном программировании будут кагбы совершенно разные понятия.

Синлетон — это всегда ОДИН объект на ОДНУ глобальную сущность AppDomain/библиотеку/процесс/иногда всю систему, если он на мьютексе. Если синглетоном называть объект на ту же пользовательскую сессию, то это не синглетон, а контекст.

Так что если тебе говорят про синглетон в контексте глобальной сущности, то тебе пофиг на реализацию, ты всегда знаешь что это такое и что от него ожидать. Все остальное детали доступа.

Синлетон — это всегда ОДИН объект

Не в ооп языках нету объектов.

Есть, только они называются struct или record.

Ну если вы объект от структуры отличить не можете, то нам тут разговаривать кагбы не очем.

Физически структура — это объект. Например при разработке драйверов Windows используется идеологическая модель ООП, не смотря что в основном там чистый C и структуры (хотя ничего не мешает писать на С++, даже с виртуальными методами, разве что без std).

Возьмем С:
Есть структура с данными и указателями на функции, принимающие указатель на эту структуру первым аргументом.

Возьмем Питон:
Есть объект класса, в словаре которого содержатся ссылки на объекты данных и на методы с первым параметром self.

Возьмем С++:
Есть класс, при инстанциации которого создаются структуры, содержащие данные и указатель на массив указателей на функции с типом первого аргумента равным указателю на данный класс или его родитель.

Какая между ними разница?
Кто из них объект, а кто — структура.

Есть структура с данными и указателями на функции, принимающие указатель на эту структуру первым аргументом

Cтруктура с указателями на функции, ака обладающая поведением это совсем не то же самое, что просто структура. Что не отменяет того что на С тоже можно писать в ОО стиле...

gstreamer-а не видел, но тут коллеги на соседнем стриминговом проекте какую-то ком-подобную компонентную систему на С зафигачили...

Кому-то когда-то это показалось хорошей идеей.

Буйство терминологии.

Чем масив в памяти отличаеться от структуры в памяти ? Мы так прийдем что масивы и переменные в памяти тоже объекты.

.NET их всех определяет как object. Верим Путину Сатье Наделле.

и че ? какое отношение эт имет к процедурному программированию и си ?

Ежу понятно что имея указатели на функции, можна сэмитировать методы на объекте. Осталось выяснить как можно сделать «тру синглтон» на сях.

Через статическую переменную внутри функции, конечно.
Singleton* Instance() {
static Singleton* inst = NULL;
if(!inst)
InitInst(&inst);
return inst;
}

Что мешает создать структуру

Singleton

в любом другом месте обойдя метод

Instance

?

Мозги)
Ну и толку ее создать — ее еще проинитить надо)
А функция InitInst() статическая внутри модуля, который за синглтон отвечает. Снаружи код ее не видит.

int *SingletonInt() {
static int instance = 42;
return &instance;
}

Инт это объект — ок.

Если вы докажете, что это класс — бросьте в меня камень.

Вот а теперь ответь, это С является ООП языком, или это ты структуру в С от объекта не можешь отличить)

Вот а теперь ответь, это С является ООП языком, или это ты структуру в С от объекта не можешь отличить)

Мой изначальный поинт:

Слово синглтон в ооп с класами, в ооп без класов, в процедурном, в функциональном программировании будут кагбы совершенно разные понятия.

Или модуль (файл с исходником)

спасибо за подробный ответ. А что не так с психологическими тестами?

Они дурацкие, не дают никаких ответов и тратят время и соискателя и рекрутера, без какой либо пользы. Лучше уже гадание по гороскопу (ну или картам Таро), так как день рождения назвать проще.

Может, там лимиты на экспорт чужих резюм.
Мне тоже такое писали.

Но, не страшно, это норма для всех постовковых хрюш.

В пиндостане местами хуже. Мало того что спрашивают резюме при линкедине, так еще местами пойди на специальный сайт компании, и всю туже информацию — вручную 3-й раз заполни.

Сиви которые генерит линкедин весьма ущербные. Как впрочем продукт любого шаблонизатора. Возможно, это мое лично эстетическое мнение, но если я с хр уже дошел до этого пункта, мне не впадло скинуть и свое личное. Оно всяко красивше.

Видимо, знакомый программист очень сильно хотел Вам польстить ;-) Не сильно обольщайтесь. Я за свою жизнь не написал ни строчки на JavaScript и мне выдало 8/10. Тест слишком простой.
Если хотите совета, завязывайте с техническими вопросами. Оставьте это дело техническим интервьюерам. Мне кажется, что Вы сейчас где-то на пике этого графика:
medium.com/...​ruger-effect-7934eb6fcf3c

Обидеть не хотел. Просто уверен, что у Вас некоторое опьянение от успехов и вам просто необходимо некоторое протрезвление.

Самое худшее в том, что вы будете ожидать однозначных ответов на свои вопросы. В то время как по мере понимания и получения опыта, все решения становятся все менее однозначными и более контекстно-зависимыми. В итоге, вы будете хорошо подготовленного интерна оценивать выше, чем реального синьора.

ок, обьясню. Никаких иллюзий у меня нет. Тест там вообще шуточный, мне кажется. Обидеть можно только того, кто готов обидеться, это точно не я. Опьянения от «успехов» нет, как нет и самих успехов :) Ответов однозначных я никаких не жду, и вообще не планирую никого оценивать.
Как я это вижу.
Разговор не технического рекрутера и кандидата — это вообще никакое не собеседование. Это знакомство, болтовня за жизнь. Моя работа в этот момент — узнать, что хочет кандидат. Спросить, как он видит — подходит ли его стек, какой он видит своюбудущую работу. Интересует ли его релокация. На каких условиях. Есть ли у него семья. (Потому что переедет он или нет во многом от этого зависит). Если коротко — я должна понять, могу ли я ему что-то предложить. Чтобы продать вакансию, нужно знать потребности кандидата.
Я никого не оцениваю, это происходит на тех собеседовании.
При этом. Ничто не мешает мне «учиться об кандидата». И на сотым знакомстве знакомых слов будет больше. И человеку общаться со мной будет приятней, поскольку разговор будет более предметный.
Этот рынок в Украине какой-то кривой, по-моему. Судя по вашим отзывам. Ибо рекрутер нужен для того, чтобы кандидату было лучше и проще, а не наоборот.

получается, если нет тех знаний — сиди тихо, не высовывайся. Если пытаешься что-то понять- куда ты лезешь, не обольщайся. Если говоришь — ок, я вас не оцениваю, так, знакомлюсь, вас потом оценит тех рекрутер — ты вообще детский сад. Я 10 лет работаю с людьми. Ищу их, обучаю, организую работу, мотивирую, помогаю получить повышение, сменить работу. Просто все это я делала в другой сфере. И да, в IT все пока сложно. Именно поэтому я здесь.

это сарказм. Меня, разумеется, не интересуют ваши указания на тему что мне делать, а что нет. Если у вас нет желания отвечать на тупые вопросы (которые специально называются тупыми, чтоб те, кто их не любит, молча прошли мимо), то ваши рекомендации на отвлеченные темы излишни

Возможно я и поторопился с выводами. Но как-то странно, что вы со ссылкой на знакомого программиста сначала говорите про феноменальный результат, а теперь называете тест шуточным...

Ладно, оставим это. Тем не менее, я уверен:

1. Рекрутеру нет вообще никакой необходимости говорить о технологиях. Самый лучший вариант, это качественно поработать с техническими интервьюерами и хайринг-менеджером на предмет того, какие технологии обязательны, их приемлимые альтернативы и что желательно. Задача же рекрутера получить у кандидата селф-ассессмент в отношении его экспертизы в них. Желательно в виде закрытого вопросы (годы опыта или по предложенной шкале). Все. Попытка «общаться» будет выглядить по меньшей мере глупо. Помимо этого — рассказать о плюшках компании (чтобы не тратить на это более дорогое время ТИ и ХМ), выяснить доступность (ищет ли вообще кандидат работу), выяснить Нотис период, зарплатные ожидания, уточнить что мотивирует (или могло бы мотивировать) сменить работу, готовность и мотивацию к релокации, командировкам (если применимо). Толерантность к овертаймам (если применимо). Английский и/или другие языки. Все. Этого достаточно для того, чтобы заполнить 15-20 минутный разговор. Больше не надо. Берегите свое время и время кандидата. «Дружеские» беседы о технологиях с человеком, который в них ничего не понимает, это хорошо только для одного. Проверить вспыльчивость человека ;-)

2. Строить выбор кандидата в Германии на основании семейного положения не только не разумно и неэтично, а даже незаконно. Думаю, почему незаконно и неэтично — понятно. Не разумно потому что одним из самых больших мотиваторов к переезду является улучшение качества жизни именно детей. В-общем, оставьте кандидату самому разбираться с вопросом готова ли семья к трансферу. В крайнем случае, после интервью накидайте ему несколько отобранных статей об основных проблемах, с которыми сталкиваются люди. Чтобы знал, с чем придется столкнуться. (Только не ведитесь на страшные русскоязычные статьи о буйствах беженцев).

я думала, что фраза о том, что такие достижение до 40 лет — это факинг эмейзинг (я про тест) как бэ намекает на то, что в оценке присутствует сарказм. Ну ок, оставим тест в покое.
Вы все очень правильно пишите, это и есть список тем, которые я планирую обсуждать с кандидатом, все так. Но ведь ничто не мешает мне ПЫТАТЬСЯ разобраться в технологиях, если я планирую работать в сфере чуть дольше, чем две недели, не? Если у кого-то со вспыльчивостью проблемы, то это обычно видно, тогда да, зачем доставать вопросами человека, который не хочет на них отвечать. Но есть люди (в том числе и тут, как оказалось), которые даже любят обьяснить что-то сложное по своему профилю простыми словами человеку, который ни черта в этом не понимает.
Топик специально назван ТУПЫЕ вопросы, чтоб прям сомнений не оставалось по поводу моей оценки своих же знаний. По идее, само название должно убедить пройти мимо людей, которые тупые вопросы не любят.
Итого имеем несколько типов людей
-не любит тупые вопросы, проходит мимо
-иногда любит потратить 30 секунд времени на то, чтобы ответить на чей-то тупой вопрос, почему нет
-любит почесать свое эго о чей-то тупой вопрос и почувствовать себя умным, на сам вопрос по сути не отвечает

Но ведь ничто не мешает мне ПЫТАТЬСЯ разобраться в технологиях, если я планирую работать в сфере чуть дольше, чем две недели, не?

Если цель вашего «разобраться» это поднять свой уровень знаний с 0 до 3 по шкале от 0 до 1000, то вы все правильно делаете. Для меня это иллюзия понимания, которая скорее опасна, чем полезна.

ну вот да, вы все правильно поняли про шкалу. Я не верю в истории типа «одна девочка долго задавала тупые вопросы на ДОУ и стала програмистом». Скорее «одна девочка долго задавала тупые вопросы и перестала шарахаться от незнакомыхслов в резюме кандидатов»

Но ведь ничто не мешает мне ПЫТАТЬСЯ разобраться в технологиях, если я планирую работать в сфере чуть дольше, чем две недели, не?

Не переживайте, со временем вы чему-то научитесь, розовые очки спадут и Ваше отношение поменяется, Вы станете как все остальные рекрутеры и это нормально.

Но ведь ничто не мешает мне ПЫТАТЬСЯ разобраться в технологиях, если я планирую работать в сфере чуть дольше, чем две недели, не?

Значит так, чтобы попытаться разобраться в технологиях:

  1. Выбираете любой из модных фронтенд-фреймворков
  2. Пишете туду-лист. Это легко, так как обычно в туториале именно туду-лист и показывают
  3. Берете документацию по google spreadsheets, прикручиваете авторизацию и делаете так чтобы тудулист сохранялся туда

    1. Альтернатива — firebase, но google spreadsheets прикольнее
  4. Заливаете код на github
  5. Берете самый дешевый сервер на DO, покупате доступный домен (или бесплатно например pp.ua) и делаете чтобы тудулист был расположен на сервере и с этого домена работал. Не забудьте про https, потому что по http в 2019 году работать уже как-то вообще не очень

Результат и код показываете фронтенд или фуллстек синьору, который готов выделить время на оценку. Он вам расскажет как всё неправильно (или не расскажет, если захочет польстить).

Это начальный уровень фронтенд веб-разработки, на котором человека могут взять на работу скажем интерном. Может даже джуном, если в довесок выучить различной теории из Computer Science.

UPD. Забыл что нужно еще сделать красиво и аккуратно и продемонстрировать умение работать с UI-фреймворком. Bootstrap, например (хотя мне больше нравится UIkit)

Результат и код показываете фронтенд или фуллстек синьору, который готов выделить время на оценку. Он вам расскажет как всё неправильно (или не расскажет, если захочет польстить).

А если синьор в глаза никогда не видел google spreadsheets? Каков алгоритм дальнейших действий?

Эм, код он тоже в глаза не видел? Могу предложить как альтернативу писать ещё и бекенд на ноде, но это несколько дольше и уже далеко от просто ознакомления

Вы занимаетесь чемто не тем. Вас же любой июнь просто по столу размажет с такими знаниями

так а я не собираюсь ни с кем «меряться знаниями». Разумеется, любой человек, написавший хоть строчку кода, по определению знает больше меня. У меня нет цели ни проверить его, ни оценить. Это будет происходить на тех собеседовании. Но этот факт не мешает мне учиться и стараться узнавать новое, дабы человеку не совсем с дубом разговаривать пришлось.

процедурным програмированием, и все происходит с помощью ООП?

Holywar mode unlocked

все происходит с помощью ООП?

Успокойтесь, далеко не все :8) И процедурное никуда из С-сей не делось; и более того, если говорить о С++, то и ООП — это уже вечер вчерашнего дня, в струе сегодняшнего — обобщенное программирование, которое вносит новые грабли в «старое доброе» ООП.

Правда ли то, что тесты от работодателя — это отстой,

Правда-то правда, но вполне возможно, что работодателю они дороги и близки к сердцу, поэтому если вам плотют денежку, то пренебрегать ими не стОит.

Различие в том, что фреймворк дает готовое решение для какой-то определенной задачи. В этом решении надо подставить своим кодом пару критических выборов — бизнес логику — и оно заработает. Фреймворк вызывает твой код и спрашивает, что сделать в данном случае.

Либа дает набор инструментов, но сама ничего не делает, пока не попросишь. Ее можно юзать с любой стороны где покажется полезным.

QT это фреймворк. MFC для microsoft vc++ тоже фреймворк хотя оно официально так не называлось. а остальное не знаю, наверное либы. Грубо говоря фреймфорк — это каркас приложения, который навязывает определенную архитектуру. Перенести приложение с одного фреймворка на другой == полностью его переписать. Либа это просто реализация набора функций. От замены одной либы на другую, архитектура приложения не пострадает и не изменится (смотря как написано конечно, но если в соответствии с принципами хорошего ООП и СОЛИД то не должно сильно измениться )

Фреймворк — вызывает написанный код.
Библиотека — вызывается написанным кодом.

Определение не то, что бы точное и универсальное, но, в основном, рабочее.

GStreamer, насколько я знаю, фреймворк.
ffmpeg — библиотека, по крайней мере, когда не пишешь расширения.
SAPI — не знаю, что это.

откуда вы знаете, чем я «пытаюсь заниматься с програмистами» :))) нет, не пытаюсь. Оценивать тех навыки не моя задача. Почему это должно мне мешать учиться, стараться разобраться, понять лучше предмет разговора, я не пойму. «Ты полезла не в свои компетенции» — это называется учиться. Когда мне механик машину чинит — да, я как минимум спрашиваю, что он делает и зачем. И если бы починка машины происходила каждый день,то через пару лет таких вопросов я бы точно знала больше о ремонте машин.

думала у програмистов с логикой все получше. Вопросы задают не когда «все знают», а наоборот. У вас какой-то триггер, связанный с задаванием вопросов, подумайте, почему вас так бесит, когда кто-то, кто чего-то не знает, спрашивает? это ж нормальная тема.

Ці питання сенсу не мають. Слова окремо — загалом мають, а разом — не дуже.

1. Ніхто не знає, що таке процедурне програмування і до чого там ООП. Є діхотомія функціональне vs імперативне, а ООП там взагалі збоку, може як бути так і не бути в обох стилях. Обидва стилі живі, імперативного набагато більше.
2. Інколи різниця стирається. Загалом відповідь скоріше ні. Фреймворк це розжиріла бібліотека.
3. Так, але доволі рідко. Практично скоріше у кожного свої.
4. Тех. співбесіда — це теж такий тест і на ній можуть бути тести. Тех. тест на дом — інколи має сенс. Психологічні тести практично не мають сенсу і скоріше гірше зроблять.

Превед. Ты напиши мне в личку, я тебе популярно поясню голосом

я б тричі подумав перед тим як дослухатись до цієї опції :)

Ты наверное не нанимал программистов.

большое спасибо, я обязательно воспользуюсь

У меня несколько новых тупых вопросов.

Главное, побольше тупых вопросов, а то тут скучно как-то. Можно и на собеседованиях.

а вот скажите, если рекрутер вам изначально сказал, что да, это не тех собеседование, это вообще не собеседование, так, знакомимся, никто вас не оценивает, ибо нет навыков и знаний для этого, но все же задает тупые вопросы — это прям сильно бесит?

Смотря кого, меня лично вообще не бесит, у меня с нервами всё в порядке, можете проверить.

Сегодня я набрала 6 пунктов из 10 в тесте на thecode.media/js-test

а зачем это рекрутеру? Ну кроме как закрепить официальную границу результата, ниже которой разраб делает себе харакири в центре опенспейса :)

Вообще не в курсах жабы скрипта. Но 9 из 10.

Сегодня мы собрались тут, чтобы принять в свой орден брата Виктора, который после долгих лет блужданий во тьме, встал на путь истинный и внял мудрости учений пророка Айка! Один из нас! Один из нас!! Один из нас!!!

Не поверил, что даже такую наколенную поделку можно сделать за 10 дней.

Ну 10 дней на создание вселенной жабаскрипта, это уже на 3 дня больше, чем 7 ;)
Там только пара вопросов специфичны для жабаскрипт, а так по логике и других языках можно догадаться. Разве что вопрос c 1 + toString() + ’1′, но и тут можно и без знаний понять к чему клонят :) Было бы удивительно если бы кто не знал какой будет i после цикла )

А вот какой будет i после цикла — зависит от языка. В некоторых языках i после выхода из цикла может уйти из области видимости.

В C# переменная, объявленная в цикле, там и остаётся.

раньше за такое сиськи присылали
а щас не, кругом софтскилы, быкуй как хочешь называется

да, времена изменились :) раньше за переустановку винды вообще, я слышала, можно было не только фотку сисек получить

Сиськи сейчас ничего не гарантируют, с современными достижениями пластической хирургии. Надо писечку

вы, по ходу, не все знаете о современной пластической хирургии :) с писечками там тоже уже разобрались

Писечка дороже. Да и всё равно на настоящую будет не очень похожа

1. Занимаются, в зависимости от языка и задач.
Спрашивать имеет смысл только в некоторых случаях, когда на одном и том же языке можно писать и так, и сяк, и нужно выяснить, знаком ли кандидат с нужной парадигмой. На том же питоне можно писать хоть процедурно, хоть функционально, хоть объектно-ориентировано, в зависимости от требований на проекте и умения программиста. Может, для джуниора вопрос может быть и уместным.
Спрашивать матерого джависта, может ли он в ООП... Хотя реакция может быть любопытной :-)

3. У каждого языка свой набор фреймворков и библиотек (исключение — экосистемы, которые уже упоминали), при этом у многих языков есть фреймворки, которые воспроизводят одну и ту же архитектуру. Типичный пример — MVC-фреймворки, которых сотни, и они существуют практически для всех популярных языков (причем для некоторых языков их могут быть десятки). Поэтому опыт с одним фреймворком определенного типа может большей частью заменить опыт с другим фреймворком того же типа для того же языка, и даже опыт с фреймворком того же типа, но для другого языка.

Вот это вот.

грубо) галеры — это скелет, а гребцы — куски мяса

:-)))

а вот на тренингах для рекрутеров програмистов называют не гребцами, а rockstars :)

На фермах так корів називають що дають високі надої.

Rockstar это только один из типов гребцов.

Тут нет противоречия: идеальный конечный результат работы рекрутера — это нанять рокстар по цене куска мяса :)

Сам себя не похвалишь — сидишь как оплеванный?

куски мяса — это если годные гребцы, а если не очень то другие куски

Правильно ли я понимаю, что сейчас уже никто не занимается процедурным програмированием, и все происходит с помощью ООП? то есть спрашивать кандидата об этом — верх тупости?

1. Процедурное программирование вас врядли интересует на сегодняшний день, хотя есть языки (С, Go?) которые можно отнести к этому типу и они активно используются. Но вот функциональное — очень даже да и оно не имеет отношения к ООП. Так что почитайте что оно означает.
2. Не пытайтесь какие-то человеческие аналогии притягивать, иначе в какой-то момент не поймете когда говорите какую-нибудь очередную чепуху думая, что знаете о чем говорите.
Библиотека — делает какую-то работу. Фреймворк — набор библиотек для выполнения какой-то конкретной бизнес-задачи широкого смысла целиком.
Например, есть game development фреймворки — это набор библиотек с помощью которых можно сделать игру. Или фронт-енд фреймворк — набор библиотек, с помощью которых создается полноценное клиентское приложение. И т.д.
3. Как правило, фреймворк предназначен для конкретного языка/технологии, но может поддерживать несколько языков. Типичный пример — .NET framework. Фреймворк один, а языки можно использовать разные — C#, F#, VB.
4. Если многие работодатели дают тесты, то кто-то их все-таки делает :) Тесты — инструмент. До того как сказать что лопата — это отстой, и никто ей уже давно не копает, ответьте на вопрос какая лопата, и что ей пытаются выкопать.

наконец-то более ли менее человеческое обьяснение про фреймворки и бибилиотеки, вы удивитесь, но во всяких статьях для чайников это так и опысывается, на человеческих аналогиях, какие-то дебри про строительство дома и т.п., вы понятно обьяснили, и то, что фреймворк — это набор библиотек, новость для меня, спасибо
Про лопату смешно, да. Спасибо!

а подойти к IT-шнику напрямую, уже не судьба?

При всех различиях меня и Вас, уверен, мы примерно одинаково обьясним понятия библиотека/фрейм. Если бы ей было не всё равно, начала бы копать у себя в огороде

З усією повагою, але bullshit вимовляється як /ˈbʊlʃɪt/

это в британском английском, в нью-йорском акценте, техасско, шотландском или новозеландском ?

1. Процедурное программирование вас врядли интересует на сегодняшний день, хотя есть языки (С, Go?) которые можно отнести к этому типу и они активно используются.

В Go поддерживаются все парадигмы программирования, и ООП тоже есть в новой интерпретации. Просто предыдущий подход абсолютно всё лепить исключительно вокруг классового ООП — морально устарел, особенно со всяким бредом наподобие множественного наследия C++. ООП теперь используется в Go как и всё остальное, только по мере необходимости, и не более того.

А чем тебе множественное наследование в питоне не нравится?

Go как раз и создан для замены python и C/C++. Тем более, что в этих языках всё равно нет прототипного ООП, которое на самом деле имеет большую ценность, чем классовое. Поскольку всё равно в практических задачах зачастую используется либо один объект класса, либо каждый экземпляр имеет какие-то уникальные свойства. Нет никакого смысла вообще в принципе городить множественное наследование, когда можно применять утиную типизацию интерфейсов, и таким образом избежать создания множества классов во всех комбинациях.

которое на самом деле имеет большую ценность, чем классовое

Вот расскажешь это нескольким поколениям программистов мейнстрим языков. Особенно будут доставлять преимущества прототипного для строк или комплексных чисел.

Нет никакого смысла вообще в принципе городить множественное наследование

 И по скорости работы будет то же самое, что С++ отресолвит во время компиляции.

Вот расскажешь это нескольким поколениям программистов мейнстрим языков

Да без проблем, я и сам программист мейнстрим языков.

Особенно будут доставлять преимущества прототипного для строк или комплексных чисел.

Вы намекаете на то, что это должно быть реализовано через классы? Как в STL? Это может быть реализовано в стандартной библиотеке, которая идёт вместе с языком, либо написано на чистом C или ассемблере. И тем более, работа со строками в C++ это не предмет гордости, поскольку строки zero-terminated, и std::string только отчасти решает эту проблему.

И по скорости работы будет то же самое, что С++ отресолвит во время компиляции.

В Go строгая статическая типизация, в отличии от нестрогой C/C++, там во время компиляции отресолвит ещё больше.

Да без проблем, я и сам программист мейнстрим языков.

И в скольких мейнстрим языках с уважаемой историей (лет 10, допустим) прототипное ООП? А в скольких — классовое? И где программисты на его жалуются?

Вы намекаете на то, что это должно быть реализовано через классы?

Кагбэ x=Complex(1, −1); удобнее, чем {x = y.Clone(); x.Set(1, −1);}

то может быть реализовано в стандартной библиотеке, которая идёт вместе с языком, либо написано на чистом C или ассемблере.

Вот и я о том же — либо стандартная библиотека дает классы для работы с нужными примитивами — тогда не жалуйтесь на классы; либо надо непонятно что клонировать, чтобы создать объект комплексного числа или строки, а затем — этот объект инициализировать. Получаете 2 действия вместо одного в коде.

В Go строгая статическая типизация

как это соотносится с

Нет никакого смысла вообще в принципе городить множественное наследование, когда можно применять утиную типизацию интерфейсов, и таким образом избежать создания множества классов во всех комбинациях.
И в скольких мейнстрим языках с уважаемой историей (лет 10, допустим) прототипное ООП?

Во всем известном мейнстрим-языке JS прототипное ООП, сейчас ещё с обёрткой классового. Качество самого по себе раннего js конечно оставим за скобками этого вопроса. Я считаю, что Lua намного лучше концептуально проработан, где более удобное прототипное ООП, и лучший релиз коротин.

Кагбэ x=Complex(1, —1); удобнее, чем {x = y.Clone(); x.Set(1, —1);}

Ерунда, строки как и комплексные числа — это примитивные типы, ничего нигде клонировать не нужно. Хотя комплексные числа практически используются редко. Но при необходимости, что в Go, что Lua можно забиндить функционал хоть по кватернионам, хоть по матрицам, хоть по тензорам на уровне примитивных типов.

как это соотносится с

также как dynamic_cast в C++.

Ерунда, строки как и комплексные числа — это примитивные типы, ничего нигде клонировать не нужно.

Подожди. А что такое «примитивный тип»? Чем он отличается от класса в С++, если его можно не клонировать, а создать через конструктор?

также как dynamic_cast в C++.

А вот его стараются не использовать, так как тормозной, и вообще — грязный хак. А ты предлагаешь Duck Typing везде вместо наследования. Оно и по скорости ударит, и проверку типизации компилером на нет сведет.

Подожди. А что такое «примитивный тип»? Чем он отличается от класса в С++, если его можно не клонировать, а создать через конструктор?

Вот, это правильный вопрос. Преимущества разных подходов в ООП сравнивать лучше не на примере примитивных типов, которые реализуются другими методами. Конечно, даже в js строки можно рассмотреть как класс, реализованный на уровне языка, но это не значит что там концептуально классовое ООП для реализации пользовательской логики.

А ты предлагаешь Duck Typing везде вместо наследования

Да, это более удобный вариант. Конечно, ничто абсолютно не мешает точно также как в C++ объявлять статичные указатели на какой-то тип или интерфейс, которые будут чекаться во время компиляции. А можно проверять на реализацию в объекте какого-то интерфейса, который в C++ нужно объявлять исключительно в классе. А если он не объявлен, а класс всё равно реализует функции интерфейса, то в период выполнения это никак не проверить, и не привести к типу.

А что такое «примитивный тип»? Чем он отличается от класса в С++, если его можно не клонировать, а создать через конструктор?

Примитивный тип, обычно — это тип:
* содержащий единственное значение (а не набор, как массив, объект/структура)
* реализующий семантику копирования при присваивании
* имеющий литерал (но некоторые языки поддерживают литералы пользовательских типов)

Ничем от класса в С++ не отличается.

функциональное — очень даже да и оно не имеет отношения к ООП.

Камон, в скале очень даже имеет.

Это кто конкретно ? три с половиною хаскелиста ?

Ну если так судить, то уже и С# имеет отношение к функциональному программированию. Дело в том, что если данный рекрутер начнет задумываться обо всех деталях и исключениях, то она вообще никогда не освоит базовые понятия :)

1. Нет, на ООП свет клином не сошелся.
Да, спрашивать глупо (не на техническом интервью).

2. Очень приблизительно — да

3. Вы путаете «языки» и «экосистемы». В рамках одной экосистемы (JVM, .NET, JS, native, etc) можно использовать доступные для этой экосистемы языки, библиотеки, фреймворки.

4. Зависит от целей теста.

пошла гуглить про экосистемы, большое спасибо

Вопрос терминологии.
Если мы примем что

Фреймворк — набор библиотек для выполнения какой-то конкретной бизнес-задачи широкого смысла целиком.

то экосистемой будут набор фрйемворков, построенных вокруг какой-то общей технологии и предназначенных для решения разных бизнес задач. В конкретном проекте будет использоваться какая-то часть экосистемы.

1. Нет, на ООП свет клином не сошелся.

Помойму кроме го с растом из современных популярных языков ооп везде во весь рост. Даже жс имеет объекты, и наследование, пусть и со своей особенностью.

Дедушка С еще живой и очень даже здоровый)

COBOL ще в 80х похоронили, а він досі живий.

Підписатись на коментарі