Ви правильно зрозуміли питання. Хочу звернути увагу, що твердження

в оригинальной версии std::[c]ref есть также вариант [c]ref(T&)

невірне. Варіанту з сигнатурою

cref(T&)

ref(const T&)

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

template<class T> void std_cref(const T&) {}
template<class T> void std_cref(const T&&) = delete;

template<class T> void bad_cref(const T&) {}
template<class T> void bad_cref(T&&) = delete;

int main() {
	int i = 0;
	std_cref(i);
	bad_cref(i);  // error: call to deleted function 'bad_cref'
	return 0;
}

Тенденція на генералізацію завжди існувала, але термінологія мені все ще не зрозуміла. За такою логікою на етапі testing skills можна було би просити інженера пройти всі попередні віртуальні етапи, а саме: витягнути вимоги із замовника, спроектувати продукт, запрограмувати його та створити тестову документацію.

Був би радий, якби хтось пояснив, чому процес requirements elicitation називають system design. Вважаю, що було би коректно проводити такі інтерв’ю з підготовленим документом з вимогами.

Не можу з вами до кінця погодитись. Протягом всього часу, що цікавлюсь цими питаннями, я не зміг знайти згадки про процес, в якому архітектура могла би бути первинною. Отже, відомі мені альтернативи такі: (1) розробка вимог -> виділення архітектурно значущих вимог -> розробка архітектури; (2) розробка системи -> виділення аспектів архітектури (поки що в статусі гіпотез) -> перевірка отриманих гіпотез (у разі потреби повертаємось до попереднього кроку) -> побудова архітектури.

А як під час співбесіди взагалі можна розробити архітектуру системи на словах? Моє перше питання в такому випадку — «дайте почитати вимоги». Відповідь завжди одна з двох: або «це тестовий приклад; в нас немає вимог» (а далі пауза), або «ну ви самі придумайте».

Рекрутери жаліються, що Senior Automation QA крутять носом від 5к. Щось мені підказує, що в розробників справи не гірше йдуть. Життєва мудрість каже, що важливо знати, які 20% зусиль дають 80% успіху, і сконцентруватись на них.

Іване, уточніть, будь ласка, в чому полягають погані новини для мене. Я не зрозумів ваш натяк.

Так, це вірно. Головне питання в тому, для чого додавати кваліфікатор const до типу параметру. На перший погляд, «rvalue нельзя изменять внутри функции» не має ніякого смислу. Більше того, ці функції навіть не мають тіла.

«этим типом должен быть обязательно именно класс» — не обов’язково, int теж підходить. В цьому контексті class може бути замінений на typename без зміни значення коду.

Приходьте в гості, у мене є кілька цікавих :) Для підігріву інтересу ось одне із них:
// what is the purpose of these declarations from the standard library? // pay attention to the unusual parameter type template <class T> void ref(const T&&) = delete; template <class T> void cref(const T&&) = delete;

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

Так, звичайно. Обидві прекрасно себе почувають і потихеньку зростають. От нещодавно в одній вирішили покривати витрати на переліт в США для людей, які будуть там вакцинуватись.

У двох компаніях працював з відпусткою за свій рахунок, компенсація за яку додавалась до обговореної зарплатні. Один раз я був ініціатором такої схеми, інший — компанія. На мою думку, цей формат роботи більш вигідний для працівника, оскільки прибирає важіль впливу під назвою «невикористану відпустку при звільненні не компенсуємо».

Як написати відгук, якщо це заборонено або суттєво обмежено (наприклад, тільки позитивні відгуки) через NDA? Вважаю, що dou потрібно запровадити прозору систему написання анонімних верифікованих відгуків. Я не користуюсь галочкою «опублікувати анонімно» саме через те, що немає механізму переконатися в тому, що зв‘язок з профілем в linkedin не може бути відновлений після публікації відгуку.

В одній з таких шкіл, яка позиціонувала себе приблизно як «ми команда професіоналів зі значним досвідом», більшість викладачів були дуже молодими, а один з них — підліток.

Работаю на macOS. По умолчанию нажатие на эти кнопки ни к чему не приводит. Через настройки можно легко задавать им поведение хоть на уровне системы, хоть в каждом приложении отдельно.

Я тащусь от такой раскладки: слева от короткой клавиатуры трекпад, справа — проводная мышь Xtrfy M4. В руке лежит удобно за счет формы и больших размеров, легкая, с хорошей вентиляцией. Под большой палец есть 2 крупные и полезные кнопки.

Як тільки в тестовому завданні з‘являється .gitignore, його також починають оцінювати. Можу навіть уявити реакцію: «Фу, кандидат не витратив 5 хв, щоб його причесати, а машинально вкинув дефолтний. Мабуть, не розуміє для чого той файл треба». Така деталізація, як вірно зауважили інші, кінця-краю не має.

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

Колись було завдання, яке складалось із трьох частин: інтерфейсу, реалізації та дрібки тестів. Кандидату видавали інтерфейс (вихідний код) і еталонну реалізацію в вигляді бінарного файлу. Завдання полягало в тому, щоб написати реалізацію — код. Очікувалось, що кандидат буде дописувати test suite та проганяти через нього різні дані, щоб здогадатись, що всередині еталонної реалізації. Але трапилась людина, яка вміла розбирати асемблер, і просто відновила код еталонної реалізації з бінарного файлу. Таку роботу не зарахували.

Що вищий рівень спеціаліста, то більше ви очікуєте побачити у коді

Професіонал чітко дотримується завдання, економлячи ресурси замовника. Якщо у вас є певні очікування щодо обробки помилок, логування чи наявності .gitignore, варто детально прописувати їх у списку вимог.