C/C++

Do programu wchodzą obiekty. W każdym obiekcie może być podany numer telefonu i/lub login (albo jedno z tych wartości, albo oba naraz), a także ładunek w postaci danych binarnych. Przychodzące obiekty należy zapisywać w pamięci operacyjnej z zachowaniem następujących ograniczeń: Jeśli przychodzący obiekt ma login i/lub telefon taki sam jak jeden z wcześniej zapisanych, to zapisany obiekt należy usunąć, a przychodzący nie zapisywać. Jeśli obiekt pozostaje w pamięci operacyjnej dłużej niż 60 sekund, należy go usunąć. Uważa się, że obiekty przychodzą często. Przy tym, obiekty pasujące po loginie/telefonie są znacznie rzadsze od ogólnej liczby przychodzących obiektów. void process(Object o) { }

[imię] opowiedz mi o sobie, produktach, nad którymi pracowałeś, oraz zadaniach, które wykonywałeś.

Podczas przeglądu widać diff, który wygląda jak gruby kopiuj-wklej lub dziwny hack — kod wykonuje potrzebne działanie, ale nie jest oczywiste, jak działa lub czy w ogóle działa poprawnie. Jakie są Twoje dalsze kroki?

Jakie właściwości powinna mieć zadanie, aby przeciwnie, wywołać reakcję 'Ojej, nie chcę się tym zajmować'?

A co, przeciwnie, odpycha na takich wydarzeniach?

Jakie cechy powinien mieć kolega, aby praca z nim była komfortowa?

Jak rozpoznać, że zmiana (np. przejście z Boost na bibliotekę standardową) naprawdę « działa »?

Jak odnosisz się do aktywności poza pracą (fora, imprezy firmowe, sport) i co najbardziej cię w nich przyciąga?

Czy brałeś udział w technicznych sporach/dyskusjach w zespole? Jak one przebiegały i jak zostały rozwiązane?

Czy miałeś doświadczenie w dużym refaktoryzowaniu dużej bazy legacy? Jeśli nie, jak byś postąpił, gdybyś musiał to zrobić?

Co skłoniło cię do poszukiwania nowego miejsca?

Dlaczego odszedłeś z poprzedniego miejsca pracy?

Zadanie do przeglądu kodu: kolega zgłosił rozwiązanie, które działa i jest pokryte testami jednostkowymi, ale implementacja w ogóle nie jest taka, jaką byś zrobił sam. Co zrobisz?

Sytuacja: dwóch menedżerów przychodzi i zadaje dwa pilne zadania, a czasu na nie nie ma. Co byś zrobił?

Jaki jest plan refaktoryzacji i co musi być, aby robić to pewnie?

Jak można zaimplementować optymalizację RVO/NRVO w kompilatorze?

Jak uniknąć sytuacji, w której po trzech miesiącach wszystko jest "rozrzucone" i nic nie działa, jeśli lider zdecydował się radykalnie przepisać kod (np. usunąć Boost)?

Proszę opowiedz o najbardziej zapadających w pamięć zadaniach lub projektach z twojego poprzedniego doświadczenia — co ci się podobało, a co, przeciwnie, nie przypadło do gustu.

Co zostanie wyświetlone na ekranie? (Pytanie 1: konstruktory, RVO/NRVO)

Czy podczas projektowania było wystarczająco informacji do analizy, czy decyzja była raczej podejmowana na ślepo, ale z powodzeniem?