Комментарии 29
Сколько денег предлагали?
def answer (i):
for i in (79, 113, 51, 52):
return True
for i in (84, 93, 99, 123, 110, 29, 44, 62, 19, 13, 33, 105, 120):
return False
Ну что я прошел?
нет, примеров кода у меня нет. Нет, вообще никаких. ГитХаба нет. Всё,
что я делал - под NDA. И я даже не могу вам рассказать, что был за
проект и чем я там занимался, потому чтогладиолусNDA
Что-то мне кажется, вы или хитрите или преувеличиваете. Да, код всегда под NDA, никто не обязан его вам показывать. Тем паче настоящий боевой код это коллективное творчество. Заливать его на личный гитхаб не только незаконно, но и некрасиво. И иметь пет-проекты тоже никто не обязан. У нас на сеньорскую команду из 30 разрабов ладно если у 1-2 найдется что-то "хоббийное" на гитхабе. Видимо, с точки зрения Истинных © Сеньоров-Помидоров мы просто никто.
Но я еще ни разу не видел, чтобы кандидат отказывался рассказать о своих рутинах под предлогом NDA. Сам за последние полгода ~40 собесов провел. Если не выпытывать имена, пароли и явки, то без проблем рассказывают в общих чертах архитектуру, проблемы, решения. Как правило уже на этом этапе понятно, кто тащил, а кто "делал таски и правил баги".
В том и дело, что за NDA пытаются скрыть отсутствие опыта. Если у человека есть какой-то опыт разработки, то подобных ситуаций и не возникает. Ха, они наверняка думают, что "таски" - это среднее между таксой и хаски!
так это все релевантно для джунов,и ГитХаб и пет-проекты. Остальным уже не нужно, они уже в дамках.
Спасибо, познавательно, с точки зрения джуна в поиске оффера.
А список вопросов в конце - вообще заряд настроения на весь день :D
Как титулованный джун соглашусь, что тестовое задание нужно. У джуна может быть в резюме стек, который он в какой-то мере знает, но эту меру сам не особо сознаёт, т.к. сравнить не с кем и оценить некому.
И резюме у джуна: вот стек, вот гитхаб. Что он ещё о себе расскажет? И HR будет сидеть и гадать по такому резюме, и придумывать "фильтр", который будет сродни рандому.
Бонус: ещё 15 идиотских вопросов из тех 200 пунктов
Это оксфордский тест саентологов) могу скинуть весь + ответы
Прочла статью, зашла в тестовое, и заглянула в джейсон лишь потому, что было в статье указано, что там будут подвохи.
Я просто бекенд, с некоторым креном в фулстек. Пока представляю себе реализацию только на Vue. Но "как вообще бекенд может отдать кривой файл с данными" - это вот в голове не укладывается. Данные же достали из базы данных, а перед складыванием в БД данные валидировали.
Я бы не догадалась, короче, зайти в джейсон.
Отсюда, пожалуй, вопрос - а как это может случиться, такой вот кривой файл с данными на фронтенде?
Золотое правило - не доверять данным, полученным из внешних источников. Представьте, что в контексте того же ТЗ набор фигур сохранялся в БД. И когда-то в нём были треугольники, а потом их убрали на фронте, но в базе они почему-то остались...
Или другой вариант, представьте, что вы данные получаете вообще от чужого сервиса, например, Гисметео. И они сначала поставляли только данные солнечно/дождь, а тут добавили ещё значение "пасмурно".
И как должно отреагировать ваше приложение? В панике упасть и лежать, пока не починят? Или выдать предупреждение в консоль и работать?
А как ему работать, когда корректных исходных данных нет?
Корректные есть. Просто они оказались чуть шире, чем предполагалось))
Ннет, там ещё есть такая circa , строка 76 в джейсоне на гитхабе. Собственно, сразу за треугольником. Как вот такое вот возникает в данных?
Или всё таки это пример избыточно битый?
И, собственно, а для чего что-нибудь выдавать в консоль, если консоль у пользователя? Вот у вас axios, он же там уже в рамках требований основного тестового. Мне бы казалось логичным пушить такие ошибки аксиосом в свои логи на сервере. Чтобы увидеть проблему в консоли, надо, чтобы кто-нибудь неленивый день за днём ходил бы на эту страницу, причём с конкретными данными. Т.е., оно два-три раза в день пяти пользователям из тысячи что-то в консоль выводит. А как вы об этом узнаете как разработчик?
Если коротко, как фронтендеры обнаруживают, что что-то пошло не так у юзера Х с данными У? Пока взбешённый пользователь не позвонил в техподдержку сам?
Добрый день ещё раз,
обдумывала ваше тестовое неоднократно. Я просто только-только начинаю реакт (я больше в бекенде), вижу, как это написать на вью, но слышу (по сторонам), что реакт моднее. А главное, в чём-то круче. Но я не знаю, в чём именно.
Вопрос, а на таком вот тестовом должно ли быть видно, чем реакт лучше вью?
На вью просто тоже есть менеджер состояний вьюекс, и вот это всё на вью + вьюекс + аксиос я напишу, возможно, за меньше часа.
В таком контексте вообще все равно на чем писать, что привычнее, то и быстрее, разницы не будет. Более того, что на Реакте, что на Вью, это всё можно написать десятью разными способами.
Про "моднее" - давний холивар. На мой вкус, Реакт на нынешней ступени развития все же обгоняет Вью по инфраструктуре, а удобство обеспечивает не хуже. Но Вью тоже на месте не стоит..
А как получилось, что, скажем, на этом проекте, куда вы человека искали, там был реакт?
И как вы сами начали писать на реакте?
Если, конечно, на эти вопросы есть внятные ответы. Я просто в своё время, когда о фреймворках узнала, стала (в бекенде) учить конкретно именно Такой-то Фреймворк лишь потому, что тогда не решилась браться сразу за документацию, а книгу бумажную ака учебник нашла только вот про тот самый Такой-то.
Не зная ни одного фреймворка и некоторых других аспектов браться за официальную документацию, имхо, дохлый номер - не знаешь просто, на что смотреть. А то, что там обычно указывают как пробник или начало - уже совсем не пробник и не начало. Это скорее сравнение с другими такими же. И пояснение с порога, чем оно лучше технически.
Возможно, на оба мои вопроса выше ответ такой же: "так получилось".
Давайте погадаем по тестовому заданию, стоит и идти работать в эту компанию..
По технологиям:
Axios: используется библиотека на 10 кб, чтобы просто делать хттп-запросы. Это означает, что техлид тянет в проект первые попавшиеся либы, совершенно не думая о его полезности. И не способен написать простейшую обёртку на 10 строк.
Redux: централизованное хранение данных свидетельствует о плохой декомпозиции проекта. Это означает, что архитектор не работал с проектами сложнее hello world, и не понимает, что глобальная шина событий очень плохо масштабируется.
React: используется популярное решение с непродуманной архитектурой. Это означает, что техдир навязывает технологии ориентируясь на рынок труда, а не на техническую целесообразность, что влечёт трату большого количества времени разработчика на борьбу с фреймворком и постоянное разрастание команды.
По макету:
Семантически однородные фильтры расположены в совершенно разных местах и выполнены разными типами контролов. Это означает, что UX-ер лепит интерфейсы от балды, не ориентируясь на информационную архитектуру.
Число колонок задаётся в конфиге, а не выставляется автоматически для оптимального заполнения экрана. Это означает, что верстальщик не умеет в адаптивную вёрстку.
Макет нарисован в виде мобильного экрана в портретном режиме. Это означает, что дизайнер практикует рисование по отдельному макету на каждый типоразмер экрана, что крайне не эффективно тратит его время.
Резюмируя: ни чему хорошему вы у дилетантов не научитесь.
Вот, смотрите, я выполнил это задание на $mol пока завтракал... Исправил UX, сделал по настоящему адаптивный дизайн под любые экраны, реализовал поддержку локализации, реализовал это всё на нормальных технологиях, поощряющих хорошую архитектуру при минимуме бойлерплейта...
Сперва делаем карточку фигуры, которая умеет показывать квадраты, круги и даже треугольники, которые есть в данных:
my/shapes/shape/card/card.view.tree
$my_shapes_shape_card $mol_view
attr *
^
my_shapes_shape_card_form <= form \circle
my_shapes_shape_card_bright <= bright \light
style *
^
backgroundColor <= color \grey
minimal_width 80
minimal_height 80my/shapes/shape/card/card.view.css.ts
$mol_style_define( $my_shapes_shape_card, {
flex: {
basis: rem(5),
grow: 1,
shrink: 1,
},
aspectRatio: '1/1',
maxWidth: vh(50),
'@': {
my_shapes_shape_card_form: {
circle: {
border: {
radius: per(50),
},
},
triangle: {
clipPath: `polygon( 50% 0, 100% 100%, 0 100% )`,
},
},
my_shapes_shape_card_bright: {
dark: {
filter: 'brightness(.5)',
},
},
},
} )Теперь реализуем схему загружаемых данных:
/my/shapes/catalog/catalog.view.ts
enum DataForms {
circle = 'circle',
square = 'square',
triangle = 'triangle',
}
const DataShape = $mol_data_record({
form: $mol_data_enum( 'Form', DataForms ),
color: $mol_data_string,
dark: $mol_data_boolean,
})
const Data = $mol_data_array( DataShape )
Затем запилим страницу вывода карточек для заданных фильтров, который загружает данные, валидирует их, нормализует, фильтрует, и выводит в виде сбалансированной галереи:
/my/shapes/catalog/catalog.view.tree
$my_shapes_catalog $mol_page
title @ \Shapes
form*? true
color*? true
bright*? true
body /
<= Items $mol_gallery
items <= items /
<= Item*0 $my_shapes_shape_card
form <= item_form* \circle
color <= item_color* \grey
bright <= item_bright* \light/my/shapes/catalog/catalog.view.ts
enum Bright {
dark = 'dark',
light = 'light',
}
export class $my_shapes_catalog extends $.$my_shapes_catalog {
@ $mol_mem
data() {
const data = $mol_fetch.json( '/my/shapes/data/shapes.json' ) as any
return Data( data ).map( ({ form, color, dark }) => ({
form,
color,
bright: dark ? Bright.dark : Bright.light,
}) )
}
@ $mol_mem
data_filtered() {
return this.data().filter(
shape => this.form( shape.form ) && this.color( shape.color ) && this.bright( shape.bright )
)
}
@ $mol_mem
items() {
return this.data_filtered().map( ( _, index )=> this.Item( index ) )
}
item_form( index: number ) {
return this.data_filtered()[ index ].form
}
item_color( index: number ) {
return this.data_filtered()[ index ].color
}
item_bright( index: number ) {
return this.data_filtered()[ index ].bright
}
}/my/shapes/catalog/catalog.view.css.ts
$mol_style_define( $my_shapes_catalog, {
flex: {
basis: rem(40),
grow: 1,
},
Items: {
padding: $mol_gap.block,
},
Item: {
margin: $mol_gap.block,
},
} )Потом реализуем панельку с фильтрами:
/my/shapes/config/config.view.tree
$my_shapes_config $mol_page
title @ \Config
body /
<= Filters $mol_list rows /
<= Forms_labeler $mol_form_field
name @ \Form
control <= Forms $mol_check_list
options *
circle @ \Circle
square @ \Square
triangle @ \Triangle
option_checked*? <=> form*? true
<= Colors_labeler $mol_form_field
name @ \Color
control <= Colors $mol_check_list
options *
red @ \Red
green @ \Green
blue @ \Blue
yellow @ \Yellow
option_checked*? <=> color*? true
<= Brights_labeler $mol_form_field
name @ \Bright
control <= Brights $mol_check_list
options *
dark @ \Dark
light @ \Light
option_checked*? <=> bright*? true
И, наконец, соединим панели друг с другом, получив законченное приложение:
/my/shapes/app/app.view.tree
$my_shapes_app $mol_book2
title @ \Shape Store
pages /
<= Config $my_shapes_config
form* => form*
color* => color*
bright* => bright*
<= Catalog $my_shapes_catalog
form* <= form*
color* <= color*
bright* <= bright*
Placeholder null/my/shapes/app/index.html
<!DOCTYPE html>
<html mol_view_root>
<head>
<meta name="viewport" content="width=device-width, height=device-height, initial-scale=1">
</head>
<body mol_view_root="$my_shapes_app">
<script src="web.js"></script>
</body>
</html>Результаты:
На мобилке
На планшете
На десктопе
И всё это в бандле на 30кб, что меньше, чем один только голый React.
И в итоге мы имеем токсичного хрена, который облил коллег говном, положил на требования, проигнорил макет и сделал что-то свое, потому что "так лучше".
Боюсь, с такими исходными даже на стажера не возьмут.
Мечтают ли джуны о тестовых заданиях?