Як я можу оцінити знання кандидата 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-blockvs 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. Заголовок висотою 100 пікселів;
3. Кнопка входу в правому куті заголовка
4. Панелі зліва та справа: ширина 100 пікселів та висота 200 пікселів;
5. Центральна панель для тексту статті.
6. Нижній колонтитул, який завжди буде внизу. Навіть якщо стаття має 1 рядок.

UPD: Люб'язно, попросіть розробника написати код лише з використанням divs (без таблиць).

Це має виглядати так:

Але перед тим, як пройти співбесіду в прямому ефірі, я б запропонував вам протестувати кандидатів в Інтернеті. Тому що простіше перевірити кандидатів в Інтернеті та запросити на співбесіду лише хороших кваліфікованих розробників, ніж витрачати свій час на кожного кандидата.

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

Тони людей вимагали багаторічного досвіду роботи з CSS, але коли їх натискали, щоб виписати, вони писали в диких здогадах на кшталт " layout: floating; direction: up;" чи інших подібних ривок. Більше 1 "CSS Ninja" навіть не отримав синтаксису правильно, a la " div(margin=5)". Це було для мене дуже відкритим для того, щоб побачити, скільки людей просто прямує на інтерв'ю. І, здавалося б, простіше брехати про CSS, ніж про просто кодування. Ви не можете нічого знати про CSS, але зробіть якийсь гугл і зможете досить швидко перекинути відповідну термінологію. Наприклад, ви не можете зробити це ефективно з такими поняттями вищого рівня, як OOP.

Існує онлайн-тест, в якому за 5 хвилин потрібно перерахувати теги HTML або властивості CSS .

Хоча це і не є повноцінним тестом, це може повідомити вам, чи кандидат достатньо знайомий з HTML / CSS.

Щодо питання, ви можете зробити тест із зразком коду та попросити його виявити синтаксичні / структурні помилки.

Що стосується реального сценарію життя, то тут все залежить від того, над яким кандидатом буде працювати у вашій компанії. Якщо ви хочете лише розробник на передньому кінці, ви можете попросити розробити веб-сайт на випадковій темі.

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

Важливо правильно використовувати цей вид тесту: як і будь-яке запитання про співбесіду, важливим є спосіб підходу кандидата до завдання, а не лише результати.

Я не збираюся розміщувати свій тест, але деякі підказки, як застосувати це до CSS:

• Синтаксичні помилки: пропустіть деякі крапки з комою. Як бонус, ви можете пропустити деякі факультативні (аргументований стиль) і подивитися, чи коментує кандидат.
• Логічні помилки: введіть префіксовану властивість після нефіксованої. Це також перевіряє на ознайомлення з CSS3 і може викликати дискусію щодо способу розробки стандарту.
• Кутові випадки: наприклад, маржа з ​​3 значеннями - ви здивуєтеся, скільки людей не знають, що це можливо. Якщо кандидат не коментує, ви можете запитати, як це трактується, щоб перевірити, чи не ігнорували вони це знання, а не незнання.
• Ще один кутовий випадок: виконайте вподобання двох-трьох помилок IE7. Це дозволить відрізнити тих, хто має шрами (які повинні помітити хоча б один з них) від недосвідчених або лише для Вебкітів.
• Стиль: надмірна специфічність, відсутність emі pxт.д. Хто - то , хто вивчав синтаксис для інтерв'ю , ймовірно , НЕ буде зловити багато з них.

З особистого досвіду роботи з іншими розробниками, я думаю, що питання щодо HTML та CSS не розберуть людей, які знають, про що вони говорять, від тих, хто знає, що насправді робить.

Я рекомендую макетний тест / прототип, заснований на реалістичному досвіді потреб вашої компанії.