Why order does not matter

A subsequence can pick any elements as long as their relative order is kept. Whether a set of chosen values is harmonious depends only on which values you chose, not where they sit. So the best harmonious subsequence for a pair of values x and x + 1 simply takes every occurrence of both.

The counting solution

from collections import Counter

def find_lhs(nums):
    count = Counter(nums)
    best = 0
    for x, c in count.items():
        if x + 1 in count:
            best = max(best, c + count[x + 1])
    return best

Time O(n), space O(k) for k distinct values. Checking only x + 1 (not also x - 1) is enough, because every valid pair is seen from its smaller member.

The detail people miss

If every value is the same, the answer is 0, not the array length. Max minus min must be exactly 1, and a constant array has difference 0. The if x + 1 in count guard handles this for free, which is worth pointing out.

Sorting alternative

Sort, then slide two pointers so that nums[right] - nums[left] <= 1, recording the window length only when the difference is exactly 1. It is O(n log n) and uses less extra memory, a fair trade-off to mention if the interviewer asks about space.

Related questions

• Longest Consecutive Sequence uses the same "look up the neighbour value in a set" move.
• Contains Duplicate II and Degree of an Array also turn a positional question into frequency bookkeeping.

Disclosure: I work on Linkjob AI. If you want practice for coding rounds like this, an AI coding interview assistant can give real-time hints.

Easy version: copy to an array

Push every value into a list and compare it with its reverse. That's O(n) time and O(n) space. Say it first, then offer the O(1)-space version, because that's what most interviewers are waiting for.

O(1) space: middle, reverse, compare

1. Use slow and fast pointers to find the middle.
2. Reverse the second half in place.
3. Walk both halves together and compare values.
4. Reverse the second half back so the caller's list is unchanged.

def isPalindrome(head):
    slow = fast = head
    while fast and fast.next:
        slow, fast = slow.next, fast.next.next

    prev = None
    cur = slow
    while cur:
        cur.next, prev, cur = prev, cur, cur.next

    left, right, ok = head, prev, True
    while right:
        if left.val != right.val:
            ok = False
            break
        left, right = left.next, right.next

    # restore the list
    cur, back = prev, None
    while cur:
        cur.next, back, cur = back, cur, cur.next
    return ok

Time O(n), extra space O(1).

Points worth saying out loud

• For odd lengths, the middle node ends up in the reversed half, and it compares harmlessly with itself.
• Restoring the list is a nice touch: mutating input without asking is a common critique.
• The recursive "compare on the way back" trick also works, but it uses O(n) stack space.

Common bugs

• Losing the next pointer while reversing (assign it before overwriting).
• Comparing until left is None instead of until right is None.
• Forgetting the empty and single-node cases (both are palindromes).

Practice tip

Linked list questions punish small pointer mistakes, so practice narrating each step. For mock runs with live feedback, you can try Linkjob AI. Disclosure: I work on Linkjob AI.

Start with the problem it solves

Dijkstra's algorithm finds the shortest path from one source node to every other node in a weighted graph where all edge weights are non-negative. Say that constraint out loud. It shows you know when the algorithm is valid.

Explain the core idea in one breath

Keep a distance estimate for every node, initially infinity except the source at zero. Repeatedly pick the unvisited node with the smallest known distance, then relax its outgoing edges: if going through this node gives a shorter route to a neighbor, update that neighbor. Because weights are non-negative, once a node is picked its distance is final.

Mention the data structure

A min-heap (priority queue) is the key choice. With a binary heap and an adjacency list, the running time is O((V + E) log V). With a simple array it is O(V^2), which can still be better for very dense graphs. Interviewers love hearing you compare the two.

Call out the edge cases

• Negative edge weights break the greedy guarantee. Switch to Bellman-Ford.
• Unreachable nodes keep an infinite distance.
• Duplicate heap entries are fine if you skip stale ones when popped.
• To rebuild the actual path, store a parent pointer for each node.

Connect it to real systems

Mention routing, maps, and network latency. A concrete example shows you understand why the algorithm matters beyond the whiteboard.

Practice saying it

Knowing the algorithm is half the job; explaining it clearly under pressure is the other half. Rehearse with a friend or try an interview assistant powered by AI to practice talking through problems like this one and get feedback on your clarity.

Written by the AI Interview Copilot team.

The rules

• k[encoded] means repeat encoded exactly k times.
• k can have more than one digit (12[ab]).
• Brackets can nest to any depth.
• Plain letters outside brackets are copied as they are.

Say these out loud before coding. The multi-digit number is the detail most candidates miss.

Approach 1: two stacks

Keep the string you are building and the current number. When you see [, push both onto stacks and start fresh. When you see ], pop and combine.

def decode_string(s):
    counts, prefixes = [], []
    cur, num = [], 0
    for ch in s:
        if ch.isdigit():
            num = num * 10 + int(ch)
        elif ch == '[':
            counts.append(num)
            prefixes.append(cur)
            cur, num = [], 0
        elif ch == ']':
            k = counts.pop()
            cur = prefixes.pop() + cur * k
        else:
            cur.append(ch)
    return ''.join(cur)

Using a list of characters instead of string concatenation keeps the inner loop cheap in Python.

Approach 2: recursion with a shared index

Each call decodes until it hits a ] and returns what it built. The bracket structure maps directly onto the call stack, which some interviewers find easier to follow.

def decode_string(s):
    i = 0
    def helper():
        nonlocal i
        out, num = [], 0
        while i < len(s):
            ch = s[i]
            i += 1
            if ch.isdigit():
                num = num * 10 + int(ch)
            elif ch == '[':
                inner = helper()
                out.append(inner * num)
                num = 0
            elif ch == ']':
                return ''.join(out)
            else:
                out.append(ch)
        return ''.join(out)
    return helper()

Complexity

Both run in time proportional to the length of the output, since every output character is written at least once. Space is the output plus the nesting depth. If the interviewer asks about adversarial input like 100[100[100[a]]], point out the output is a million characters and no algorithm can beat writing it.

Test cases worth saying out loud

• 3[a]2[bc] gives aaabcbc (siblings)
• 3[a2[c]] gives accaccacc (nesting)
• 2[abc]3[cd]ef gives abcabccdcdcdef (trailing letters)
• 10[a] (multi-digit count)
• abc (no brackets at all)

Follow-ups

• Validate the input first? Use a counter for brackets and reject a digit not followed by [.
• Stream the output? The recursive version can yield chunks instead of building a whole string.
• Encode instead of decode? That becomes an interval DP problem and is much harder; say so honestly.

If you practice these patterns and want help while you work through timed online assessments, the Linkjob AI interview copilot gives real-time hints during coding rounds.

Disclosure: I'm part of the team at Linkjob AI. These notes are general interview prep.

Naive matching and its worst case

Slide the pattern over the text and compare character by character. On inputs like text aaaaaaaab and pattern aaab, each alignment re-checks almost the whole pattern, so the cost is O(n·m). That repeated work is what both algorithms remove.

KMP: never re-read the text

KMP precomputes, for each prefix of the pattern, the length of the longest proper prefix that is also a suffix (the "LPS" or failure array). When a mismatch happens, you jump the pattern forward using that array instead of moving the text pointer back.

def build_lps(p):
    lps = [0] * len(p)
    k = 0
    for i in range(1, len(p)):
        while k and p[i] != p[k]:
            k = lps[k - 1]
        if p[i] == p[k]:
            k += 1
        lps[i] = k
    return lps

def kmp_search(text, p):
    lps, k, hits = build_lps(p), 0, []
    for i, c in enumerate(text):
        while k and c != p[k]:
            k = lps[k - 1]
        if c == p[k]:
            k += 1
        if k == len(p):
            hits.append(i - k + 1)
            k = lps[k - 1]
    return hits

O(n + m) time, O(m) extra space. The text pointer only moves forward, which is the sentence to say in the interview.

Rabin-Karp: compare hashes, not strings

Keep a rolling hash of the current window. Moving the window one step removes the outgoing character and adds the incoming one in O(1). Only when the hash matches the pattern's hash do you compare the actual characters, which guards against collisions.

• Expected O(n + m), worst case O(n·m) with many collisions.
• Use a large prime modulus; mention double hashing if the interviewer pushes on collisions.
• It shines when you search for many patterns of the same length or need repeated substrings (Longest Duplicate Substring combines it with binary search on length).

Which one to pick

Problems that are secretly LPS problems

• Repeated Substring Pattern: s is built from a repeated block if n % (n - lps[-1]) == 0 and lps[-1] > 0.
• Shortest Palindrome: build s + '#' + reverse(s) and read the last LPS value.
• Find the Index of the First Occurrence: the textbook KMP use.

Talking through it

Write the naive version's worst case on the board first, then explain what information a mismatch already gives you. Interviewers care more about that reasoning than about remembering the LPS loop perfectly, so trace build_lps("aabaaab") by hand to show you understand it.

Disclosure: I work on Linkjob AI copilot, an AI assistant for live coding and technical interviews. The material above is a standalone study guide.

면접관이 실제로 보는 것

케이스 면접에서 평가하는 요소는 대체로 다음과 같습니다.

• 문제 정의: 질문의 핵심이 무엇인지 정확히 파악하는가
• 구조화: 문제를 빠짐없이, 겹치지 않게 나눌 수 있는가
• 가설 설정과 검증: 근거를 바탕으로 가설을 세우고 필요한 정보를 요청하는가
• 커뮤니케이션: 생각의 흐름을 상대가 이해하기 쉽게 설명하는가

즉, 최종 결론이 조금 달라도 과정이 논리적이면 좋은 평가를 받을 수 있습니다.

기본 진행 순서

1. 질문을 다시 확인하기. 들은 내용을 자신의 말로 요약하고, 궁금한 점을 질문합니다. "매출 감소가 전 매장에서 나타나는지, 특정 지역에서만 나타나는지 알 수 있을까요?" 같은 질문은 문제 범위를 좁히는 데 도움이 됩니다.

2. 생각할 시간 요청하기. "30초 정도 정리할 시간을 주셔도 될까요?"라고 말하는 것은 전혀 감점 요인이 아닙니다. 오히려 바로 말하기 시작해 횡설수설하는 것보다 훨씬 낫습니다.

3. 틀을 제시하기. 매출 문제라면 '매출 = 고객 수 × 객단가'로 나누고, 고객 수는 다시 신규 고객과 기존 고객으로 나눠 볼 수 있습니다. 이렇게 틀을 먼저 보여 주면 면접관도 지원자의 접근 방향을 이해하기 쉽습니다.

4. 가설을 세우고 데이터를 요청하기. "최근 근처에 경쟁 매장이 생겨 기존 고객이 이탈했을 가능성이 있다고 봅니다. 고객 수 변화 데이터를 확인할 수 있을까요?"처럼 구체적으로 묻습니다.

5. 결론과 제안 정리하기. 마지막에는 핵심 원인과 실행 가능한 대책, 그리고 추가로 확인해야 할 리스크를 짧게 정리합니다.

자주 하는 실수

• 틀을 외워서 문제와 상관없이 그대로 적용하는 것
• 계산 문제에서 단위를 놓치거나 검산하지 않는 것
• 면접관이 주는 힌트를 흘려듣는 것
• 혼자 오래 생각하며 침묵하는 것

특히 면접관의 힌트는 방향을 바꾸라는 신호인 경우가 많으니, 귀 기울여 듣고 유연하게 반영하는 태도가 중요합니다.

효과적인 연습 방법

케이스 면접은 혼자 책을 읽는 것만으로는 실력이 잘 늘지 않습니다. 스터디원과 번갈아 면접관 역할을 맡아 실제처럼 진행하고, 끝난 뒤에는 구조화가 적절했는지 서로 피드백을 주는 것이 좋습니다. 연습 상대를 구하기 어렵다면 AI 면접 코파일럿을 활용해 다양한 케이스 질문을 받아 보고, 자신의 답변 흐름을 점검해 보는 것도 방법입니다. Linkjob AI 같은 도구는 연습 후 답변을 다시 정리하는 데에도 도움이 됩니다.

평소에는 일상 속 비즈니스 현상을 케이스처럼 생각해 보는 습관을 들여 보세요. 동네 가게가 왜 문을 닫았는지, 새로 생긴 서비스는 어떻게 돈을 버는지 스스로 질문하고 구조를 세워 보는 것만으로도 좋은 훈련이 됩니다.

마치며

케이스 면접은 처음에는 어렵게 느껴지지만, 접근 방식을 익히고 충분히 연습하면 오히려 자신의 사고력을 보여 줄 수 있는 좋은 기회가 됩니다. 정답을 맞히려 하기보다, 면접관과 함께 문제를 풀어 가는 동료처럼 대화하는 것을 목표로 해 보세요.

Czemu służą pytania stresowe?

Rekruter zazwyczaj nie chce nikogo upokorzyć. Celem jest sprawdzenie, jak reagujesz na presję, krytykę lub niespodziewaną sytuację. Dotyczy to szczególnie stanowisk, na których kontakt z wymagającym klientem, negocjacje czy szybkie decyzje są częścią pracy. Liczy się nie tyle sama treść odpowiedzi, co sposób, w jaki do niej dochodzisz: czy zachowujesz spokój, czy potrafisz uporządkować myśli i czy nie przechodzisz do defensywy.

Najczęstsze rodzaje pytań stresowych

• Podważanie kompetencji: „Nie wydaje mi się, żeby pani doświadczenie wystarczyło na to stanowisko”.
• Pytania niewygodne: „Dlaczego tak krótko pracował pan w poprzedniej firmie?”
• Pytania nietypowe lub absurdalne: „Ile okien jest w Warszawie?”
• Presja czasu: „Ma pan 30 sekund, żeby mnie przekonać”.
• Celowe milczenie po twojej odpowiedzi, które ma sprowokować do dalszego tłumaczenia się.

Jak reagować krok po kroku

1. Zatrzymaj się na chwilę. Kilka sekund przerwy na zebranie myśli jest w pełni akceptowalne. Możesz powiedzieć: „Dobre pytanie, zastanowię się przez moment”.

2. Nie bierz tego do siebie. Pamiętaj, że to element procesu, a nie ocena twojej osoby. Ton głosu spokojny, bez irytacji i bez nadmiernych przeprosin.

3. Odpowiedz rzeczowo. Na zarzut braku doświadczenia możesz odpowiedzieć konkretnym przykładem: „Rozumiem tę wątpliwość. W ostatnim roku samodzielnie prowadziłem projekt wdrożenia nowego systemu dla dwóch działów, więc znam podobną skalę odpowiedzialności”.

4. Przy pytaniach nietypowych pokaż tok myślenia. W przypadku pytań typu „ile okien jest w Warszawie” nikt nie oczekuje dokładnej liczby. Chodzi o to, czy potrafisz rozbić problem na mniejsze części i przyjąć rozsądne założenia. Mów na głos, jak liczysz.

5. Wytrzymaj ciszę. Jeśli po twojej odpowiedzi zapada milczenie, nie musisz go wypełniać. Możesz spokojnie zapytać: „Czy chciałby pan, żebym coś doprecyzował?”

Gdzie leży granica?

Pytania stresowe to jedno, a pytania niezgodne z prawem lub naruszające godność to coś zupełnie innego. Pytania o plany rodzinne, wyznanie czy stan zdrowia niezwiązany z pracą nie powinny paść. Masz prawo grzecznie odmówić odpowiedzi. Sposób prowadzenia rozmowy też jest dla ciebie informacją o kulturze organizacyjnej firmy.

Przygotowanie zmniejsza stres

Najlepszym sposobem na pytania stresowe jest oswojenie się z nimi wcześniej. Spisz kilka trudnych pytań, które mogłyby paść w twoim przypadku, na przykład o przerwy w CV czy częste zmiany pracy, i przećwicz odpowiedzi na głos. Możesz poprosić znajomego, by celowo był wobec ciebie nieco chłodniejszy, albo skorzystać z narzędzia takiego jak Linkjob AI, które pomaga symulować rozmowę i przeanalizować, czy twoje odpowiedzi brzmią pewnie i konkretnie.

Podsumowanie

Pytanie stresowe trwa zwykle kilkanaście sekund, ale może zostawić mocne wrażenie, zarówno pozytywne, jak i negatywne. Spokój, konkret i umiejętność przyznania się do niewiedzy bez utraty pewności siebie to najlepsza odpowiedź na presję. Właśnie te cechy rekruter chce zobaczyć.

Che cosa cercano davvero i selezionatori

Per uno stage le competenze tecniche contano, ma raramente sono decisive. Le aziende guardano soprattutto a:

• motivazione: perché proprio questo settore e questa azienda;
• capacità di apprendimento: come affronti argomenti nuovi;
• affidabilità: puntualità, organizzazione, rispetto delle scadenze;
• attitudine al lavoro di squadra: come ti comporti con colleghi e responsabili.

Tutte queste qualità si possono dimostrare anche senza un lavoro vero e proprio alle spalle.

Trasforma l'esperienza universitaria in esempi concreti

Progetti di gruppo, tesi, lavori part-time, volontariato, associazioni studentesche, periodi all'estero con l'Erasmus: sono tutte fonti di esempi utili. Se ti chiedono come gestisci una scadenza stretta, puoi raccontare come hai organizzato il lavoro di un progetto d'esame con altri tre compagni. Se ti chiedono di un conflitto, può andare bene anche una divergenza nata in un gruppo di studio.

L'importante è essere specifici: qual era la situazione, che cosa hai fatto tu personalmente e che cosa hai imparato.

Studia l'azienda (e il tirocinio)

Leggi con attenzione l'annuncio e il sito aziendale. Cerca di capire in quale ufficio lavorerai, con quali strumenti e su quali progetti. Durante il colloquio, collegare la tua formazione alle attività dello stage fa una grande differenza: «Nel corso di marketing digitale ho usato Google Analytics per un progetto, quindi mi piacerebbe approfondirlo nel vostro team».

Informati anche sugli aspetti pratici, come durata, rimborso spese e possibilità di inserimento al termine del tirocinio, ma lascia queste domande alla parte finale del colloquio.

Le domande più frequenti

Preparati a rispondere in modo naturale ad alcune domande classiche:

1. «Mi parli di lei»: una presentazione di un minuto su studi, interessi e motivazione.
2. «Perché ha scelto questo stage?»
3. «Quali sono i suoi obiettivi nei prossimi anni?»
4. «Come si organizza quando deve conciliare più impegni?»

Non serve imparare le risposte a memoria; basta avere chiari i punti principali. Provare a voce alta aiuta molto: puoi esercitarti con un amico oppure con un assistente IA per colloqui, che ti propone domande simili a quelle reali e ti aiuta a capire se le tue risposte sono troppo lunghe o vaghe.

Fai domande anche tu

Alla fine del colloquio arriva quasi sempre il momento di «Ha qualche domanda?». Approfittane. Puoi chiedere com'è una giornata tipo per il tirocinante, chi sarà il tuo tutor o quali competenze si aspettano che tu sviluppi. Sono domande che mostrano interesse per la crescita, che è proprio ciò che uno stage dovrebbe offrire.

Un ultimo consiglio

Non cercare di sembrare più esperto di quello che sei. L'onestà sui propri limiti, unita alla voglia di imparare, è spesso più convincente di un elenco di competenze gonfiate. Presentati per quello che sei, uno studente o un neolaureato pronto a mettersi in gioco, e lascia che la tua preparazione parli per te.

Entenda o formato antes de estudar

Não adianta passar semanas resolvendo exercícios de algoritmos se a vaga vai avaliar, por exemplo, modelagem de banco de dados ou desenho de APIs. Pergunte ao recrutador como é a etapa técnica: duração, ferramentas usadas, se é individual ou em par, se pode consultar documentação. Essa informação é comum de ser compartilhada e muda completamente a forma de se preparar.

Alguns formatos frequentes:

• Live coding: resolver um problema em tempo real, compartilhando a tela ou em um editor online.
• Desafio para casa: um projeto pequeno com prazo de alguns dias, seguido de uma conversa sobre as decisões tomadas.
• System design: desenhar a solução de um sistema em alto nível, comum para vagas plenas e seniores.
• Revisão de código: analisar um trecho e apontar problemas e melhorias.

Pense em voz alta

Este é o conselho mais importante para o live coding. Silêncio longo deixa o entrevistador sem saber se você está travado ou avançando. Antes de escrever qualquer linha, repita o problema com suas palavras, faça perguntas sobre os casos-limite e explique a abordagem que pretende usar. Algo como: "Minha primeira ideia é uma solução mais simples, que percorre a lista duas vezes. Depois posso tentar otimizar".

Começar por uma solução que funciona e depois melhorá-la é muito mais valorizado do que ficar paralisado tentando achar a resposta ideal de primeira.

Teste o próprio código

Depois de escrever a solução, percorra um exemplo manualmente, incluindo entradas vazias ou valores extremos. Encontrar e corrigir um bug por conta própria demonstra maturidade, e isso conta pontos.

Saiba falar dos seus projetos

Muitas entrevistas técnicas incluem perguntas sobre projetos anteriores. Escolha dois ou três que você domina e esteja pronto para explicar o problema, as alternativas consideradas, por que escolheu determinada tecnologia e o que faria diferente hoje. Falar sobre trade-offs com honestidade costuma impressionar mais do que listar ferramentas.

Quando não souber a resposta

Ninguém sabe tudo, e os entrevistadores sabem disso. Se não conhecer um conceito, diga com tranquilidade e mostre como chegaria à resposta: "Não trabalhei diretamente com isso, mas imagino que funcione de forma parecida com X, e eu verificaria na documentação". Inventar uma resposta costuma ser pior do que admitir a lacuna.

Pratique em condições parecidas com as reais

Resolver exercícios sozinho em silêncio é diferente de resolver com alguém observando. Treine explicando em voz alta, cronometrando o tempo e, se possível, com outra pessoa no papel de entrevistador. Há também ferramentas de ajuda em tempo real com IA na entrevista que ajudam a organizar o raciocínio e a revisar suas respostas depois das simulações, o que facilita perceber onde você costuma travar.

Para fechar

A entrevista técnica não é uma prova de memória, e sim uma amostra de como seria trabalhar com você. Comunicação clara, curiosidade e capacidade de lidar com o que não sabe pesam tanto quanto o conhecimento técnico. Prepare-se para mostrar essas qualidades, e o resultado tende a refletir melhor o profissional que você realmente é.

Comprendre ce qui se passe

Le stress déclenche une réaction physique : le cœur accélère, la respiration devient plus courte, l'attention se resserre. Dans une certaine mesure, cette tension est utile, car elle vous rend plus vif. Le problème apparaît quand elle déborde et vous empêche de penser clairement. L'objectif n'est donc pas de supprimer le trac, mais de le ramener à un niveau gérable.

Avant l'entretien : réduire l'incertitude

Une grande partie de l'anxiété vient de l'inconnu. Plus vous réduisez les zones floues, plus vous arrivez serein.

• Préparez la logistique la veille : adresse, itinéraire, tenue, lien de visioconférence testé, documents imprimés.
• Travaillez vos réponses clés sans les apprendre par cœur. Repérez cinq ou six situations professionnelles que vous pouvez raconter avec aisance ; elles serviront de base à la plupart des questions.
• Simulez l'entretien à voix haute. Répondre mentalement ne suffit pas. Demandez à un proche de jouer le recruteur, ou entraînez-vous avec un outil comme Linkjob AI, qui permet de répéter des questions réalistes et de repérer les moments où vous hésitez.
• Dormez correctement et évitez l'excès de café le matin même, qui accentue souvent la nervosité.

Juste avant d'entrer : calmer le corps

Quelques minutes avant l'entretien, la respiration est votre meilleur allié. Une technique simple consiste à inspirer par le nez pendant quatre secondes, retenir son souffle quatre secondes, puis expirer lentement pendant six secondes. Répétée quelques fois, elle aide à faire redescendre le rythme cardiaque.

Vous pouvez aussi relâcher volontairement les épaules et la mâchoire, deux zones où la tension s'accumule sans qu'on s'en rende compte. Enfin, remplacez le discours intérieur « je vais tout rater » par quelque chose de plus factuel : « je me suis préparé, je connais mon parcours ».

Pendant l'entretien : se donner du temps

Le trou noir arrive souvent parce qu'on croit devoir répondre instantanément. Ce n'est pas le cas. Vous avez le droit de dire : « Bonne question, laissez-moi réfléchir un instant. » Ces quelques secondes passent beaucoup plus inaperçues pour le recruteur que pour vous.

Si vous perdez le fil au milieu d'une réponse, reformulez la question ou résumez ce que vous venez de dire : cela vous remet sur les rails. Et si vous sentez que votre voix tremble, ralentissez délibérément votre débit. Parler plus lentement donne une impression d'assurance, même quand on n'en ressent pas.

Pour les entretiens en visio, certains candidats s'appuient sur un assistant d'entretien IA qui affiche quelques mots-clés en cas de blanc. Utilisé avec mesure, ce type d'outil peut rassurer, à condition de rester dans l'échange naturel avec votre interlocuteur.

Après l'entretien : faire le bilan sans se juger

Une fois l'entretien terminé, prenez quelques notes : quelles questions vous ont mis en difficulté, à quels moments vous vous êtes senti à l'aise. Ce retour d'expérience rend l'entretien suivant moins intimidant, parce que vous aurez déjà affronté des situations similaires.

Le trac diminue rarement d'un coup ; il s'apprivoise avec la pratique. Chaque entretien, même celui qui ne débouche pas sur une offre, vous entraîne à rester présent et clair sous pression. Et c'est précisément cette compétence que beaucoup de recruteurs cherchent à observer.

¿Cuándo enviarlo?

Lo ideal es enviarlo dentro de las 24 horas siguientes a la entrevista. Si la conversación fue por la mañana, puedes mandarlo esa misma tarde. Esperar varios días le quita sentido, porque para entonces el equipo quizá ya esté comparando candidatos. Si te entrevistaron varias personas, lo mejor es escribir un mensaje breve a cada una, con algún detalle distinto según lo que hablasteis.

La estructura que funciona

Un buen correo de agradecimiento cabe en cuatro o cinco frases. No necesitas más.

1. Agradecimiento concreto. En lugar de un "gracias por su tiempo" genérico, menciona algo específico: "Gracias por explicarme cómo está organizado el equipo de producto y los retos del próximo lanzamiento".
2. Conexión con el puesto. Relaciona ese detalle con tu experiencia: "Me motivó especialmente, porque en mi empleo actual coordiné un proceso parecido con tres equipos distintos".
3. Un matiz que quieras añadir (opcional). Si sentiste que una respuesta quedó incompleta, este es el lugar para completarla en una o dos líneas, sin volver a contar la entrevista entera.
4. Cierre con interés. "Sigo muy interesado en el puesto y quedo a su disposición para cualquier información adicional".

Un ejemplo breve

Asunto: Gracias por la entrevista – Puesto de Analista de Marketing

Hola, Laura:

Muchas gracias por la conversación de hoy. Me resultó muy interesante conocer cómo estáis replanteando la estrategia de contenidos para el mercado latinoamericano. En mi puesto actual he trabajado en la adaptación de campañas para distintos países, así que me encantaría aportar esa experiencia al equipo.

Quedo atento a los próximos pasos. ¡Un saludo!

Adapta el tono al de la empresa: en una startup puedes tutear y ser más cercano; en un despacho o una entidad pública, mejor mantener el "usted".

Errores que conviene evitar

• Copiar y pegar la misma plantilla para todos los entrevistadores. Se nota, sobre todo si se reenvían el correo entre ellos.
• Presionar por una respuesta. Preguntar "¿cuándo sabré algo?" en este mensaje suena impaciente. Si no te dijeron plazos, puedes consultarlo más adelante en un seguimiento aparte.
• Faltas de ortografía o el nombre mal escrito. Revisa dos veces, porque un descuido aquí pesa más de lo que parece.
• Extenderte demasiado. Si tu correo necesita desplazarse en pantalla, es demasiado largo.

¿Y si no responden?

Si pasa el plazo que te indicaron y no hay noticias, es razonable enviar un segundo mensaje breve unos días después, preguntando con amabilidad si hay novedades sobre el proceso. Más allá de eso, conviene seguir con otras candidaturas en paralelo.

Prepara también lo que viene antes

El correo de agradecimiento funciona mejor cuando la entrevista ya fue sólida. Para eso ayuda practicar tus respuestas con antelación y tener a mano tus ejemplos clave. Algunas personas utilizan un copiloto de entrevistas con IA para ordenar sus ideas durante la preparación y, después, apuntar los temas concretos que surgieron y que pueden mencionar en el mensaje.

Al final, un buen agradecimiento no te consigue el puesto por sí solo, pero sí transmite algo que los reclutadores valoran mucho: que eres una persona atenta, organizada y con interés real. Y eso, en una decisión ajustada, puede marcar la diferencia.

ماذا يريد مسؤول التوظيف أن يسمع؟

ابدأ بفهم دور الشخص الذي يتصل بك. غالبًا لديه قائمة أسئلة ثابتة يطرحها على جميع المرشحين، ويقارن الإجابات بسرعة. لذلك فإن الإجابة المركّزة أفضل بكثير من الحديث المطوّل. من الأسئلة الشائعة:

• حدّثني باختصار عن خبرتك الحالية.
• لماذا تبحث عن فرصة جديدة الآن؟
• ما الذي لفت انتباهك في هذه الوظيفة؟
• ما هو موعد توفرك للبدء؟
• هل لديك توقعات مبدئية بشأن الراتب؟

جهّز لكل سؤال إجابة من ثلاث إلى أربع جمل، واربطها دائمًا بما ورد في إعلان الوظيفة. إذا كان الإعلان يركّز على إدارة المشاريع مثلًا، فاذكر مشروعًا محددًا قدته وما تحقق فيه.

جهّز بيئتك قبل الرنين

لأن المكالمة صوتية فقط، يصبح صوتك هو كل ما يملكه المحاور للحكم عليك. اختر مكانًا هادئًا، واشحن هاتفك، وتأكد من قوة الإشارة. ضع أمامك نسخة من سيرتك الذاتية وإعلان الوظيفة وورقة صغيرة فيها أهم ثلاث نقاط تريد إيصالها. هذه ميزة لا تتوفر في المقابلة الحضورية، فاستفد منها دون أن تقرأ حرفيًا.

نصيحة عملية: قف أو اجلس منتصب الظهر أثناء الحديث، وابتسم. قد يبدو ذلك غريبًا في مكالمة لا يراك فيها أحد، لكن نبرة الصوت تتأثر بوضعية الجسد بشكل ملحوظ.

تعامل بذكاء مع سؤال الراتب

يُطرح سؤال الراتب كثيرًا في هذه المرحلة المبكرة. إن لم تكن مستعدًا لذكر رقم، يمكنك أن تقول إنك تودّ معرفة المزيد عن مسؤوليات الدور أولًا، ثم تسأل عن النطاق المخصص للوظيفة. وإن كنت مضطرًا لذكر رقم، فقدّم نطاقًا مبنيًا على بحث مسبق في سوق العمل في بلدك وتخصصك، لا رقمًا عشوائيًا.

لا تنسَ أن تسأل أنت أيضًا

في نهاية المكالمة ستُسأل عادة إن كان لديك أي استفسار. اغتنم الفرصة لتسأل عن خطوات العملية التالية وعدد المقابلات المتوقعة ومن ستقابل. هذه الأسئلة العملية تُظهر جديتك وتساعدك على التخطيط.

التدريب يصنع الفرق

أفضل طريقة لتقليل التوتر هي أن تسمع نفسك وأنت تجيب. سجّل إجاباتك على الأسئلة الشائعة واستمع إليها: هل هي طويلة؟ هل تكرر كلمات مثل "يعني" و"في الحقيقة"؟ يمكنك أيضًا الاستعانة بأداة مثل Linkjob AI لمراجعة صياغة إجاباتك قبل الموعد، أو استخدام مساعد مقابلات بالذكاء الاصطناعي يقترح عليك نقاطًا مختصرة حين تتشتت أفكارك.

بعد انتهاء المكالمة

دوّن فورًا ما دار في الحديث: اسم المتصل، والمعلومات التي حصلت عليها عن الفريق، والخطوة التالية المتفق عليها. ثم أرسل رسالة شكر قصيرة خلال يوم واحد تؤكد فيها اهتمامك بالوظيفة. قد تبدو هذه التفاصيل صغيرة، لكنها تترك انطباعًا مهنيًا يميزك عن مرشحين كثيرين يملكون المؤهلات نفسها.

المكالمة الهاتفية الأولى ليست امتحانًا صعبًا، بل محادثة تحتاج إلى وضوح وتحضير. إذا دخلتها وأنت تعرف ما تريد قوله ولماذا تناسبك هذه الوظيفة، فأنت قد قطعت نصف الطريق.

先調整心態：空窗期不是汙點

很多求職者一被問到空窗期就開始解釋、道歉，甚至越講越心虛。這種反應反而會讓面試官更在意。先告訴自己：職涯本來就不是一條直線，重點是你怎麼說明它，以及你從中帶走了什麼。

說明的三段式結構

建議用「原因、收穫、現況」三個部分來回答，整體控制在一分鐘左右。

一、簡短交代原因。 一兩句話說清楚就好，不需要交代所有細節。例如：「前一份工作結束後，我花了大約八個月照顧住院的家人。」涉及健康或家庭隱私時，點到為止即可，你沒有義務說得太深入。

二、具體說出收穫。 這是最關鍵的部分。想一想這段時間你做了哪些事：上了線上課程、考了證照、接過零星案子、參與志工活動，或是自學了新的工具。即使是照顧家人，也可能鍛鍊了時間管理與溝通協調的能力。重點是要具體，例如「完成了資料分析的線上課程，並用公開資料做了兩個小專案」，會比「我有持續學習」更有說服力。

三、回到現在與未來。 最後把話題拉回這份職缺：「現在家裡的狀況已經穩定，我也確定想回到行銷領域，而貴公司這個職位正好能讓我發揮過去的經驗。」這樣收尾，面試官的注意力就會從「過去發生什麼」轉到「你能帶來什麼」。

常見的地雷說法

• 過度負面： 例如抱怨前公司或景氣，容易讓人覺得你把問題都推給外在環境。
• 前後不一致： 履歷上的時間和口頭說明對不上，會直接影響信任感。面試前請再核對一次日期。
• 含糊帶過： 「就休息一下」如果沒有下文，會讓人猜測你是不是缺乏動力。

在履歷上也可以先處理

如果空窗期超過半年，不妨在履歷上用一行簡短說明，例如「2025.03–2025.11 家庭照護期間，自學 Python 並取得相關證照」。主動交代比等面試官發問更從容，也能讓面試時的對話更順。

事先演練，讓說法更自然

這類問題最怕臨場卡住，所以建議先寫下你的版本，再大聲練習幾次，直到能用自己的話說出來，而不是背稿。你可以找朋友扮演面試官，或是利用 AI 面試助手 模擬提問，看看自己的回答是否太長、是否有防衛感。熟練之後，你會發現這個問題其實只是面試中很普通的一題。

結語

空窗期本身不會決定面試結果，真正有影響的是你如何面對它。誠實、簡潔、帶出成長，再把焦點放回你對這份工作的準備，面試官看到的就會是一個清楚知道自己要什麼的人，而不是一段履歷上的空白。

Recognize the shape

Greedy tends to fit when the problem asks for a maximum or minimum count and you can sort by one key: interval scheduling (sort by end time), jump game (track the farthest reach), assigning cookies or boats (sort both sides, use two pointers), and gas station (reset the start when the tank goes negative).

Say the exchange argument out loud

You don't need a formal proof. One sentence is enough: "Suppose an optimal answer picks a different first interval. Swapping it for the one that ends earliest never makes things worse, so picking the earliest end is safe." Interviewers mostly want to see that you checked.

Try a counterexample first

Before coding, spend thirty seconds trying to break your greedy rule. Coin change with coins 1, 3, 4 and target 6 breaks "take the biggest coin first" (4+1+1 versus 3+3). If you find a counterexample, switch to dynamic programming and say why.

Template

def max_non_overlapping(intervals):
    intervals.sort(key=lambda x: x[1])
    count, end = 0, float('-inf')
    for s, e in intervals:
        if s >= end:
            count += 1
            end = e
    return count

Practice prompts

Non-overlapping intervals, minimum arrows to burst balloons, jump game II, partition labels, task scheduler.

I'm on the team behind Linkjob AI, an AI assistant for technical interviews, and greedy questions are where we see candidates lose the most points by skipping the "why" step.

What interviewers are looking for

• Prioritization. Can you tell a correctness bug from a style nit, and say which matters more?
• Clear, kind feedback. Would your comments help a junior engineer, or make them defensive?
• Context questions. Do you ask what the code is for before judging it?
• Testing instinct. Do you notice missing tests and edge cases?

A simple review order

1. Read the description first. Say out loud what the change is supposed to do. If there is no description, ask.
2. Check correctness. Off-by-one errors, null or empty inputs, error handling, concurrency, and resource leaks.
3. Check security and data safety. Unvalidated input, SQL built from strings, secrets in code, logging personal data.
4. Check design. Is the logic in the right place? Is something duplicated that already exists?
5. Check tests. What is tested, and what obvious case is missing?
6. Only then, readability. Naming, long functions, comments.

How to phrase comments

Label severity so the author knows what blocks the merge:

• "Blocking: this loop skips the last element when n is even."
• "Suggestion: this could reuse parseDate() from utils."
• "Nit: tmp2 could be named retryCount."

Ask questions when you are unsure ("Is this called from multiple threads?") instead of stating guesses as facts. And mention one thing the author did well. Interviewers notice it.

Practice ideas

• Review open pull requests in a project you use and compare your notes with the maintainers' comments.
• Take an old piece of your own code and review it as if a stranger wrote it.
• Time-box yourself to 20 minutes, which is typical for this round.

Wrapping up

End your review with a short summary: "Two blocking issues, one around empty input and one SQL injection risk; the rest are suggestions. Overall the structure is easy to follow."

If you want to rehearse explaining your reasoning out loud, an AI assistant for technical interviews such as Linkjob AI can help you practise (disclosure: I work on Linkjob AI). The habit that matters most is the same either way: prioritize, explain, and stay constructive.

Days 1–2: Find your gaps, not your comfort zone

Do four timed problems (two arrays/strings, one graph or tree, one dynamic programming). Don't look anything up. Write down where you stalled: was it the idea, the edge cases, or the code itself? That list drives the next twelve days.

Days 3–7: Patterns over volume

Pick the five patterns that showed up as weak spots and do two or three problems each: sliding window, two pointers, BFS/DFS, binary search on the answer, and top-down DP are the usual suspects. After each problem, write one sentence describing the trigger that should have told you which pattern to use. Those sentences are worth more than the solutions.

Days 8–9: System design or project deep dive

If you're mid-level or above, sketch two designs out loud (a URL shortener and a news feed are fine). If you're earlier in your career, prepare to walk through one project in detail: the trade-offs you made, what broke, and what you'd change.

Days 10–11: Behavioral stories

Write six short STAR stories: a conflict, a failure, a win you're proud of, a time you led without authority, a tight deadline, and a time you changed your mind. Most behavioral questions map to one of these.

Days 12–13: Full mock interviews

Do at least two mocks under real conditions: camera on, a shared editor, and someone else asking the questions. Practice narrating your thinking before you type. Interviewers grade communication as heavily as the final code.

Day 14: Rest and logistics

Test your setup, re-read your pattern sentences, and stop early. Fatigue costs more points than one more problem earns.

Tools that help

A timer, a plain editor without autocomplete, and a friend for mocks cover most of it. If you want feedback while you practice answering out loud, an AI coding interview assistant can listen to the question and suggest structure in real time. (Disclosure: I work on Linkjob AI, so weigh that recommendation accordingly; the plan above works with or without it.)

Two focused weeks won't make you an expert, but they're enough to turn rusty into ready.

1. Don't bluff

Making something up is the fastest way to lose trust. Interviewers usually know the answer, and a confident wrong answer looks worse than an honest gap. Say it plainly: "I haven't worked with that directly."

2. Bridge to what you do know

Right after admitting the gap, connect it to something nearby. For example: "I haven't used Kafka in production, but I've built a queue-based pipeline with RabbitMQ. I'd expect the trade-offs around ordering and retries to be similar. Can I reason through it from there?" This turns a dead end into a signal about how you learn.

3. Think out loud

If it's a problem rather than a fact, narrate your reasoning:

• Restate the problem in your own words.
• Ask one or two clarifying questions about inputs, scale or constraints.
• Start with a brute-force idea and say why it's slow.
• Look for the bottleneck and try one improvement at a time.

Silence is the real failure mode. Even half-formed reasoning gives the interviewer something to score and a chance to nudge you.

4. Use hints well

When the interviewer gives a hint, take it, repeat it back, and show how it changes your approach. Taking a hint gracefully is a positive signal, since it's what working with teammates looks like.

5. Close the loop

If you still don't get there, summarise where you got to and what you'd look up next: "I'd check how the scheduler handles priority inversion; I suspect that's the missing piece." If it's natural, follow up after the interview with a short note showing you found the answer.

6. Practise being stuck

Most people only practise questions they can answer. Instead, pick topics you're weak on and do timed mock rounds out loud, recording yourself. You'll get comfortable saying "I don't know yet, here's how I'd find out."

For realistic practice against your own resume and target role, tools like Linkjob.ai can help you rehearse technical and behavioural rounds. (Disclosure: this post is written by the Linkjob AI team.) The habit matters more than the tool, though: be honest, bridge, and reason out loud.

Quick script

"I haven't used that directly. Here's what I know that's related... Let me reason through it. My first thought is... The trade-off there is... Is it fair to assume...?"

Being stuck is normal. Handling it calmly is one of the clearest signals you can give.

1. Clarify requirements (5 minutes)

Before drawing a single box, ask:

• Who are the users and what are the two or three core actions?
• Roughly how many users or requests per second?
• Is the workload read-heavy or write-heavy?
• What matters most: latency, consistency, or cost?

Write the answers down where the interviewer can see them. It shows you design for a goal rather than for a buzzword.

2. Do a back-of-the-envelope estimate (3 minutes)

Turn the numbers into storage and throughput. Example: 1 million daily users, 10 writes each, 1 KB per write means about 10 GB per day and roughly 115 writes per second on average, with peaks maybe 5x higher. You don't need precision, you need the order of magnitude to justify later choices.

3. Sketch the high-level design (10 minutes)

Start simple: client, load balancer, stateless app servers, a primary database, and a cache. Explain the request path for each core action out loud. Only then add pieces the requirements actually demand, such as a queue for slow work or object storage for files.

4. Define the data model and API

List the main tables or documents and their keys, and write two or three API endpoints. Interviewers often dig into this part with juniors because it connects directly to day-to-day work.

5. Go deep on one bottleneck (10 minutes)

Pick the component most likely to break first and discuss options: read replicas, caching strategy and invalidation, sharding by user ID, or rate limiting. Name the trade-off of each option rather than listing them.

6. Wrap up with trade-offs and failure modes

Summarize what you'd monitor, what happens when a server or the cache dies, and what you'd build next with more time.

How to practice

• Do one design per week out loud, timed, with a friend or a recording.
• Reuse the same six-step skeleton until it is automatic.
• Review real-time feedback tools if you want a second opinion while rehearsing; an AI interview copilot like Linkjob AI can listen to mock questions and suggest structure and follow-ups as you go.

The goal isn't a perfect architecture. It's showing the interviewer you can turn a vague prompt into clear requirements, reasonable estimates, and honest trade-offs.

Quick refresher

• Situation: one or two sentences of context.
• Task: what you were responsible for.
• Action: the specific steps you took.
• Result: the outcome, ideally with numbers, plus what you learned.

Example 1: "Tell me about a time you handled conflict"

Situation: On a three-person project, a teammate and I disagreed on whether to rewrite a module or patch it before a release.

Task: As the person writing the tests, I needed us to agree quickly so QA could begin.

Action: I proposed a short comparison. I listed the effort, risk and benefit of each option, then asked us both to score them. We found the patch covered 90 percent of the need in a day, while the rewrite would take two weeks.

Result: We patched it, shipped on time, and scheduled the rewrite for the next quarter. My teammate later said the written comparison made the discussion feel fair.

Example 2: "Describe a time you failed"

Situation: I was responsible for a weekly report, and I sent figures that included a duplicated data source.

Task: Correct the error and make sure it could not happen again.

Action: I told my manager the same day, sent a corrected report with a short explanation, and added a duplicate check to the script.

Result: No decisions were made on the wrong numbers, and the check caught two similar issues over the next months. I learned to validate inputs before sharing results.

Example 3: "Tell me about a time you led without authority"

Situation: Our team's onboarding document was outdated, and new hires kept asking the same questions.

Task: Nobody owned the document, but I wanted to reduce the repeated questions.

Action: I collected the ten most common questions, rewrote the guide, and asked two colleagues to review it. I then added a reminder to update it during each release.

Result: Questions to the team dropped noticeably, and the next new hire was productive in her first week.

Tips for building your own stories

1. Prepare five to six stories that can flex across themes such as teamwork, conflict, failure, leadership and deadlines.
2. Use "I", not only "we". Interviewers need to know your contribution.
3. Quantify results when you honestly can: time saved, errors reduced, users helped.
4. Be truthful. Follow-up questions will expose invented details.
5. Practice aloud and time yourself. Recording a mock answer is a good way to notice rambling. Tools like Linkjob AI can support your practice, but the stories must be your own.

Common mistakes

• Spending too long on the situation
• Describing what the team did instead of what you did
• Ending without a result or a lesson
• Blaming others when discussing conflict

With a handful of well-practiced stories, you can adapt to nearly any behavioral question calmly and clearly.