Как я могу оценить знания кандидата в области HTML / CSS во время интервью? [закрыто]

Я пытаюсь определить несколько хороших вопросов для интервью, чтобы оценить способность людей приходить на работу по HTML / CSS, однако эта тема чрезвычайно широка, и я не уверен, какие вопросы я могу задать, чтобы правильно оценить чей-то HTML / Знание CSS.

Какие вопросы я могу задать, чтобы оценить способности кандидата в области HTML / CSS во время интервью?

В идеале я хотел бы задать несколько вопросов, а затем дать им реальный сценарий борьбы.

HTML и CSS сложно взять на собеседование по нескольким причинам:

1. Они слишком простые, по сравнению, например, с языком программирования,

2. Они очень сильно зависят от контекста работы. Примеры:

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

   • Если вы создаете действительные веб-сайты XHTML W3C, вы должны убедиться, что кандидаты знают разницу между XHTML 1.0 и XHTML 1.1 или какие атрибуты являются обязательными <img/>и т. Д.

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

   • и т.п.

3. Если это чисто HTML и CSS работа, то человеку придется работать с дизайнерами, с одной стороны, и разработчиками, с другой. Они должны знать HTML и CSS, но гораздо важнее их способность взаимодействовать с этими людьми , а также понимать потребности дизайнеров, требования разработчиков и ограничения HTML и CSS.

   Например, они должны знать, как структурировать свой HTML таким образом, чтобы разработчику JavaScript было проще добавить интерактивность позже.

Вы можете начать с некоторых основных вопросов:

Какой ваш любимый браузер?

Если человек отвечает «Internet Explorer», немедленно прекратите собеседование: вам не нужен такой человек.

Нет, я шучу. Ответ не имеет значения. Вместо этого вы можете задать следующее:

Расскажите мне об инструментах отладки, которые вы используете в своем любимом браузере.

Основное использование Chrome, я ежедневно работаю с инструментами разработчика. Эти инструменты позволяют мне:

• Просматривать запросы, сделанные со страницы,

• Изучите время, необходимое для загрузки страницы и связанных ресурсов, особенно поиск DNS, время ожидания и получения,

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

• Просмотрите DOM и изучите, как применяются селекторы CSS,

Я также использую YSlow, который служит мне контрольным списком для оптимизации сайта, который требует высокой масштабируемости. YSlow также является хорошим инструментом для определения, правильно ли настроен сервер (отправка правильных заголовков и т. Д.).

В Firefox я использую Firebug, инструмент, очень похожий на Инструменты разработчика из Chrome. Инструменты разработчика также доступны в новых версиях Internet Explorer, а также позволяют переключаться в представления совместимости IE7 и IE10. Эта последняя функция очень полезна, так как без нее я был бы вынужден установить несколько виртуальных машин только для устаревшего тестирования или гораздо чаще использовать платные сервисы, такие как Litmus .

Пожалуйста, объясните мне, что это за <dl/>тег? Для чего предназначался этот тег? Как это используется на практике? Что вы думаете об этом расширенном использовании?

Здесь вы хотите, чтобы человек мог объяснить это <dl/>для словарей, связывающих один ключ <dt/>с одним или несколькими значениями <dd/>. Хотя основное использование этого тега было чисто связано с семантикой, на практике он широко использовался для замены таблиц, хорошим примером является PHPBB3. Это хорошо, когда таблицы замедляют визуализацию страницы, но ее следует использовать с осторожностью: во многих случаях не только таблицы подходят для лучшего описания данных, но также могут быть и другие средства, такие как обычные списки, чтобы описать содержание без использования <dl/>.

В чем разница между фиксированной и жидкостной схемами? Каковы плюсы и минусы каждого?

Фиксированный макет имеет предопределенную ширину элементов. Элементы жидкого макета зависят от ширины страницы.

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

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

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

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

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

Что вы думаете об этом куске кода <p color="Red" align="Center">Text here</p>?

У части кода есть недостаток, чтобы смешать логику представления в HTML. Логика представления должна быть вставлена ​​в CSS по нескольким причинам:

• Это помогает разделить проблемы и чистый код, что означает более дешевое обслуживание позже,
• Это делает стили многократно используемыми от страницы к странице, что (за исключением проблем сопровождения) помогает гарантировать, что вы используете одни и те же стили на всем сайте,
• Это помогает уменьшить пропускную способность, поскольку файлы CSS будут кэшироваться.

После нескольких базовых вопросов вы можете задать несколько более сложных:

Как избежать дублирования цветов или шрифтов в CSS, когда эти цвета или шрифты применяются к нескольким элементам, которые не могут быть нацелены одним селектором? Есть ли недостатки?

Вы делаете это с помощью CSS-препроцессоров, таких как Sass или LESS. Они позволяют определять цвета, шрифты и другие части стиля внутри переменных, которые вы можете использовать позже в своих стилях.

Недостатки CSS-препроцессоров заключаются в том, что:

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

• Они известны только нескольким разработчикам, что затрудняет присоединение или поддержку проекта новому человеку,

• Нет хороших и быстрых IDE для Sass или LESS, и интеграция в самые популярные IDE довольно разочаровывает.

Приведите пример hrefзначения изображения в CDN, учитывая, что это изображение отображается на веб-сайте, доступ к которому можно получить как по HTTP, так и по HTTPS.

Поскольку HTTPS требует, чтобы каждый вызываемый ресурс также был включен в HTTPS (в противном случае пользователю будет отображаться предупреждение о безопасности во многих случаях), невозможно указать ссылку как http://cdn.example.com/image.png. Чтобы правильно ссылка на изображение, //cdn.example.com/image.pngдолжна быть использована; Браузер будет добавлен http:или https:зависит от контекста.

Учитывая, что размер страниц и количество запросов на веб-сайте не могут быть оптимизированы, а содержимое не может быть изменено, а AJAX не может быть добавлен, как вы создаете у пользователя впечатление, что веб-сайт работает быстрее? Что это включает в себя с точки зрения HTML?

Если используется HTTP 1.1, страница может быть разделена на части . Это означает, что первые части будут появляться быстрее, создавая впечатление, что сайт работает быстрее, чем на самом деле. Кодирование передачи по частям невозможно в HTTP 1.0, что означает, что в этом случае ничего не нужно делать.

Возможность обслуживания фрагментированного контента требует с точки зрения HTML переупорядочения элементов, помещая наиболее важные из них в верхнюю часть файла (что не означает, что они должны будут отображаться в верхней части страницы). Например, на веб-сайте электронной коммерции, когда пользователь хочет просмотреть подробную информацию о продукте, первый блок может содержать данные <head/>о продукте и. Следующий блок может содержать основные элементы, такие как логотип веб-сайта, главное меню, авторские права и т. Д. Наконец, последний блок может содержать раздел «Люди, купившие это, также купили», комментарии и оценки продукта, «Поделиться в Facebook» и т. д.

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

Пожалуйста, не могли бы вы создать страницу XHTML с двумя зонами: левой со списком и правой с текстом. Две зоны разделены вертикальной линией, которая простирается от самого верха до самого низа страницы. Список и текст различаются по размеру, вы не можете предсказать, какой из них будет иметь наибольшую высоту. Вы не можете использовать <table/>s.

На самом деле, это довольно просто, но показывает, есть ли у человека рефлекс, чтобы думать о высоте. Неопытный кандидат создаст float:leftзону и border-left:solid 1px #ccc;зону, но забудет добавить границу в левую зону и расширить ее так, чтобы две границы были в одном месте.

Вот несколько вопросов, которые я хотел бы задать о CSS:

1. Блочная модель CSS. Поля, отступы и т. Д. Модель IE и модель W3C. Как можно переключаться между двумя? Каковы их преимущества и недостатки?
2. CSS позиционирование. Что означает, что элемент находится «в потоке» и «вне потока»
3. inline-blockи другие отображаемые значения. Разница между display: none;и visibility: hidden; (это хороший и простой вопрос для новичков в CSS)
4. inline-blockпротив floatмакетов.
5. Искатели.
6. CSS сбрасывает. Зачем они нужны и чего они достигают?
7. Медиа-запросы и адаптивный дизайн.
8. Как организовать стили и как сохранить количество селекторов небольшим. LESS, Sass и другие CSS препроцессоры. Объектно-ориентированный CSS.

И несколько вопросов о HTML:

1. Doctype и режимы браузера.
2. Почему некоторые теги являются более предпочтительными, чем другие ( emпротив, iнапример)?
3. Каковы основные принципы, которым нужно следовать, чтобы HTML и CSS были управляемыми и простыми в обслуживании?

В целом, я уделяю больше внимания CSS, так как это область, которую многим людям трудно понять и эффективно использовать. Я встречаю много кандидатов, которые помещают «CSS» в свои резюме, но не могут ответить на любые вопросы по этому поводу. Большинство людей просто говорят: «Нет-нет, я знаю CSS достаточно хорошо, чтобы справиться с этим, но недостаточно хорошо, чтобы говорить об этом».

Иногда хорошей идеей будет просто дать простое задание и собеседнику выполнить его. Скажем, создайте простую страницу с макетом и блочным стилем, который поддерживает несколько размеров экрана и настраивается соответствующим образом. Это займет около часа или двух, и кандидат должен объяснить, что он делает и почему.

Удачи в интервью!

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

Пример (очень распространенный в реальной разработке). Попросите разработчика написать html / css код страницы с:

1. Ширина жидкости.
2. Заголовок с высотой 100px;
3. Кнопка входа в правом углу заголовка
4. Левая и правая панели шириной 100 пикселей и высотой 200 пикселей;
5. Центральная панель для текста статьи.
6. Нижний колонтитул, который всегда будет внизу. Даже если статья имеет 1 строку.

UPD: Конечно, попросите разработчика написать код, используя только div (без таблиц).

Это должно выглядеть так:

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

Я участвовал в нескольких интервью с веб-дизайнером, и мы распечатали очень простой макет блога на бумаге, а затем попросили кандидата просто набросать немного HTML и / или CSS на странице в течение 10 минут или около того, чтобы дать нам базовую идею о том, как они это закодируют. Это дает нам знать, если кто-то на самом деле знал CSS или нет. Мы просто искали базовые вещи, такие как плавающие таблицы или что-то в этом роде, и объяснили, что это не обязательно должно быть идеально.

Тонны людей требовали многолетнего опыта работы с CSS, но когда их заставляли писать, они писали в диких догадках, таких как " layout: floating; direction: up;" или другой подобной ерунды. Более 1 "CSS Ninja" даже не получили правильный синтаксис, а-ля " div(margin=5)". Это было очень открытое для меня, чтобы увидеть, сколько людей просто прямо лежат в интервью. И, казалось бы, легче лгать о CSS, чем о прямом кодировании. Вы не могли бы ничего знать о CSS, но немного погуглили и смогли бы довольно быстро обойти правильную терминологию. Вы не можете сделать это эффективно с концепциями более высокого уровня, такими как ООП, например.

Существует онлайн-тест, в котором вы должны перечислить теги HTML или свойства CSS за 5 минут.

Хотя этот тест не является полностью защищенным, вы можете узнать, достаточно ли знаком с кандидатом HTML / CSS.

Что касается вопроса, вы можете сделать тест с примером кода и попросить его обнаружить синтаксические / структурные ошибки.

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

Один тип теста, который применим к языкам программирования и языкам разметки, - это проверка кода. Создайте небольшой образец (20 или 30 строк) со смесью синтаксических ошибок, логических ошибок, угловых случаев, возможно, плохого стиля ... Затем попросите кандидата определить все, что кажется ему подозрительным.

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

Я не собираюсь публиковать свой тест, но некоторые советы о том, как применить это к CSS:

• Синтаксические ошибки: пропустите несколько точек с запятой. В качестве бонуса вы можете пропустить некоторые дополнительные (спорный стиль) и посмотреть, комментирует ли кандидат.
• Логические ошибки: ставьте префиксное свойство после нефиксированного. Это также проверяет знание CSS3 и может спровоцировать дискуссию о том, как разрабатывается стандарт.
• Угловые случаи: например, поле с 3 значениями - вы будете удивлены, сколько людей не знают, что это возможно. Если кандидат не комментирует, вы можете спросить, как он интерпретируется, чтобы убедиться, что он проигнорировал это из-за знания, а не по незнанию.
• Еще один поворотный случай: используйте ваши любимые две или три ошибки IE7. Это позволит отличить тех, кто имеет боевые шрамы (которые должны заметить хотя бы одного из них) от неопытного или только для Webkit.
• Стиль: чрезмерная специфика, отсутствие emи pxт. Д. Кто-то, кто изучал синтаксис для интервью, вероятно, не поймет многих из них.

Исходя из личного опыта, работая с другими разработчиками, я думаю, что вопросы по HTML и CSS не выберут людей, которые знают, о чем они говорят, и тех, кто знает, что они на самом деле делают.

Я бы порекомендовал фиктивный тест / прототип, основанный на реальном опыте потребностей вашей компании.