Comments 35
Опять эти люки… Как и написано в заголовке, эти вопросы действительно ужасны, и совершенно не подходят для собеседования )
Я возможно ошибаюсь, но мне почему-то кажется, что большинству работодателей, нужны кадры способные решать задачи, а не задачки… Искренне надеюсь, что эти вопросы не были взяты с реальных собеседований.
А задачки интересные, конечно )
Я возможно ошибаюсь, но мне почему-то кажется, что большинству работодателей, нужны кадры способные решать задачи, а не задачки… Искренне надеюсь, что эти вопросы не были взяты с реальных собеседований.
А задачки интересные, конечно )
+8
Да, абсолютно верно, именно поэтому мы отказались от этих вопросов.
На текущий момент мы сразу применяем физическое насилие к кандидатам. Обычно используем наручники и батарею.
На текущий момент мы сразу применяем физическое насилие к кандидатам. Обычно используем наручники и батарею.
+8
А если кандидат чемпион мира по рукопашному коду?
+6
На текущий момент мы сразу применяем физическое насилие к кандидатам. Обычно используем наручники и батарею.
Можно подробнее? Очень интересует практика в данном вопросе.
+3
Страшно представить, что у вас делают с бэкендерами… Недельные спринты в темных подвалах?
+1
Это такой новый тренд moikrug.ru/vacancies/1000032070?
+1
на первой своей работе коллеги мне рассказали историю (10 лет назад), что за год до моего прихода они наняли человека для кражи кода c прошивки с микроконтроллера и переделки его из ASM в код С++ (тайваньский алгоритм распознавания отпечатков пальцев). Код был скачан, но с конвертацией были проблемы. Чел потихоньку слился. Его нашли, прицепили к батарее пока он не сделал (1 месяц это заняло). Не только вы одни такое практикуете. Сейчас эти деятели пилят оборонные заказы.
+4
Object.freeze замораживает только свойства самого объекта. Так что, если объект содержит в себе вложенные объекты, их тоже необходимо заморозить.
Или чтобы этого не делать достать данные из замыкания. Думаю понятно что флаг dataLoaded
нужен только из-за отсутствия реактивности у item
.
import getItemFromApi from 'path/to/getItemFromApi';
let item;
export default {
data() {
return { dataLoaded: false }
}
async mounted() {
item = await getItemFromApi();
this.dataLoaded = true;
},
computed() {
return this.dataLoaded && item;
}
};
Статья крутая, спасибо!
+2
Так у вас тогда будет 1 item на все компоненты.
Если мне не изменяет память, (сменил vue на реакт примерно 8 месяцев назад) можно просто не объявлять его в data и таким же способом вернуть через computed. (только как this.item)
Если мне не изменяет память, (сменил vue на реакт примерно 8 месяцев назад) можно просто не объявлять его в data и таким же способом вернуть через computed. (только как this.item)
+1
Этот вопрос может показаться легким, но я гарантирую, на него не ответит ни один, даже самый прошареный разработчик. Можете задать его в начале собеседования, чтобы кандидат сразу почувствовал ваше превосходство.
Обычно, в начале собеседования наоборот легкие вопросы. Для человека собес — это стрессовая ситуация, а от простого первого вопроса он становится менее напряженным. Потом по нарастающей.
+2
Ох, почувствовал я себя днищем. Ни на один вопрос…
Как раз недавно читал тут статью про заниженную самооценку русскоязычных IT-шников.
И где вы только умудряетесь такие вопросы находить, изверги! =)
Спасибо, интересная и полезная статья.
Как раз недавно читал тут статью про заниженную самооценку русскоязычных IT-шников.
И где вы только умудряетесь такие вопросы находить, изверги! =)
Спасибо, интересная и полезная статья.
+1
К слову говоря — эта песочница тоже написана на Vue.js
+1
О, так это ваша песочница!
Спасибо большое за нее, песочница с лучшей консолью!
Спасибо большое за нее, песочница с лучшей консолью!
+1
Благодарю!
Не могли бы вы рассказать, чем консоль столь примечательна?
Возможно у вас есть пожелания?
+1
Консоль примечательна тем, что:
1. Она есть
2. Она удобно расположена под preview
Единственный аналог с консолью на сайте, который я нашел — это jsbin.com. Вначале я пытался использовать его, но что-то у них не завелась подсветка синтаксиса
Из пожеланий — мне показалось неудобным, что нельзя сразу увидеть html, css и js.
Проблема возникает тогда, когда ты скидываешь человеку незнакомый ему код. Чтобы понять смысл этого кода, надо прокликать по всем вкладкам и держать в голове предыдущие файлы. В статье это было было не критично, я использовал только один js файл. Но когда мне присылали чуть более сложные демки на вашем сайте, я чувствовал затруднения.
1. Она есть
2. Она удобно расположена под preview
Единственный аналог с консолью на сайте, который я нашел — это jsbin.com. Вначале я пытался использовать его, но что-то у них не завелась подсветка синтаксиса
Из пожеланий — мне показалось неудобным, что нельзя сразу увидеть html, css и js.
Проблема возникает тогда, когда ты скидываешь человеку незнакомый ему код. Чтобы понять смысл этого кода, надо прокликать по всем вкладкам и держать в голове предыдущие файлы. В статье это было было не критично, я использовал только один js файл. Но когда мне присылали чуть более сложные демки на вашем сайте, я чувствовал затруднения.
+1
Отличное изложение, спасибо
А я то думал: «зачем это подавление справочными вопросами, которые решаются с помощью гугла и исходников того же element-ui?».
«… упадут зарплатные ожидания» — теперь понятно. Умно!
+1
Вообще зачем задавать вопросы по фреймворку?
0
+1
Спасибо за пост. Вы здорово повеселили меня и скрасили вечер. :)
Отдельное спасибо Agel_Nash за комментарий.
Отдельное спасибо Agel_Nash за комментарий.
+1
Больше повесили комментарии к посту)
0
В последнем примере почему вы добавили
const { item } = this;
, а не оставили
this.item
?
0
Внутри методов и computed-функций я использую и деструктуризацию, и обращение через this, это зависит от контекста.
Если функция маленькая и использует переменную только один раз, то я обращаюсь через this (деструктуризация выглядит слишком громоздко для метода из одной строчки):
Однако если метод большой и использует переменную несколько раз, то я предпочитаю деструктуризацию:
Благодаря деструктуризации
После таких махинаций код выглядит немного почище и попонятней :)
Если функция маленькая и использует переменную только один раз, то я обращаюсь через this (деструктуризация выглядит слишком громоздко для метода из одной строчки):
export default {
/* ... */
computed: {
formattedValue() {
return this.value.toFixed(2);
},
isInCart() {
return this.presentInCart(this.item);
},
},
};
Однако если метод большой и использует переменную несколько раз, то я предпочитаю деструктуризацию:
export default {
/* ... */
mounted() {
const { field } = this.$refs;
if (!field) {
return;
}
this.fieldWidth = field.offsetWidth;
this.doSomething();
},
computed: {
progress() {
const { start, end } = this;
if (start === 0 && end === 0) {
return '50%';
}
return `${(start / (start + end)) * 100}%`;
},
},
};
Благодаря деструктуризации
- В длинных методах сразу понятно, какие переменные объекта используются, так как использующиеся поля объявляются вначале
- JavaScript после минификации меньше весит
После таких махинаций код выглядит немного почище и попонятней :)
0
Каким образом можно научиться разбирать подобные примеры неочевидного поведение в работе фреймворка? В процессе работы над проектом или в изучении исходников?
0
Sign up to leave a comment.
8 худших вопросов на собеседовании по Vue.js