I failed my tech challenge today for a job interview. I don't think I was given a fair chance



Can we use chunk_every/4 here? What if the words we are looking for is the last word of the first chunk and the first two words of the next chunk?


3rd argument of Stream.chunk_every/4 is the “jump”. So if “jump” is smaller than window then you can control what will happen in window. As I defined jump to be one, it will give me stream of all 3 consecutive words sequences.

iex(3)> [1, 2, 3, 4, 5] |> Enum.chunk_every(3, 1)
[[1, 2, 3], [2, 3, 4], [3, 4, 5], [4, 5]]

my god, this is really cool, i honestly thought this chunk piece was the trickiest part of this interview question.


Hi, Polygonpusher. I wouldn’t be too worried about it. Just go to more job interviews and someone will hire you. I’ve been coding for 30 years and get turned down sometimes, even when I nail the coding challenges. That’s because interviewers are largely idiots when it comes to interviewing people.

Here’s the truth about technical interviews. 99% of the people that will interview you during your career know absolutely nothing about interviewing people and finding good talent. They’re as dumb as rocks when it comes to interviews, so they use code challenges to add a sense of legitimacy to an otherwise talentless, feeling-based, arbitrary crap-shoot. They decide within the first five minutes of meeting you whether they like you or not, and the rest of the interview is time-wasting fluff to justify the baseless, emotional decision they’ve already made.

Regarding the quiz you were given. It is not as easy as calling the chunk() function on a split() list of words and then counting how many times those three-word chunks are found in the list. That answer is wrong! The code challenge specifically said that you have to find the most popular three-word phrases and there is no guarantee, and should be no expectation, that those popular phrases would just happen to begin on every third word. It isn’t that easy! Instead, you have to calculate the frequency of n-grams and make comparisons based of that analysis, which is not trivial. Even using an excellent language processing library, like Python’s NLTK, you’re still looking at writing queues and about 40 to 50 lines of code. The calculation would require you to go through the list O(WN), where W is the number of words in the list and N is the number of n-grams. I would like to see your interviewers write that code in three hours without the use of a library. In my opinion, this aspect of their coding challenge alone is unrealistic and nonsensical, and just goes to show that interviewers are incompetent and ignorant when it comes to interviewing people.

In my opinion, if you’re a skilled developer and you cannot ascertain whether or not someone has good development skills through a simple conversation in an interview, and instead resort to gimmicky code challenges, you’re not a skilled developer.

I hope you have better luck at your next interview.


40-50? I gave an solution that does what is needed in just 27 lines with almost line by line explanation what it is doing. And it is as simple as calling chunk on reuse of split. And you can do it in O(m log n) time where m is count of words in original stream and n is maximum amount of different trigrams. So you are bloating problem, which is fairly simple, needlessly.


@hauleth - I hope I didn’t offend you. I didn’t mean to if I did. If you don’t mind, I’d like to go over your solution just to reiterate my original point.

You can correct me if I’m wrong, but here’s what your code is doing (I’m going to skip over the stream and normalize bits because those are correct):

  1. You’re taking the normalized string, “lorem ipsum dolor sit amet consectetur adipiscing elit cras quis turpis euismod fermentum sem id ornare nisl duis porttitor pretium lorem quis pretium donec placerat eros eu odio malesuada sollicitudin phasellus a consectetur nisi morbi nec dui at elit consequat dictum a quis purus,” and splitting it into a list of words.

  2. Next, you’re taking that list and calling Stream.chuck_every(word_list, 3, 1, :discard) on it, which gives you [["lorem", "ipsum", "dolor"], ["sit", "amet", "consectetur"], ["adipiscing", "elit", "cras"], ["quis", "turpis", "euismod"], ["fermentum", "sem", "id"], ["ornare", "nisl", "duis"], ["porttitor", "pretium", "lorem"], ["quis", "pretium", "donec"], ["placerat", "eros", "eu"], ["odio", "malesuada", "sollicitudin"], ["phasellus", "a", "consectetur"], ["nisi", "morbi", "nec"], ["dui", "at", "elit"], ["consequat", "dictum", "a"]] since you’re dropping the last two words.

  3. Then, you’re joining the trigrams back into three-word sentences, so you end up with ["lorem ipsum dolor", "sit amet consectetur", "adipiscing elit cras", "quis turpis euismod", "fermentum sem id", "ornare nisl duis", "porttitor pretium lorem", "quis pretium donec", "placerat eros eu", "odio malesuada sollicitudin", "phasellus a consectetur", "nisi morbi nec", "dui at elit", "consequat dictum a"].

  4. Then you’re counting the occurrence of each of these trigrams by creating a map, with each trigram as the key, and updating the count each time the trigram is found. In this example, you’d end up with the following, since there aren’t any repeats.
    %{ "adipiscing elit cras" => 1, "consequat dictum a" => 1, "dui at elit" => 1, "fermentum sem id" => 1, "lorem ipsum dolor" => 1, "nisi morbi nec" => 1, "odio malesuada sollicitudin" => 1, "ornare nisl duis" => 1, "phasellus a consectetur" => 1, "placerat eros eu" => 1, "porttitor pretium lorem" => 1, "quis pretium donec" => 1, "quis turpis euismod" => 1, "sit amet consectetur" => 1 }

  5. Then you’re sorting the results, taking the top 100, and printing out the results.

In other words, what you’re doing is analyzing the string like this:

lorem ipsum dolor
sit amet consectetur
adipiscing elit cras
turpis eusmod fermentum

and then counting how many repeats you have in that subset of possible trigrams. You’re also ignoring the last 2/3rds of the final trigram. What you need to be doing is this:

lorem ipsum dolor
ipsum dolor sit
dolor sit amet
sit amet consectetur
amet consectetur adipiscing

and THEN analyzing that list. Yes, you don’t need a complicated library to solve this, but it is a problem that is easily misunderstood and not something that I feel these interviewers were being realistic in by expecting to be done in under three hours, especially when paired with all their other requirements.

You’re obviously an excellent coder, but it appears that even you didn’t get it right the first time, which is entirely my point. I’m not trying to disparage your example in any way. My issue is with the test itself and your example perfectly illustrates my point. You know how to code and I think you did what most of us would do. Would we fail their test, simply because we counted the trigrams incorrectly? Maybe. If that is indeed the case, the company has likely rejected quality candidates because they don’t know how to interview people and many candidates have likely walked away feeling their time was wasted. Candidates talk, so this may result in the company losing even more quality candidates.

I’d like to see whoever administered this test solve it correctly in three hours without any foreknowledge of the problem. I doubt they could.

Again, I apologize if I offended you, @hauleth. That wasn’t my intent.


Did you actually run Stream.chunk_every(word_list, 3, 1, :discard) on your example word_list? It does return the list you say is needed for the challenge and it does also not drop anything, as it’s only moving forward one element at a time. It just stops as soon as there are not longer 3 elements to be chunked together.

  ["lorem", "ipsum", "dolor"],
  ["ipsum", "dolor", "sit"],
  ["dolor", "sit", "amet"],
  ["sit", "amet", "consectetur"],
  ["amet", "consectetur", "adipiscing"],
  ["consectetur", "adipiscing", "elit"],
  ["adipiscing", "elit", "cras"],
  ["a", "quis", "purus"]


@LostKobrakai - Nope. I don’t have the ability to now. However, if that is what it returns, then thanks for pointing out my mistake. @hauleth was right and I was wrong.


I still don’t believe @polygonpusher should give up on the industry, and I still believe technical interviews are largely stupid though. :wink:


Most technical interviews are indeed very strongly biased towards one direction or another. I’ve been in many companies – not a good thing to say about one’s career, I hear, but I found it quite illuminating throughout my life – and I honestly only ever met two people in total who could properly interview a candidate. Most cannot even tell a good joke over a beer, let alone be able to understand another person’s motivations and skills in a conversation. That’s the harsh truth.

I believe @clinton absolutely nailed it with everything he said. With 99% of the interviewers your fate is decided in the first 5 minutes, the rest is just the interviewers doing post-hoc rationalisation of their gut feeling.