Как к Вам записаться на менторскую программу? В телеге вроде тема была, но проект был еще в стадии разработки (насколько я понял). Дайте контакты кому писать?
Оба несут вещи, которые не понимают - "три машинных слова". здесь у меня машинное слово 4 байта, здесь уже 8. "Есть виртуальная память, есть резидентная". Пустая структура у них стала весить 8 байт, а int стал 4 байтным (в практической задаче с горутинами и каналами)🤦♂
В вычислительной и иной программируемой технике машинным словом называется единица данных, которая выбрана естественной для данной архитектуры процессора. Каким боком вы приравняли машинные слова к струтуре слайс - непонятно.
Как бальзам на душу! Смотрю и за голову хватаюсь, оба бросаются такими терминами и не понимают что это означает. Причем у кандидата машинные слова внезапно стали иметь разный размер и интервьюер это проглотил спокойно.
@@flamehowk это нормально, что он не знает много. Меня интервьюер немного расстроил, он не поправляет его, просто соглашается. Значит сам не сильно опытней.
Не надевайте на созвоны рубашку телесного цвета, есть большая вероятность что вас запомнят именно по ней а не то как хорошо вы знаете и как много умеете.
В какой момент времени Go программисты стали байтоориентировнными? Только и разговоры про байты, офсеты, экономию места под микроскопом. Я ни разу не видел на собесах Ruby, как спрашивают про устройство интерпретатора или про формат метаданных в гемах. Допускаю, что живу в другом измерении.
В наследство от Гугл осталось, плюс в Го перешло много байтоебов из С/С++. Но сравнение не корректное. Руби сопоставим с питоном, а го берут уже когда питон начинает душить и его не хватает, по этому имеем требования к пониманию работы на низких уровнях.
Программирую на Go с 2015 года и вот что скажу про собесы на Go - на них вы очень редко услышите вопросы по Алгоритмы, структуры данных, CI, CS, про паттерны проектирования и конкретные технологии вроде message brokers, olap, oltp и т.д. Особенно если собеседование на сениора. Вас буду спрашивать только про рантайм, обязательно не просто как работает GC в целом, а про его трехцветный алгоритм, про то, как же все таки устроена мапа в go - на списках или целиком на массиве - это ооочень важно! Обязательно спросят про устройство интерфейса, про кооперативный или нет планировщик и т.д. Скажу, что с одной стороны, какой - то уровень IQ это определяет - а код у разработчика с более высоким уровнем IQ будет среднеарифметически лучше. С другой - это реально приводит к ситуациям, когда какой - нибудь ушлый джун за одну ночь "все перечитал" и устроился на работу синиором - реальные были кейсы, когда устраивались "сениоры" которые не знают, что такое grpc, не работали с kafka, не пользовались cubectl и не знают, что такое Makefile. К примеру, по JS такого ни разу не помню - объективно, почти всегда можно выявить реальный уровень кандидата, объективно, экосистема JS на прикладном уровне намного сложнее, чем GO - и на ровне конструкций языка и на уровне фремворков. А Go - язык для микросервисов, порог вхождения для него низкий, что касается горутин и асинхронной работы - в 95% случаев разработчикам это не нужно от слова СОВСЕМ! В работе пользовался только разве что Errgroup раскидать задачи, timeAfter пару раз для таймаута ну sync Pool разок для работы с файлами, mutex с мапой - и все! 99% работы вообще не затрагивало фичи Golang. В то время как в Js если ты не знаешь, как работает асинхронный код и паттерны работы с промисами - ты как сеньор вообще далеко не уйдешь. Тебе надо знать пару фреймворков, vanilla, DOM, promises, closure, препроцессоры вроде Typescript и т.д. - а в Go, объективно, люди от нехрен делать в рантайм лезут
задача на код решена неправильно. Канал не закрыт эт раз, второе переменная i из цикла захвачена замыканием - в результате скорее всего напчает 99 везде
Напечатает везде 100, хоть это немного и неожиданно, попробую объяснить: запустит горутины от 0 до 99, добавит к счетчику 1 (i станет =100) убедится что 100
Там интересней - результат исполнения будет отличаться каждый раз, но 100-к будет больше всего. Вот в JS были б одни сотки, а здесь все таки более честная параллельность
Ну он тут скорее не про само ее использование в го, а про непосредственно механизм доступа к i-тому элементу в реализации массивов как структуры данных. так что грубой ошибки не совершил)
Уже второй раз слышу вопрос "Может ли быть ситуация, когда итерироваться по слайсу быстрее чем по мате?" Вы серьезно? в моей картине мира по слайсу практические всегда быстрее итерироваться чем по мапе, Можно же сказать что итерация по слайсу это практически итерация по массиву, непрерывному участку памяти из кеша или кучи, плюс у проца есть кеш куда могут попадать участки из этого массива и не всегда придется ходит в оперативу. А меп это намного более сложная структуа, окей изначально у нас был непрерывный участок с бакетами, но он намного сложнее устроен, есть оверхед на просмотр, плюс если много коллизий, место бакета в бакете закончилось, он начинает ссылаться на другой бакет по ссылке.
Исходя из последующего ответа собеседуемого видно, что собеседующий явно оговорился. Он очевидно хотел сказать "когда поиск по слайсу быстрее, чем по мапе". И такая ситуация может быть т.к. поиск для мапы O(n), для слайса Ω(lg n)(не рассматривая граничный случай Ω(1). И O(n) для мапы собеседуемый назвал(100% коллизии) и Ω(lg n) для слайса (бинарный поиск или дихотомия для предварительного отсортированного слайса). На самом деле был бы хороший вопрос если бы был задан корректно, т.к. как показывает практика, процентов 70 программистов не знают ни про три уровня асимптотической сложности алгоритмов, ни про то, что поиск по слайсу можно проводить быстрее, чем за линейное время, ни про то, что поиск по мапе может быть не константный, а линейный
не очень понял про сборщик мусора в контексте джавы. На сколько я понял, в го он не не то чтобы просто нормальный(stop the world, куча потребляемой памяти и прочее), так чем же он лучше джавовского? вопрос не провокационный, просто хочется понять))
Небольшой коммент по поводу того, можно ли передавать в контексте логгер. Александр говорит, что это не очень хорошая практика. Сегодня послушал выступление Нежибицкого Ильяса из Озона, с его слов, они как раз логгер передают в контексте. Противоречие какое-то получается :) Это видимо тот случай, когда в теории все хорошо и красиво, а на практике ...
Понятно почему невозможно устроиться на работу... Я программирую с 1992-го, а собеседуют меня ребята, которые занимаются разработкой по 5 лет. Ну да ладно, через пару лет, когда я выпущу на рынок свой продукт и он начнет зарабатывать, возможно я еще спасибо скажу таким вот "собеседователям"...
К менторской программе я никакого отношения не имею. Но как практикующий гошник, работавший в известных (и не очень) компаниях, отвечу, нет, не стоит. Базовые аспекты изучаются за несколько недель, максимум месяц. В этот же месяц вы прочитаете Effective Go и другие рекомендации к написанию кода на go. А более глубоко вы начнете разбираться через год full-time работы на go. Вот тогда, возможно, ментор понадобится. Поскольку всякие tricky-questions из этого собеса черпаются в не официальной доке к языку, а в доп. источниках, которые не так просто найти.
Задачу можно было и намного элегантнее через atomic решить: func main() { n := 100 var cnt atomic.Int32 ch := make(chan struct{}) for i := 0; i < n; i++ { go func(i int) { fmt.Println(i) cnt.Add(1) if int(cnt.Load()) == n { ch
"В слайсе поиск за 1, и в мапе тоже за 1", "В мапе есть хэши, а слайс - он тупой...". Ну, то есть, про древовидные структуры ни один ничего не знает и как ведется поиск листьев по веткам - никто понятия не имеет... скорей всего даже не понимают - зачем вообще там хэши нужны.
Как к Вам записаться на менторскую программу? В телеге вроде тема была, но проект был еще в стадии разработки (насколько я понял). Дайте контакты кому писать?
Можете запустить нашего бота: t.me/mock_interviews_bot?start=youtube_18_05_2022
И после команды /start в меню выбрать "Менторская программа".
@@Skills_mentor Спасибо!
Огонь, обожаю такие видосы!
Оба несут вещи, которые не понимают - "три машинных слова". здесь у меня машинное слово 4 байта, здесь уже 8. "Есть виртуальная память, есть резидентная". Пустая структура у них стала весить 8 байт, а int стал 4 байтным (в практической задаче с горутинами и каналами)🤦♂
http - протокол седьмого, прикладного уровня!
В вычислительной и иной программируемой технике машинным словом называется единица данных, которая выбрана естественной для данной архитектуры процессора.
Каким боком вы приравняли машинные слова к струтуре слайс - непонятно.
Как бальзам на душу! Смотрю и за голову хватаюсь, оба бросаются такими терминами и не понимают что это означает. Причем у кандидата машинные слова внезапно стали иметь разный размер и интервьюер это проглотил спокойно.
@@hoffmanmilo Парень всего 5 лет как программирует, чему Вы удивляетесь...
@@flamehowk это нормально, что он не знает много. Меня интервьюер немного расстроил, он не поправляет его, просто соглашается. Значит сам не сильно опытней.
Не надевайте на созвоны рубашку телесного цвета, есть большая вероятность что вас запомнят именно по ней а не то как хорошо вы знаете и как много умеете.
В какой момент времени Go программисты стали байтоориентировнными? Только и разговоры про байты, офсеты, экономию места под микроскопом. Я ни разу не видел на собесах Ruby, как спрашивают про устройство интерпретатора или про формат метаданных в гемах. Допускаю, что живу в другом измерении.
В наследство от Гугл осталось, плюс в Го перешло много байтоебов из С/С++. Но сравнение не корректное. Руби сопоставим с питоном, а го берут уже когда питон начинает душить и его не хватает, по этому имеем требования к пониманию работы на низких уровнях.
Программирую на Go с 2015 года и вот что скажу про собесы на Go - на них вы очень редко услышите вопросы по Алгоритмы, структуры данных, CI, CS, про паттерны проектирования и конкретные технологии вроде message brokers, olap, oltp и т.д. Особенно если собеседование на сениора. Вас буду спрашивать только про рантайм, обязательно не просто как работает GC в целом, а про его трехцветный алгоритм, про то, как же все таки устроена мапа в go - на списках или целиком на массиве - это ооочень важно! Обязательно спросят про устройство интерфейса, про кооперативный или нет планировщик и т.д.
Скажу, что с одной стороны, какой - то уровень IQ это определяет - а код у разработчика с более высоким уровнем IQ будет среднеарифметически лучше. С другой - это реально приводит к ситуациям, когда какой - нибудь ушлый джун за одну ночь "все перечитал" и устроился на работу синиором - реальные были кейсы, когда устраивались "сениоры" которые не знают, что такое grpc, не работали с kafka, не пользовались cubectl и не знают, что такое Makefile.
К примеру, по JS такого ни разу не помню - объективно, почти всегда можно выявить реальный уровень кандидата, объективно, экосистема JS на прикладном уровне намного сложнее, чем GO - и на ровне конструкций языка и на уровне фремворков.
А Go - язык для микросервисов, порог вхождения для него низкий, что касается горутин и асинхронной работы - в 95% случаев разработчикам это не нужно от слова СОВСЕМ! В работе пользовался только разве что Errgroup раскидать задачи, timeAfter пару раз для таймаута ну sync Pool разок для работы с файлами, mutex с мапой - и все! 99% работы вообще не затрагивало фичи Golang.
В то время как в Js если ты не знаешь, как работает асинхронный код и паттерны работы с промисами - ты как сеньор вообще далеко не уйдешь. Тебе надо знать пару фреймворков, vanilla, DOM, promises, closure, препроцессоры вроде Typescript и т.д. - а в Go, объективно, люди от нехрен делать в рантайм лезут
Михаил - лучший ментор в технопарке !
задача на код решена неправильно. Канал не закрыт эт раз, второе переменная i из цикла захвачена замыканием - в результате скорее всего напчает 99 везде
Напечатает везде 100, хоть это немного и неожиданно, попробую объяснить: запустит горутины от 0 до 99, добавит к счетчику 1 (i станет =100) убедится что 100
Хах, точно!
Там интересней - результат исполнения будет отличаться каждый раз, но 100-к будет больше всего. Вот в JS были б одни сотки, а здесь все таки более честная параллельность
Александр лучший ментор! Профессионально проведенное интервью.
крепкий чел
Миша топ - senior уровень, фундаментальные вещи знает
Про реализацию мап, очень слабый и непонятный ответ
про мапы да, ответы неправильные
25:00
в го нет адресной арифметики, это грубая ошибка
Есть, но её лучше не использовать. Через uintptr
Ну он тут скорее не про само ее использование в го, а про непосредственно механизм доступа к i-тому элементу в реализации массивов как структуры данных. так что грубой ошибки не совершил)
Автор комментария слышал звон...
Что за чепуху оба прогнали про контейнеризацию и виртуализацию?
1.25.40 - rofl - HTTP сетевой протокол.
Сначала причем интервьюируемый всё правильно сказала а потом вот это =(
Отличная аналогия livelock
Уже второй раз слышу вопрос "Может ли быть ситуация, когда итерироваться по слайсу быстрее чем по мате?" Вы серьезно? в моей картине мира по слайсу практические всегда быстрее итерироваться чем по мапе, Можно же сказать что итерация по слайсу это практически итерация по массиву, непрерывному участку памяти из кеша или кучи, плюс у проца есть кеш куда могут попадать участки из этого массива и не всегда придется ходит в оперативу. А меп это намного более сложная структуа, окей изначально у нас был непрерывный участок с бакетами, но он намного сложнее устроен, есть оверхед на просмотр, плюс если много коллизий, место бакета в бакете закончилось, он начинает ссылаться на другой бакет по ссылке.
Исходя из последующего ответа собеседуемого видно, что собеседующий явно оговорился. Он очевидно хотел сказать "когда поиск по слайсу быстрее, чем по мапе". И такая ситуация может быть т.к. поиск для мапы O(n), для слайса Ω(lg n)(не рассматривая граничный случай Ω(1). И O(n) для мапы собеседуемый назвал(100% коллизии) и Ω(lg n) для слайса (бинарный поиск или дихотомия для предварительного отсортированного слайса). На самом деле был бы хороший вопрос если бы был задан корректно, т.к. как показывает практика, процентов 70 программистов не знают ни про три уровня асимптотической сложности алгоритмов, ни про то, что поиск по слайсу можно проводить быстрее, чем за линейное время, ни про то, что поиск по мапе может быть не константный, а линейный
вот это я понимаю уровень
не очень понял про сборщик мусора в контексте джавы. На сколько я понял, в го он не не то чтобы просто нормальный(stop the world, куча потребляемой памяти и прочее), так чем же он лучше джавовского? вопрос не провокационный, просто хочется понять))
хотел написать в бота, получил usernamenotfound
Просто этого бота написали "менторы")
Небольшой коммент по поводу того, можно ли передавать в контексте логгер. Александр говорит, что это не очень хорошая практика. Сегодня послушал выступление Нежибицкого Ильяса из Озона, с его слов, они как раз логгер передают в контексте. Противоречие какое-то получается :) Это видимо тот случай, когда в теории все хорошо и красиво, а на практике ...
это называется что в каждой команде, даже внутри одной компании, может быть все по-разному
В каждой команде надо учить их религиозные убеждения. И там лидер команды будет убеждать, что именно их подход самый правильный.
Учить и учить короче ) ну оооооки
Понятно почему невозможно устроиться на работу... Я программирую с 1992-го, а собеседуют меня ребята, которые занимаются разработкой по 5 лет.
Ну да ладно, через пару лет, когда я выпущу на рынок свой продукт и он начнет зарабатывать, возможно я еще спасибо скажу таким вот "собеседователям"...
А что с собесом не так?
@@misteranderson6058 В сообщении выше все очевиднейшим образом сказано.
Простите за глупый вопрос, есть смысл брать занятие с ментором, если только пока разбираюсь в базовых аспектах языка.
К менторской программе я никакого отношения не имею. Но как практикующий гошник, работавший в известных (и не очень) компаниях, отвечу, нет, не стоит.
Базовые аспекты изучаются за несколько недель, максимум месяц. В этот же месяц вы прочитаете Effective Go и другие рекомендации к написанию кода на go. А более глубоко вы начнете разбираться через год full-time работы на go. Вот тогда, возможно, ментор понадобится. Поскольку всякие tricky-questions из этого собеса черпаются в не официальной доке к языку, а в доп. источниках, которые не так просто найти.
@@wskeal86 спасибо большое
Ого, я полумидл оказывается
опана ) привет
дЕфер, хёрт бит, ну ребята, ну блин..
Задачу можно было и намного элегантнее через atomic решить:
func main() {
n := 100
var cnt atomic.Int32
ch := make(chan struct{})
for i := 0; i < n; i++ {
go func(i int) {
fmt.Println(i)
cnt.Add(1)
if int(cnt.Load()) == n {
ch
"В слайсе поиск за 1, и в мапе тоже за 1", "В мапе есть хэши, а слайс - он тупой...". Ну, то есть, про древовидные структуры ни один ничего не знает и как ведется поиск листьев по веткам - никто понятия не имеет... скорей всего даже не понимают - зачем вообще там хэши нужны.