Treść zadania brzmiała mniej więcej tak: Tu masz interfejs, tu jest klasa z testami, zaimplementuj to tak żeby testy przechodziły. Ogólnie chodziło o to aby napisać implementację która zlicza częstotliwość wystąpienia danego znaku w wyrazie i zwracać to jako mapę Map<Character, Double>, np:

• a -> map.get(a) -> 1
• ab -> map.get(a) -> 0.5 / map.get(b) -> 0.5
• aaa -> map.get(a) -> 1
• AaA -> map.get(a) -> 1
• abcd -> map.get(a) -> 0.25

Interfejs:

public interface Frequency {
    Map<Character, Double> analyze(String analyze);
}

Klasa testowa: (gist)

class FrequencyTest {

    private Frequency frequency;

    @BeforeEach
    void setUp() {
        frequency = getFrequency();
    }

    @Test
    void should_return_1_for_single_character() {
        Map<Character, Double> result = frequency.analyze("a");

        assertEquals(1.0, result.get('a'));
    }

    @Test
    void should_return_half_when_two_different_characters() {
        Map<Character, Double> result = frequency.analyze("ab");

        assertEquals(0.5, result.get('a'));
        assertEquals(0.5, result.get('b'));
    }

    @Test
    void should_return_1_for_the_same_character() {
        Map<Character, Double> result = frequency.analyze("aaa");

        assertEquals(1.0, result.get('a'));
    }

    @Test
    void should_return_even_half_when_two_different_characters() {
        Map<Character, Double> result = frequency.analyze("aab");

        assertEquals(0.5, result.get('a'));
        assertEquals(0.5, result.get('b'));
    }

    @Test
    void should_return_even_half_when_different_characters() {
        Map<Character, Double> result = frequency.analyze("abcd");

        assertEquals(0.25, result.get('a'));
        assertEquals(0.25, result.get('b'));
        assertEquals(0.25, result.get('c'));
        assertEquals(0.25, result.get('d'));
    }

    @Test
    void should_return_1_for_the_same_character_with_Upper_And_Lower_case() {
        Map<Character, Double> result = frequency.analyze("AaA");

        assertEquals(1.0, result.get('a'));
    }

    @Test
    void should_return_even_half_when_different_characters_occurs_few_times() {
        Map<Character, Double> result = frequency.analyze("aaaAbcdd");

        assertEquals(0.25, result.get('a'));
        assertEquals(0.25, result.get('b'));
        assertEquals(0.25, result.get('c'));
        assertEquals(0.25, result.get('d'));
    }

    @Test
    void should_throw_exception_when_null_input() {
        assertThrows(IllegalArgumentException.class, () -> frequency.analyze(null));
    }

    private Frequency getFrequency() {
        return null;
    }
}

Jeżeli chodzi o samą klasę testową to nie zapamiętałem wszystkich testów jakie tam były (+ ich nazw dokładnie 1 do 1), tutaj przedstawiam większą i ważniejszą część którą zapamiętałem.

1. Pierwszym krokiem jaki zrobiłem było utworzenie klasy implementującej nasz interfejs oraz zwrócenie go w teście. Nie miałem pomysłu na nazwę więc poleciała pierwsza lepsza jaka mi przychodziła do głowy FrequencyImpl. Teraz jak na nią patrzę to na pewno dałbym inną, np. FrequencyAnalyzer albo FrequencyCharacterAnalyzer.

private Frequency getFrequency() {
    return new FrequencyImpl();
}

Zgodnie z TDD pierwsze testy uruchomiłem od razu po utworzeniu domyślnej implementacji. Oczywiście wszystkie zakończyły się błędem ale o to chodzi w TDD – krótka i szybka pętla zwrotna. Następnie, czas na spełnienie pierwszego testu – rozwiązałem to tak, że stworzyłem mapę i na sztywno wpisałem wartość jaka ma być zwracana – czy to była dobra decyzja? I tak i nie. Tak, bo miałem znów bardzo szybki zwrot z informacją, że pierwszy test się udał a nie bo wiedziałem, że za chwilę i tak to zmienię więc czy dla spełniego takiego testu jest sens pisać tak PROSTĄ IMPLEMENTACJĘ?? W moim odczuciu – tak, z uwagi na pętlę zwrotną z feedbackiem że coś działa + o to właśnie chodzi w TDD – piszemy coś najprościej jak się da a później refaktorujemy, weryfikując że testy nadal przechodzą.

@Override
public Map<Character, Double> analyze(String text) {
    Map<Character, Double> characterFrequency = new HashMap<>();
    characterFrequency.putIfAbsent(text.charAt(0), 1.0);
    return characterFrequency;
}

No i dobra. Pierwszy test zaliczony, czas przejść do drugiego.

2. Mamy zwracać równe połówki gdy jako wejście dostaliśmy dwa różne znaki. Właściwie nie trzeba się nad tym za długo zastanawiać jeżeli chcemy osiągnąć cel jak najprostszym i najszybszym sposobem. Możemy wyciągnąć tablicę znaków z naszego inputa a później po niej iterować. Każdy napotkany znak wsadzamy do mapy, gdzie jako wartość robimy proste obliczenie arytmetyczne dzieląc 1 przez ilość znaków.

@Override
public Map<Character, Double> analyze(String text) {
    Map<Character, Double> characterFrequency = new HashMap<>();
    char[] chars = text.toCharArray();
    for (int i = 0; i < chars.length; i++) {
        characterFrequency.putIfAbsent(text.charAt(i), 1.0 / chars.length);
    }
    return characterFrequency;
}

Do tej pory wszystko było git. Ale teraz zaczęły się schody. I to takie których nie przeszedłem – właściwie nie wiem dlaczego.. chyba za bardzo się zestresowałem takim live codingiem. Bo żeby nie było – do wszystkiego co pisałem często były zadawane pytania – dlaczego tak, a po co to? No nieważne… jesteśmy przy drugim teście odpalamy i jest zielono (przy pierwszym i drugim teście) – lecimy do kolejnego.

3. Mamy ignorować powtórzenia, czyli w świecie baz danych musimy zrobić distinct na naszym wejściowym stringu. Potencjalnie można ten test rozwiązać na kilka sposobów a najprostszy z nich wyglądałby tak, że robimy 2 oddzielne pętle. W pierwszej wsadzamy elementy do mapy, pamiętając, że mapa w kluczu nie przechowuje duplikatów (tutaj jako wartość możemy wsadzić dowolny element będący doublem – nie ważne czy to będzie prawidłowa wartość czy nie), w drugiej natomiast (wiedząc, że nasza mapa zawiera unikatowe klucze – czyt. zrobiła distinct na stringu wejściowym) wsadzamy wartości do mapy raz jeszcze – tym razem przypisując każdemu znakowi wejściowemu prawidłową wartość – czyli dzieląć 1 przez wielkość mapy.

@Override
public Map<Character, Double> analyze(String text) {
    Map<Character, Double> characterFrequency = new HashMap<>();
    char[] chars = text.toCharArray();
    for (int i = 0; i < chars.length; i++) {
        characterFrequency.putIfAbsent(text.charAt(i), 0.0);
    }
    for (Character character : characterFrequency.keySet()) {
        characterFrequency.put(character, 1.0 / characterFrequency.size());
    }
    return characterFrequency;
}

Gdybym tak to zrobił, miałbym zaliczony test 3, 4 i 5.

4. Ingorujemy małe i wielkie znaki. Najprostsze rozwiązanie? Na całym wejściowym stringu robimy .toLowerCase().

@Override
public Map<Character, Double> analyze(String text) {
    Map<Character, Double> characterFrequency = new HashMap<>();
    text = text.toLowerCase();
    ...
}

Testy 6 i 7 zaliczone.

5. Ostatni test do zaliczenia. Bardzo prosty – wystarczy dodać obsługę wartości nullowej na wejściu. Końcowo nasza implementacja wygląda tak:

@Override
public Map<Character, Double> analyze(String text) {
    if (text == null) {
        throw new IllegalArgumentException();
    }
    Map<Character, Double> characterFrequency = new HashMap<>();
    text = text.toLowerCase();
    char[] chars = text.toCharArray();
    for (int i = 0; i < chars.length; i++) {
        characterFrequency.putIfAbsent(text.charAt(i), 0.0);
    }
    for (Character character : characterFrequency.keySet()) {
        characterFrequency.put(character, 1.0 / characterFrequency.size());
    }
    return characterFrequency;
}

Wszystkie testy przechodzą. Zadanie zaliczone. I tutaj każdy kto pracuje z TDD powinien powiedzieć hola hola amigos !! Chyba brakuje jeszcze jakiejś fazy. Właściwie to powinna ona być robiona po każdym z zaliczonych testów – tzn. refactoring. Niestety na rozmowie nie udało mi się dojść do tego etapu, jednak tutaj zaprezentuję rozwiązanie jakie byłbym w stanie wrzucić na review gdybym mógł pomyśleć o tym zadaniu na chłodno.

Ostateczne rozwiązanie: (gist)

@Override
public Map<Character, Double> analyze(String text) {
    if (text == null) {
        throw new IllegalArgumentException();
    }
    text = text.toLowerCase();
    Map<Character, Double> characterFrequency = new HashMap<>();
    long distintChars = text.chars().distinct().count();
    for (Character character: text.toCharArray()) {
        characterFrequency.putIfAbsent(character, 1.0 / distintChars);
    }
    return characterFrequency;
}

Tak to wyglądało. Trudne, łatwe? Powiedziałbym – takie przeciętne. Myślę, że w tym zadaniu chodziło o sprawdzenie kilku aspektów:

1. Znajomość i umiejętność pracy z TDD
2. Znajomość API Javy
3. Umiejętność logicznego myślenia
4. Radzenie sobie ze stresem

Daj znać w komentarzu co byś napisał inaczej (jak wyglądałoby Twoje ostateczne rozwiązanie)? A może sam czasem przeprowadzasz rozmowy rekrutacyjne to co byś dodał do tego zadania? Z chęcią będę aktualizował ten post – a nóż widelec może przyda Ci się to zadanko przy prowadzeniu przyszłej rozmowy rekrutacyjnej…

Tyle na dziś. Dzięki bardzo za przeczytanie. Za tydzień – standardowo, w sobotę o 12 –  obsługa VIMa dla każdego. Czyli w 5 minut naucz się tego dziwnego edytora!

Artykuł Zadanie rekrutacyjne 🤫 [MID] – TDD 🤷‍♂️❓ pochodzi z serwisu bdabek.pl.

Jeszcze słowo odnośnie nietechnicznych aspektów. Rozmowa była prowadzona przez 2 developerów (tech leadów) i trwała około 2 godzin. Zaoferowali mi całkiem fajną ofertę ale niestety nie godzili się na pracę zdalną w 100% więc się nie dogadaliśmy.

Z tej rozmowy na bloga chcę przelać jedno z ciekawszych pytań jakie padło i jedno zadanie jakie musiałem wykonać robiąc live-coding (btw. poległem na tym zadaniu bardzo bardzo…). Pytanie opiszę w tym artykule a zadanie pojawi się za dwa tygodnie w sobotę.

Ok… o co chodzi z tym pytaniem? Prymitywy-Wrappery-Obiekty . Miałem przedstawiony następujący kawałek kodu

public class Decrementer {
    private void decrement(double x) {
        x = x - 1.0;
    }
    public static void main(String[] args) {
        double x = 12.3;
        Decrementer decrementer = new Decrementer();
        decrementer.decrement(x);
        System.out.println(x);
    }
}

I dostałem pytanie: Co zostanie wypisane na ekranie?

• a) 12.3
• b) 0
• c) 11.3

Pytanie raczej z gatunków proste – btw. zanim przeczytasz dalej, sam na nie odpowiedz (albo napisz w komentarzu, żeby dać mi satysfakcję że nie piszę do ściany). Szybka analiza kodu i wiedza, że Java działa pass-by-value daje nam oczywiście odpowiedź a) 12.3.

A teraz pytanie co się stanie jak kod zmienimy w następujący sposób? (zmiana prymitywów na Double)

public class Decrementer {
    private void decrement(Double x) {
        x = x - 1.0;
    }
    public static void main(String[] args) {
        Double x = 12.3;
        Decrementer decrementer = new Decrementer();
        decrementer.decrement(x);
        System.out.println(x);
    }
}

Java działa pass-by-value ale jeżeli przesyłamy obiekt i modyfikujemy coś w nim (najczęściej przez settery) to stan obiektu powinien się zmienić nawet po wyściu z metody, tak? To takie trochę pytanie retoryczne bo odpowiedź brzmi TAK. Więc co teraz? Jaka będzie odpowiedź? …. <chwilka na namysł>. Ponownie prawidłową odpowiedzią jest a) 12.3. Dlaczego? Jeżeli nie wiesz (ja się na tym wywaliłem, bo nie wiedziałem co tak naprawdę robi wrapper double’a) to spójrz na linię 3. Nie używamy tu żadnego setter’a do zmiany stanu obiektu, używamy tylko znaku przypisania =. Ba… więcej. Zajrzyjmy do klasy Double i zobaczmy jakie metody są tu dostępne.

Widzisz jakieś metody do zmiany stanu wewnętrznej zmiennej (value)? Raczej nie i nie szukaj bo nie znajdziesz. Wszystkie wrappery zostały celowo zaprojektowane tak aby nie dało się zmienić ich stanu wewnętrznego. Dlaczego? Taką decyzję projektową podjęły osoby, które to implementowały – nie ma na to jasnej odpowiedzi. Jednym z plusów takiego rozwiązania jest na pewno to, że możemy działać bezpiecznie z wieloma wątkami dzięki temu, że klasa jest niemutowalna. Więc co tak naprawdę się stało, że mimo wszystko przypisanie do zmiennej x, która była typu Double zadziałało wewnątrz metody i że po wyjściu z tej metody mieliśmy tę samą wartość co poprzednio? <Dzięki Cepewka> Zadziałał tu wcześniej wspominany mechanizm pass-by-value i bardzo polecam prześledzić sobie dokładnie tą odpowiedź na stackoverflow, która fajnie obrazkowo pokazuje dlaczego to działa właśnie w ten sposób. I nie ma to znaczenia czy prześlemy tu obiekt wrapujący czy jakikolwiek inny. Autoboxing i Unboxing, czyli automatyczna konwersja, której dokonuje kompilator Javy dzięki czemu my – developerzy – mamy czystszy kod. Dla bardziej dociekliwych – oto jak wygląda byte code metody decrement

0 aload_1
 1 invokevirtual #2 <java/lang/Double.doubleValue>
 4 dconst_1
 5 dsub
 6 invokestatic #3 <java/lang/Double.valueOf>
 9 astore_1
10 return

To co nas interesuje to linie 1 (unboxing) i linia 6 (autoboxing). Jak widzisz pomimo tego, że wysyłaliśmy Double’a to jednak kompilator pod spodem robi trochę niewidocznej roboty… Nasza wartość została na początku skonwertowana do typu prymitywnego (java/lang/Double.doubleValue), następnie została wykonana operacja odejmowania i z powrotem dostajemy klasę wrapującą (java/lang/Double.valueOf). Myślę, że warto wiedzieć takie rzeczy… prędziej lub później (w moim przypadku później :D) :).

Jeżeli chodzi o pytania z rozmowy odnośnie tego zagadnienia to właściwie na tym się skończyło. Po tym jak poległem z brakiem mojej wiedzy o klasach wrapujących, myślę, że rekruterzy nie do końca chcieli ciągnąć ten wagonik. Jednak wydaje mi się, że mogłoby tu się pojawić pytanie, co zrobić, żeby móc zmodyfikować stan tego obiektu. I można tu udzielić dwóch odpowiedzi. Pierwsza to oczywiście zwracać wartość z metody i przypisywać ją do nowej zmiennej. Druga opcja to dodanie pola do klasy Decrement przechowującego wartość i modyfikowanie tego pola w ramach metody decrement a następnie odwoływanie się do niego w metodzie wypisującej wynik na ekran (tylko trzeba pamiętać, że to już nie jest thread-safe). O coś takiego

public class Decrementer {
    Double x;
    private void decrement(Double x) {
        this.x = x - 1.0;
    }
    public static void main(String[] args) {
        Double x = 12.3;
        Decrementer decrementer = new Decrementer();
        decrementer.decrement(x);
        System.out.println(decrementer.x);
    }
}

To na tyle w tym tygodniu :). Dzięki za przeczytanie i standardowo zapraszam za tydzień o 12:00 (sobota), gdzie pojawi się wpis o najbardziej przydatnych (moim zdaniem) skrótach klawiszowych do IntelliJ.

Artykuł Pytania rekrutacyjne 🤫 [MID] – Prymitywy-Wrappery-Obiekty 🤷‍♂️❓ pochodzi z serwisu bdabek.pl.