Нетехнические вопросы на интервью

[John Smith]

3. Вы как программист, не можете смотреть на такую ситуацию, когда клиент рвет на себе волосы и бьется в бессилии, что его проблему задвигают на задний план. Поэтому принимаете решение пофиксить багу непланово - в течении получаса после работы. Мол, сверх плана.
4. На следующий день сообщаете начальтсву что проблема решена. Можно выкатывать к клиенту без затрат доп времени.
5. Менеджеры и клиент ликуют!

А-ха-ха-ха!

[IvanGrozniy]

аналог С-шных pointers.

Надо четче формулировать, для чего надо. Обычно указатели в Питоне "хотят" по двум причинам:
1. Хотят не сколько указатели, сколько просто отслеживать object identity. Для этих случаев подойдет id(). Например, если вдруг какому извращенцу связный список пренепременно нужен, то id() + dictionary, наверное.
2. Действительно нужны честные указатели - скорее всего для интеропа. import ctypes и вперед.

Библиотека TensorFlow построена на этих декораторах.
Например, сначала описываешь свою математичекую/питонную функцию. Потом ее передаешь как параметр в функцию TensorFlow для поиска локального минимума этой функции при тренировки модели для нейронной сети машинного обучения.
Только признаюсь, что я не знал, что эта фишка передачи указателя на функции в Питоне декоратором называется. Пришлось погуглить определение. Не обессудьте.

[M. Ridcully]

Библиотека TensorFlow построена на этих декораторах.
Например, сначала описываешь свою математичекую/питонную функцию. Потом ее передаешь как параметр в функцию TensorFlow для поиска локального минимума этой функции при тренировки модели для нейронной сети машинного обучения.
Только признаюсь, что я не знал, что эта фишка передачи указателя на функции в Питоне декоратором называется. Пришлось погуглить определение. Не обессудьте.

Декоратор - это функция, которая превращает одну функцию в другую, а не то, что вы написали.
Что TF "построена на декораторах" я сильно сомневаюсь.
Подозреваю, что Питон там используется только для того, чтобы построить граф вычислений который потом исполняется на бэкенде (C++, разумеется).
Даже если издали выглядит, будто вы чего-то там на Питоне навычисляли. Это иллюзия.

[IvanGrozniy]

Библиотека TensorFlow построена на этих декораторах.
Например, сначала описываешь свою математичекую/питонную функцию. Потом ее передаешь как параметр в функцию TensorFlow для поиска локального минимума этой функции при тренировки модели для нейронной сети машинного обучения.
Только признаюсь, что я не знал, что эта фишка передачи указателя на функции в Питоне декоратором называется. Пришлось погуглить определение. Не обессудьте.

Декоратор - это функция, которая превращает одну функцию в другую, а не то, что вы написали.
Что TF "построена на декораторах" я сильно сомневаюсь.
Подозреваю, что Питон там используется только для того, чтобы построить граф вычислений который потом исполняется на бэкенде (C++, разумеется).
Даже если издали выглядит, будто вы чего-то там на Питоне навычисляли. Это иллюзия.

А я подозреваю наоборот

[M. Ridcully]

Библиотека TensorFlow построена на этих декораторах.
Например, сначала описываешь свою математичекую/питонную функцию. Потом ее передаешь как параметр в функцию TensorFlow для поиска локального минимума этой функции при тренировки модели для нейронной сети машинного обучения.
Только признаюсь, что я не знал, что эта фишка передачи указателя на функции в Питоне декоратором называется. Пришлось погуглить определение. Не обессудьте.

Декоратор - это функция, которая превращает одну функцию в другую, а не то, что вы написали.
Что TF "построена на декораторах" я сильно сомневаюсь.
Подозреваю, что Питон там используется только для того, чтобы построить граф вычислений который потом исполняется на бэкенде (C++, разумеется).
Даже если издали выглядит, будто вы чего-то там на Питоне навычисляли. Это иллюзия.

А я подозреваю наоборот

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

[IvanGrozniy]

Библиотека TensorFlow построена на этих декораторах.
Например, сначала описываешь свою математичекую/питонную функцию. Потом ее передаешь как параметр в функцию TensorFlow для поиска локального минимума этой функции при тренировки модели для нейронной сети машинного обучения.
Только признаюсь, что я не знал, что эта фишка передачи указателя на функции в Питоне декоратором называется. Пришлось погуглить определение. Не обессудьте.

Декоратор - это функция, которая превращает одну функцию в другую, а не то, что вы написали.
Что TF "построена на декораторах" я сильно сомневаюсь.
Подозреваю, что Питон там используется только для того, чтобы построить граф вычислений который потом исполняется на бэкенде (C++, разумеется).
Даже если издали выглядит, будто вы чего-то там на Питоне навычисляли. Это иллюзия.

А я подозреваю наоборот

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

Ну вот пример использования декоратора в тенсор флоу для convolution network на языке Питон. Декоратор под называнием compute_cost

Code: Select all

def compute_cost(Z3, Y):
	cost = tf.reduce_mean(tf.nn.softmax_cross_entropy_with_logits())
return cost
...
cost = compute_cost(Z3, Y) 
...
with tf.Session() as sess:
...
	_ , temp_cost = sess.run([optimizer, cost], feed_dict={X: minibatch_X, Y: minibatch_Y}) 

Убедил, что декоратор?

[M. Ridcully]

Ну вот пример использования декоратора в тенсор флоу для convolution network на языке Питон. Декоратор под называнием compute_cost

Code: Select all

def compute_cost(Z3, Y):
	cost = tf.reduce_mean(tf.nn.softmax_cross_entropy_with_logits())
return cost
...
cost = compute_cost(Z3, Y) 
...
with tf.Session() as sess:
...
	_ , temp_cost = sess.run([optimizer, cost], feed_dict={X: minibatch_X, Y: minibatch_Y}) 

Убедил, что декоратор?

Да где же тут декоратор-то?
Декоратор - в Питоне - это, еще раз - функция, которая модифицирует другую функцию, и исползуется со специальным синтаксисом:

Code: Select all

def my_decorator(f):
    return modify_func(f)
    
@my_decorator # turn vanilla_func into smth else
def vanilla_func()
    pass

А вы там, судя по всему, просто функцию как параметр другой функции передаете? Но я не уверен, ибо с TF не знаком, и не знаю, каких монстров этот ваш код на бэкенде рождает. Но уверен, что все написанное на Питоне там - сплошная иллюзия, чтобы болезных машинообученцев не травмировать.

[Херовимчик]

аналог С-шных pointers.

Надо четче формулировать, для чего надо. Обычно указатели в Питоне "хотят" по двум причинам:
1. Хотят не сколько указатели, сколько просто отслеживать object identity. Для этих случаев подойдет id(). Например, если вдруг какому извращенцу связный список пренепременно нужен, то id() + dictionary, наверное.
2. Действительно нужны честные указатели - скорее всего для интеропа. import ctypes и вперед.

Я ни разу не питонщик, читаю и пишу со словарем. Мне было интересно в контексте какой-то задачи, где в С все легко решается при помощи указателей, а в питоне подтягивается куча функций. Но ответ того чувака очень понравился

[Херовимчик]

В тему о нетехнических вопросах:
сейчас Линкдином принесло обсуждения вопрос "Расскажите о случаях, когда вы разошлись во мнениях с менеджером или коллегами"

Предлагаемый шаблон:
1. Клиент обнаружил баг
2. Создается собрание с начальниками и с коллегами на подведение итогов релиза и на осмотр текующих багов планируемых для следующего релиза. Начальство выделяет часы на планируюмую заплату для этого клиента. Допустим, 4 часа исправления в исходниках. Также много других задач которые давно запланировали ранее. Соотвественно ремонт баги откладывается до следующего релиза, в конец очереди. Мол, есть работа и поважнее по другим багам. На вас, сетующего на недовольство клиента, внимания не обращают.
3. Вы как программист, не можете смотреть на такую ситуацию, когда клиент рвет на себе волосы и бьется в бессилии, что его проблему задвигают на задний план. Поэтому принимаете решение пофиксить багу непланово - в течении получаса после работы. Мол, сверх плана.
4. На следующий день сообщаете начальтсву что проблема решена. Можно выкатывать к клиенту без затрат доп времени.
5. Менеджеры и клиент ликуют!
Вот таким образом вы разошлись во мнениях с начальством и с коллегами, но все завершилось хорошо!
Это я пример из своего недавнего опыта описал (только я багу фиксил во время митинга из второго пункта, пока все руками размахивали). Сразу 3 амазоновских приципа одним ударом убивает: несогласие с начальством, мания к сохранению клиентов и экономия средств на производстенном процессе.
Не благодарите

на самом деле это вопрос с подвохом. Услышать от вас хотят что вам хватило "наглости" вслух высказать свое мнение, и хватило дипломатии выслушать другие версии и принять решение мирно и цивильно. Смогли ли вы убедить (мирно и цивильно) что ваше мнение более правильное? Вообщем опять, soft skills в чистом виде

[ystar]

В тему о нетехнических вопросах:
сейчас Линкдином принесло обсуждения вопрос "Расскажите о случаях, когда вы разошлись во мнениях с менеджером или коллегами"

Предлагаемый шаблон:
1. Клиент обнаружил баг
2. Создается собрание с начальниками и с коллегами на подведение итогов релиза и на осмотр текующих багов планируемых для следующего релиза. Начальство выделяет часы на планируюмую заплату для этого клиента. Допустим, 4 часа исправления в исходниках. Также много других задач которые давно запланировали ранее. Соотвественно ремонт баги откладывается до следующего релиза, в конец очереди. Мол, есть работа и поважнее по другим багам. На вас, сетующего на недовольство клиента, внимания не обращают.
3. Вы как программист, не можете смотреть на такую ситуацию, когда клиент рвет на себе волосы и бьется в бессилии, что его проблему задвигают на задний план. Поэтому принимаете решение пофиксить багу непланово - в течении получаса после работы. Мол, сверх плана.
4. На следующий день сообщаете начальтсву что проблема решена. Можно выкатывать к клиенту без затрат доп времени.
5. Менеджеры и клиент ликуют!
Вот таким образом вы разошлись во мнениях с начальством и с коллегами, но все завершилось хорошо!
Это я пример из своего недавнего опыта описал (только я багу фиксил во время митинга из второго пункта, пока все руками размахивали). Сразу 3 амазоновских приципа одним ударом убивает: несогласие с начальством, мания к сохранению клиентов и экономия средств на производстенном процессе.
Не благодарите

Отлично. Благодарю!

[8K]

что декоратор?

... и что он Гекубе...

На правах офтопа (из последнего, для интересующихся начинающих):

[8K]

принимаете решение пофиксить багу непланово - в течении получаса после работы. Мол, сверх плана.

Отлично. Благодарю!

А потом что, нормальным людям не иметь жизни из-за этих стахановцев? Такой футбол нам не нужен.

[vdfs]

Ну почему. "Нормальные люди" имеют нормальную жизнь в других местах. Где меньше платят и/или меньше требования. Не факт, что оно стоит тех инвестиций, денег, или географии. В пересчете на затраченные часы и личную жизнь, ответ не всегда очевиден. Кому и кобыла невеста (с).

[Falcon]

В тему о нетехнических вопросах:
сейчас Линкдином принесло обсуждения вопрос "Расскажите о случаях, когда вы разошлись во мнениях с менеджером или коллегами"

Предлагаемый шаблон:
1. Клиент обнаружил баг
2. Создается собрание с начальниками и с коллегами на подведение итогов релиза и на осмотр текующих багов планируемых для следующего релиза. Начальство выделяет часы на планируюмую заплату для этого клиента. Допустим, 4 часа исправления в исходниках. Также много других задач которые давно запланировали ранее. Соотвественно ремонт баги откладывается до следующего релиза, в конец очереди. Мол, есть работа и поважнее по другим багам. На вас, сетующего на недовольство клиента, внимания не обращают.
3. Вы как программист, не можете смотреть на такую ситуацию, когда клиент рвет на себе волосы и бьется в бессилии, что его проблему задвигают на задний план. Поэтому принимаете решение пофиксить багу непланово - в течении получаса после работы. Мол, сверх плана.
4. На следующий день сообщаете начальтсву что проблема решена. Можно выкатывать к клиенту без затрат доп времени.
5. Менеджеры и клиент ликуют!
Вот таким образом вы разошлись во мнениях с начальством и с коллегами, но все завершилось хорошо!
Это я пример из своего недавнего опыта описал (только я багу фиксил во время митинга из второго пункта, пока все руками размахивали). Сразу 3 амазоновских приципа одним ударом убивает: несогласие с начальством, мания к сохранению клиентов и экономия средств на производстенном процессе.
Не благодарите

Отлично. Благодарю!

Зря. Это очень мелко. В evaluation будет написано, mild concern

[Big W]

что декоратор?

... и что он Гекубе...

На правах офтопа (из последнего, для интересующихся начинающих):
www.youtube.com/watch?v=T8CQwGIsrx4

Гм, видео аж почти на 3 с половиной часа... Для меня термин Декоратор в контексте программирования как бы сразу ассоциируется с Decorator pattern, в питоне что-то иное что ли...

[M. Ridcully]

что декоратор?

... и что он Гекубе...

На правах офтопа (из последнего, для интересующихся начинающих):
www.youtube.com/watch?v=T8CQwGIsrx4

Гм, видео аж почти на 3 с половиной часа... Для меня термин Декоратор в контексте программирования как бы сразу ассоциируется с Decorator pattern, в питоне что-то иное что ли...

https://docs.python.org/3/glossary.html#term-decorator

Но народу, тут, вижу нравится строить догадки и ассоциации с чем угодно, только бы в первоисточник - или хотя бы в Гугл - не заглянуть!

[Big W]

... в питоне что-то иное что ли...

Действительно другое

Please do not confuse the Decorator Pattern (or an implementation of this design pattern in Python...) with Python Decorators, a Python language feature. They are different things.
https://en.wikipedia.org/wiki/Decorator_pattern#Python

[kyk]

Но народу, тут, вижу нравится строить догадки и ассоциации с чем угодно, только бы в первоисточник - или хотя бы в Гугл - не заглянуть!

по-научному такой подход называется "Critical Thinking" Мало ли что первоисточник, Гугол или википедия говорит. Сегодня одно, а завтра - другое Нельзя всё на веру принимать - обманут. Своя голова надёжнее будет, особенно если большая

[M. Ridcully]

Но народу, тут, вижу нравится строить догадки и ассоциации с чем угодно, только бы в первоисточник - или хотя бы в Гугл - не заглянуть!

по-научному такой подход называется "Critical Thinking" Мало ли что первоисточник, Гугол или википедия говорит. Сегодня одно, а завтра - другое Нельзя всё на веру принимать - обманут. Своя голова надёжнее будет, особенно если большая

Ваши слова были бы справедливы, если бы мы рассуждали о каком-то естественнонаучном феномене. А не чем-то таком, что придумали сами люди и дали этому абсолютно однозначное формальное определение.

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

[ystar]

В тему о нетехнических вопросах:
сейчас Линкдином принесло обсуждения вопрос "Расскажите о случаях, когда вы разошлись во мнениях с менеджером или коллегами"

Предлагаемый шаблон:
1. Клиент обнаружил баг
2. Создается собрание с начальниками и с коллегами на подведение итогов релиза и на осмотр текующих багов планируемых для следующего релиза. Начальство выделяет часы на планируюмую заплату для этого клиента. Допустим, 4 часа исправления в исходниках. Также много других задач которые давно запланировали ранее. Соотвественно ремонт баги откладывается до следующего релиза, в конец очереди. Мол, есть работа и поважнее по другим багам. На вас, сетующего на недовольство клиента, внимания не обращают.
3. Вы как программист, не можете смотреть на такую ситуацию, когда клиент рвет на себе волосы и бьется в бессилии, что его проблему задвигают на задний план. Поэтому принимаете решение пофиксить багу непланово - в течении получаса после работы. Мол, сверх плана.
4. На следующий день сообщаете начальтсву что проблема решена. Можно выкатывать к клиенту без затрат доп времени.
5. Менеджеры и клиент ликуют!
Вот таким образом вы разошлись во мнениях с начальством и с коллегами, но все завершилось хорошо!
Это я пример из своего недавнего опыта описал (только я багу фиксил во время митинга из второго пункта, пока все руками размахивали). Сразу 3 амазоновских приципа одним ударом убивает: несогласие с начальством, мания к сохранению клиентов и экономия средств на производстенном процессе.
Не благодарите

Отлично. Благодарю!

Зря. Это очень мелко. В evaluation будет написано, mild concern

А есть пример как правильно?

[Херовимчик]

В тему о нетехнических вопросах:
сейчас Линкдином принесло обсуждения вопрос "Расскажите о случаях, когда вы разошлись во мнениях с менеджером или коллегами"

Предлагаемый шаблон:
1. Клиент обнаружил баг
2. Создается собрание с начальниками и с коллегами на подведение итогов релиза и на осмотр текующих багов планируемых для следующего релиза. Начальство выделяет часы на планируюмую заплату для этого клиента. Допустим, 4 часа исправления в исходниках. Также много других задач которые давно запланировали ранее. Соотвественно ремонт баги откладывается до следующего релиза, в конец очереди. Мол, есть работа и поважнее по другим багам. На вас, сетующего на недовольство клиента, внимания не обращают.
3. Вы как программист, не можете смотреть на такую ситуацию, когда клиент рвет на себе волосы и бьется в бессилии, что его проблему задвигают на задний план. Поэтому принимаете решение пофиксить багу непланово - в течении получаса после работы. Мол, сверх плана.
4. На следующий день сообщаете начальтсву что проблема решена. Можно выкатывать к клиенту без затрат доп времени.
5. Менеджеры и клиент ликуют!
Вот таким образом вы разошлись во мнениях с начальством и с коллегами, но все завершилось хорошо!
Это я пример из своего недавнего опыта описал (только я багу фиксил во время митинга из второго пункта, пока все руками размахивали). Сразу 3 амазоновских приципа одним ударом убивает: несогласие с начальством, мания к сохранению клиентов и экономия средств на производстенном процессе.
Не благодарите

Отлично. Благодарю!

Зря. Это очень мелко. В evaluation будет написано, mild concern

А есть пример как правильно?

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

[nyekimov]

Предлагаемый шаблон:
1. Клиент обнаружил баг
2. Создается собрание с начальниками и с коллегами на подведение итогов релиза и на осмотр текующих багов планируемых для следующего релиза. Начальство выделяет часы на планируюмую заплату для этого клиента. Допустим, 4 часа исправления в исходниках. Также много других задач которые давно запланировали ранее. Соотвественно ремонт баги откладывается до следующего релиза, в конец очереди. Мол, есть работа и поважнее по другим багам. На вас, сетующего на недовольство клиента, внимания не обращают.
3. Вы как программист, не можете смотреть на такую ситуацию, когда клиент рвет на себе волосы и бьется в бессилии, что его проблему задвигают на задний план. Поэтому принимаете решение пофиксить багу непланово - в течении получаса после работы. Мол, сверх плана.
4. На следующий день сообщаете начальтсву что проблема решена. Можно выкатывать к клиенту без затрат доп времени.
5. Менеджеры и клиент ликуют!
Вот таким образом вы разошлись во мнениях с начальством и с коллегами, но все завершилось хорошо!
Это я пример из своего недавнего опыта описал (только я багу фиксил во время митинга из второго пункта, пока все руками размахивали). Сразу 3 амазоновских приципа одним ударом убивает: несогласие с начальством, мания к сохранению клиентов и экономия средств на производстенном процессе.
Не благодарите

Отлично. Благодарю!

Зря. Это очень мелко. В evaluation будет написано, mild concern

А есть пример как правильно?

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

Ну а разве не сказано, что начальство согласно и оценило решение в 4 часа. Только по приоритету отодвинуло это решение, так как текущие или другие задачи важней.

[alex_127]

...
Зря. Это очень мелко. В evaluation будет написано, mild concern

А есть пример как правильно?

вник в детали 50млн бизнеса
мотался как бобик по супер клиентам и они все любили
увеличил команду в 5 раз
довел до 500млн.

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

[ystar]

...
Зря. Это очень мелко. В evaluation будет написано, mild concern

А есть пример как правильно?

вник в детали 50млн бизнеса
мотался как бобик по супер клиентам и они все любили
увеличил команду в 5 раз
довел до 500млн.

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

мотаться по клиентам, вроде это не работа девелопера.

[Херовимчик]

Отлично. Благодарю!

Зря. Это очень мелко. В evaluation будет написано, mild concern

А есть пример как правильно?

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

Ну а разве не сказано, что начальство согласно и оценило решение в 4 часа. Только по приоритету отодвинуло это решение, так как текущие или другие задачи важней.

Ну вот вам уже 2 разногласия:
1. Трудозатраты
2. Приоритеты

Удачное разрешение конфликта, это не когда ты промолчал и сделал по-свойму, а когда открыто обсудил и пришел к общему согласию