Cover image for How to lose a Job in 10 minutes

How to lose a Job in 10 minutes

albinotonnina profile image Albino Tonnina Updated on ・7 min read

Whiteboard coding interviews can cost you a job

Recently I’ve been quite close to getting a job at one of the Big 5. I went through the screening process and the take-home assignment smoothly but I failed to pass one of the final stages, a set of one to one, or two to one, interviews:

  • Whiteboard coding interview: algorithms.
  • Technical interview: JavaScript, CS, React.
  • Culture fit: that.
  • Second whiteboard interview

It went wrong

There are a few mistakes that contributed to this temporary debacle.

I may have passed the techical test and the culture fit (let’s just assume that) but I admittedly performed badly at the whiteboard coding interviews.

Thinking in retrospective about that day I couldn’t expect any different outcome.

The truth is: I’m not prepared to do whiteboard interviews.

Whiteboard interviews

The whiteboard interview is, in some ways, a hybrid of a technical test of the depth of your knowledge and also a social exercise

We all know what it is, right? it’s not much about the code, it’s about your solving abilities, it doesn’t matter if etc etc…

I’m a frontend developer, I generally don’t implement interview-like algorithms or articulate my thought process while I code, I sort of make interactive UIs most the time.

How much do these tests tell about a candidate anyway?

Someone even said:

In real life, you would rarely just whip up an off-the-cuff algorithm from memory in the middle of a coding session. You are almost always going to use an existing library, which has its own test suite, and has survived the scrutiny of other developers.

The only world where you would actually need to be able to recall an algorithm would be a post-apocalyptic one, where the hard drives of all the computers connected to the internet were fried, and all copies of foundational academic papers and computer science textbooks had been reduced to ashes.

My opinion tend to match the one of the aforementioned author although I like to believe that such a skill (being good at whiteboard interviews) is about having a set of very good to have other skills, soft and hard.

Mitigating circumstances first

I’ll make this list because you may relate to some of them but most of all I still have to vent a little bit 😄

  • I didn’t do the interview in my first language. Under pressure and under the spot it suddenly becomes more difficult to talk in english.
  • I’m a self taught frontend developer. I lack an academic preparation.
  • I didn’t do many interviews in my career. And not many of them had whiteboard interviews kind of tests.
  • I don’t do much public speaking. Unfortunately, at the moment, not much.

You could object that none of these are actually mitigating circumstances and you would be right.

By definition, mitigating circumstances are out of our control: the truth is that I could improve my English, do more CS, do more interviews, do more public speaking.

I’m gonna try to solve that first whiteboard test the way I should have done that day and I’m going to try to report the process here.

The Test

;['Tokyo', 'London', 'Rome', 'Donlon', 'Kyoto', 'Paris'][
  (['Tokyo', 'Kyoto'], ['London', 'Donlon'], ['Rome'], ['Paris'])

That’s it. If you rotate the letters of each city you may or may not match another city. In case you do, put them together in a array on their own.

At work you’re escaping labyrinths of thousands of lines of code on a daily basis, how difficult is to show these people how to solve this simple and even kinda funny problem? Hold my beer.


Let’s pretend it went slightly differently.

The perfect whiteboard interview

Catchy paragraph title, although wrong. This is just the way I could have solved this test, both code and thought articulation. Who know how many other ways there are!

Me: thank you very much. I’ll gladly solve this problem for you (little bow)

Me: First question, do the letters just ‘rotate’ or they can be randomly mixed up?

Larry (to protect the privacy of the interviewers, I changed their name into a fancy one): Just rotate. First letter goes last, etc.

Me: right.

Larry: right.

Me: Right! I guess to start I would need a way to rotate the letters of each city. Tokyo would became okyoT, then kyoTo, oh cool! we’ve got kyoto now! Ok, I’m going to need a function to do that.

Me: I also need a way to loop through the input cities, ‘rotate’ the letters, do some matching and lastly grouping them together. I see that the input and the output are both arrays and they both contains the same values, the only difference is the depth of the two arrays, a flat one and an array of arrays.

Still me: I’m gonna write some pseudocode now to validate my thoughts. Later I’m going to test it too, cause I’m that good. 😏

function groupCitiesByRotatedNames(cities) {
  // use a variable to contain the output.
  let output = []
  // loop through each of the cities
  //  rotate the name in any possible combination
  //  check if the output contains a city that matches a combination
  //   add that city to the array containing the match
  //   otherwise add the city to the output as a new array
  return output

Me, confident as a rockstar: let’s pseudotest my pseudocode (😛).

const input = ['Tokyo', 'London', 'Rome', 'Donlon', 'Kyoto', 'Paris']
// That's how it would build up. The final output would be the last array:
// [
//     ["Tokyo"]
// ]
// [
//     ['Tokyo'],
//     ['London']
// ]
// [
//     ['Tokyo'],
//     ['London'],
//     ['Rome']
// ]
// [
//     ['Tokyo'],
//     ['London', 'Donlon'],
//     ['Rome']
// ]
// [
//     ['Tokyo','Kyoto'],
//     ['London', 'Donlon'],
//     ['Rome']
// ]
// [
//     ['Tokyo','Kyoto'],
//     ['London', 'Donlon'],
//     ['Rome'],
//     ['Paris']
// ]

Let’s start implementing this algorithm.

First, the utility to rotate the letters of the city names. I will create a utility function:

Me: let’s make this function a bit smoother (and less readable). Overconfidence at its peak.

Me: Right! I like the reduce method, I’m gonna use it again! (It’s also very functional-programmy so it’s cool to use in an interview 😎)

The reduce() method applies a function against an accumulator and each element
in the array (from left to right) to reduce it to a single value

Our single value being the desired output.

Let’s sum up what this algorithm does:

We check for each city in the cities array, we rotate the nameand we match
every combination with the accumulator value. If we find something we add the new city to the array containing the matches (with Array.splice) otherwise we just push a new array containing our new city.

Et voila’:

All together now!

Get the Gist here.

The actual whiteboard interview

I started from the solution. I said, ok, I’m gonna need a reduce method. I immediately approached the board to write actual code without really knowing the plan. I did have an idea of the solution, pretty much the one I wrote in the previous chapter, but I didn’t articulate it, I didn’t really explain it consistently to my poor interviewers. So I got lost in the code, I lost the the train of my thoughts several times, I also stumbled on syntax errors, in a mix of poor written pseudocode and actual code. There was no way to turn the tide at this point. A performance like this can make a lot of damage to the outcome of the interviews, especially if you let this affect the rest of the process on your side.

What should I do now

Practice, practice, practice.

Get a whiteboard, pick a problem and talk out-loud to the air and write, do that a lot.

Practice the whiteboard interview, learn the routine. Your routine, any routine. Learn it like a song on the guitar, a card trick or whatever dangerous stunt with your skate.

You need to prepare a speech, it’s like a presentation.

It’s like a presentation with variables.

A variable is the problem.

I’ll go like this:

  • I’ll spend some time analysing the requirements (1 min)
  • I’ll formulate questions if necessary and get answers (3 min).
  • I’ll pause and think of a direction to take (few min, don’t be afraid to stay silent for a while).
  • I will propose initial solutions and get feedback from the interviewers (5 min).
  • I will pause again and choose a solution (2 min).
  • I will write pseudocode (5 min)
  • I will test my pseudocode (5 min)
  • I’ll finish by transforming the pseudocode into actual code. (until necessary)

In around 30 min I will have solved the problem in a enjoyable and ordinated way.


Thanks for reading

And Thanks Adam Mackintosh and Josh Comeau for proof-reading this :)

Hello, my name is Albino Tonnina, I’m a frontend engineer who does bad whiteboard interviews at the moment and works in London, you can find me on Twitter or Github or Instagram or around the city.

Posted on by:

albinotonnina profile

Albino Tonnina


Particularly interested in UI Engineering


markdown guide

I applaud the effort in your post, but maannn.... I’ve been hiring developers for about 15 years and I’ve grown to despise white board interviews. I’m convinced that any organization that requires whiteboarding in their technical interviews is simply doing it wrong.

I’m also pretty convinced that the “big 5” have very inefficient hiring practices (and I’ve worked for two of them, so I speak from experience).

I understand why junior devs want to work for them, it’s a sort of initiation ritual into the tech world, but I wish more companies could move on from interviewing practices that were invented back when we used punch cards to write programs...


I agree totally with this. I don't do whiteboard interviews and I've been hiring other devs since early 2000s. It shows absolutely zero and starts everything off in a hostile environment. Prove to me you can cook a dish by writing out a recipe with your non-dominant hand. And stand on one foot.

Whiteboard interviews are more hazing ritual than anything.


Ahahah I enjoyed a lot your reply, thanks :)


Hi Patrick.
What do you use instead of the white board interview to make sure the candidate is right for the position?



We do one design interview, and one programming interview (out of 5 total). Candidates are encouraged to use the whiteboard if it helps them explain their thinking, but the whiteboard is just a tool.

So "design" will concentrate on architectural decisions, whereas "programming" will concentrate on things like algorithms and data structures.

The other 3 interviews are all about behavioral questions, not programming ones.


I've long made a pact with myself: the moment an interview process includes a whiteboard part, I walk out and tell them it's because of the whiteboard. At this point they either want me enough to hire me anyway or it is a better outcome for both parties when I don't work there.


The people in charge of the interview process may well not represent the rest of the company or its culture. At at least one place where I worked, the interviews were done by tech-savvy senior management without involving any of the day-to-day development team at all, which resulted in us employing a lot of people who never lasted their probationary period.
In the trenches, it was still a good team to work for :)


When I am interviewing people I honestly don't even care if they give me a fully correct solution. I understand not everyone can do that spur of the moment. I certainly can not. What I'm looking for is confidence in your solution, your thought process, the questions you ask, and if you can explain why you think your solution is right.


That's exactly what I did wrong. :)
Knowing me, not knowing how I should do whiteboard interviews I've got nervous, ultimately auto-sabotaging my performance. So what this test proved of me is that when I'm agitated I cannot articulate the solution of an algorithm. It's something that for me has to do more with public speaking than the job itself. I never have that feeling at work, not like that!


The interviewer did a bad job: it’s his duty to make you feel comfortable and safe. And it’s his job to animate a conversation if you’re stuck in your thoughts. And it’s his duty to guide you to write or discuss top level pseudo code.
Then whiteboard interviews make sense...

"The interviewer did a bad job: it’s his duty to make you feel comfortable"

Agreed. I always try to make people feel comfortable because if they don't, I ultimately don't get a chance to see what they are really capable of.


Well, interviews are always stressful situations, so don't beat yourself up about it.

But one remark: try to resist showing off too much technical cleverness. Two reasons for that: first of all, you risk getting lost in unimportant technical details (what was the exact signature of a reducer function again?) rather than acutally solve the problem. Also you might also raise suspicion that you value complexity over simplicity.

Personally I think the best interview preparation is having a real person in the room (which doesn't need to be technical at all) to which you talk. Mentally walking through an interview on paper or in a preparation book is not the real deal. It costs a little bit more effort, but is worth it. The second best to that is rubber ducking. But by any means: talk out loud, even if you are alone in your room.

All the best for your next interview (with or without whiteboard)

P.S. I could not help it, and came up with this alternative solution to the problem


Love your solution, Fabian; short, precise, efficient, readable & understanding the actual problem over having to show off reduce :)

This might be for you:


Here’s my take based on anagramNormalized (SCNR ;) )

function anagramNormalized(str) {
    return str.toLocaleLowerCase().split("").sort().join();

function groupBy(array, fn) {
    return array.reduce((result, word) => {
        const group = fn(word)
        const target = result[group] || []
        result[group] = target 
        return result
    }, {})

const list = ['Tokyo', 'London', 'Rome', 'Donlon', 'Kyoto', 'Paris'];

Object.values(groupByAnagram(list, anagramNormalized))

Thanks both of you!
Your solution I'm afraid doesn't solve the problem though!
It's important that the letters rotate one by one, sorting them would create false positives.

So London and Donlon would go in the same array but not DnnooL!

Also using reduce on an array is not showing off, come on, it's using a legitimate method of the array object, what's wrong with it :)

Ah, you’re right, I missed that requirement.

Nothing inherently wrong with reduce – I’ve used it in my solution ;)

But back to whiteboard interviews:

I've seen dev interviews from both sides of the table. Currently I manage a team of developers and as such I also hire people; we conduct interviews over video calls, and I ask candidates to take an actual coding challenge.

You might be surprised at how many people with "impressive" resumes apply for senior dev positions and can not explain or let alone code the simplest thing. And I mean the simplest thing, like sorting an array.

So, I like my whiteboard interviews because it helps me identify the strong candidates that we then hire to build a great team.

Hi Andreas!
I cannot surely disagree with you.

With this article I just explored a thought, a little doubt about this process: what is the actual skill that is being tested during a whiteboard interview? We know that observing a candidate during a whiteboard interview gives us insights about both their communication and their technical skills.
My hypothesis is that the particular "sub-skill" of communicating effectively under stressful circumstances such as an interview is a must-have if a candidate wants to pass this test.
This sub-skill though may tell little about the talent of the candidate, unless you are looking for someone that needs to have that of course.
And the lack of it though could overshadow any other skill they may have, maybe jeopardising the entire interview.
In conclusion what I would say is that people should do practice for this test.
If you're not a natural, practice is the way to go. Problem solved! ;)

In conclusion what I would say is that people should do practice for this test.

I agree and I appreciate your pro-active approach.

Keep in mind that failing this interview because of your lack of this one skill didn't get you the job you wanted and applied for. (I’m not saying this to criticize you)

Great candidates master this skill and at the same time are great developers as well. These are the ones everyone is looking for; and they are your competition.

Taking the proactive route of acquiring this skill will take you a lot further than blaming employers for doing whiteboard interviews; Kudos to you!

Can someone please elaborate on why the solution with sorting string literals to be compared and then finding out if they are same (case insensitively) would not be sufficient? How does it not meet the requirements?

I understand that the point of this post is elsewhere but just not to wrap my head around it anymore.

Thank you

Well, the solution matches the provided test case, but the test suite obviously was not extensive enough to test for all edge cases. Poof provided in his reply the hint

So London and Donlon would go in the same array but not DnnooL

It also was in the "interview" part of the article:

First question, do the letters just ‘rotate’ or they can be randomly mixed up?
Larry (to protect the privacy of the interviewers, I changed their name into a fancy one): Just rotate. First letter goes last

So comparing by the anagram builds up groups of the wrong equivalence class. To use the phrasing of Poofs article, it is "randomly mixing".

But the definition of "just rotate", as I understood it after the new test case, that DnnooL is not in the same equivalence class as London, is to be case insentively the same string as one element of the set that you get when you split the string at any index, swap the parts and concatenate again.

Albeit, I still stand by the general structure of the solution I proposed, which doesn't need reduce at all. Just swap the predicate isAnagram with isRotation, e.g.

function range(n) {
  return Array.from(Array(n).keys());

function allRotations(str) {
  return range(str.length)
    .map(index => [str.substring(index), str.substring(0, index)])
    .map(array => array.join("").toLocaleLowerCase());

function isRotation(a, b) {
  return allRotations(a).includes(b.toLocaleLowerCase());


An alternative approach to this question is to put the cities into an easier to work with data structure, such as a map (aka object) of sets, with the key being a canonical rotation, and then translate that into the desired array of arrays in the output. (Here is that as a gist. )

You didn't ask for suggestions on the solution, but I couldn't resist playing around with the exercise. I might have drawn a blank if asked to come up with this at a whiteboard though. My first solution was four nested loops.


Hi Dustin, thanks for your reply!
I didn't ask for suggestion because I'm sure there are so many solutions to this test!
More performant, more declarative, more functional, more more more :)
Someone may even find an O(1) version of this, I don't know :D

As you said the problem is doing it there, under pressure. I like to write elegant code, I like approaching problem methodically, I do like these problems. But my method it just doesn't work in a context like that. Not when the stakes were so high.


I laughed so hard at "four nested loops" 😂😂😂


I do whiteboard interviews (interviewers side ;) ).
A clean and readable solution with nested loops would have been perfect for me.


Cool article.

I would approach something like this in as simple a manner as possible though. I'd use those creaky, dinosaur-like for loops and so on. I'd tell them I was doing it deliberately, too. I might make the code more modern in a second pass or talk about it in the inevitable section afterwards where they ask you what you could do to improve it.

Just my vector. I've never passed a whiteboard interview, though, so what do I know.


Thanks Ben!
While I agree with you, it's becoming more rare everyday for me to use for statements. They just don't came anymore as first option to be honest! I guess that the community did a good job in advocating for array methods lately!


Completely empathize with your experience. Whiteboard interviews just aren't sufficient for gauging the skill-level of a dev. It also makes it difficult to figure out how well that individual can function in a team environment because the whiteboard interview is so artificial. Ensuring that the interviewee is embedded in an experience that more closely resembles the collaborative setting software is built in usually produces a better result for everyone involved.

This is actually what led @tonymastrorio and I to build Whiteboardfree. You can use the site to find jobs at companies that don't whiteboard during the technical interview process. No need to hassle with those interviews anymore :)


So if the company doesn’t do a whiteboard interview, doesn’t give out coding exercises, then how should they get an idea of the candidates capabilities??


Just my two cents, here, but I think the interviewers are looking to see if think about grouping the city by length first, and then check for rotation matches.

Then, if you want bonus points, I would not write a function that create the rotations for one city, but checks if two cities are rotation matches. You don't really need to creates strings, just compare offset indexes. You can quickly decide that a pair of cities are not a match here, by finding all the letter in the second city that match the first letter of the first one: if none, not a match ever, and if there are, then you just reduced the number of possible rotations "anchors".

Granted, not necessarily easy to think about all that under pressure, but that is what a whiteboard coding interview is: not focusing on the small syntax details, but on the general approach to the problem.


That's a nice idea. I also just thought of a useful way to check if two strings x,y are rotations of each other.

x is a rotation of y iff x occurs in yy and size(y) = 2*size(x)

Actually, it's quite similar to what you're suggesting.


I think whiteboard interviews is too much old for 2018.
Today we have so many ways to know the level of knwoledge of a candidate, with a simple test or pair programming already know the level.
The best experience i had in interviews was when the interviewer send me a test and when i finished he call me and ask how and why I come to that result, he tried to understand my logic and how difficult/ease it was for him to understand

  • no pressure
  • no fear
  • just code and a good conversation (like us in a day job) 🙂

The tips I have is:

  • aways remember, the interviewers DON'T know development, with lucky they know what is a if() or for() 😂, so trie to communicate, talk about what you want to do, sometimes they understand everything only reading the variables and some explanation.
  • Make all the questions you need to resolve the problem, they have the answers you need to get in the result.
  • You don't need to trainnig aways, but only if you want to switch the job, in this case I suggest you training one of this coding challenge websites (HackerRank, TopCoder...)

Hello Gabriel, wonderful comment, thanks! Couldn't agree more!


Personally, I think a Whiteboard interview would just infuriate me. I watched a mock whiteboard interview on YouTube done by one of the "Big 5" and I was pissed at the end. It felt to me that the interviewer was just trying to trip up the interviewee. Kinda like, "You think your smart eh? Then prove it, Dumb Dumb." Frankly, I think Whiteboard interviews strip companies from hiring very talented thinkers and coders and they also seem slightly dehumanizing. IMHO


Thanks for sharing, I had almost the exact same experience it seems like. I interviewed at one of the Big 5 (from your explanation it sounds like it may have been the same one actually...), where I had 4 hour-long interviews back to back in one day.

I tried to prepare and review my algorithms etc. before going (it was a cross-country trip for me, so I had time...). I felt like I did pretty well on the first 3 interviews, and I'm sure I did a crappy job on the last one (which was purely algorithmic in nature).

And it was mostly because of the same things you described...I just did a bad job taking my time, explaining my approach, asking questions for clarification, etc. Literally as soon as I got back to my hotel room after that interview I banged out the solution in no time, but I just kind of choked in the room during the interview. I think it was nerves and being a little exhausted from the multiple interviews and probably just not being fully prepared with enough algo stuff. I don't know how old you are, but I've been out of college for almost 15 years, so it had been awhile since I had focused on that stuff.

Anyway, all this is to say that I have some idea of how you feel, and while it was pretty disappointing at the time, life goes on :) You sound like you learned a lot from the experience, so at least you got something out of it ;) Some of the feedback I got was to brush up on some of that stuff, and re-apply after some time. I have no idea if that would actually work (I haven't tried...) but it's probably worth a shot.


Thank you for sharing your experience! I'm not alone :)
As you said it's been a learning experience so I'm fine :) Thank you!
And in your case, of course it's worth a shot, re-apply!


Hi Albino and friends,

Documented this "interview pattern" on a post here: medium.com/@dimist/red-flags-in-in....

After some deliberation I find it difficult to get out of my life, study algorithms for some time just to pass an interview, and then forget them, unless the interviewer confirms that day to day activities consist of doing such things.

I have a friend in a similar situation like you (self taught, Italian :), front end). His approach is to iterate through many companies until he finds one that does not do that type of interviewing, they are out there.


Hey ciao! ;)
Thank you so much for your comment, really appreciate it! Gonna read the article very soon, from the beach (taking a break from all this interview madness :P )


From reading your post: do a reverse Cinderella thing: instead of trying to change your foot to fit the shoe, get another shoe.
(and post pics with lots of sand).


I know how frustrating whiteboard interviews can be. It's why I made an online course to help people struggling with JavaScript interview questions. If anyone wants to check it out, here's a link with a coupon code already applied. The first few problems & solutions are free for anyone to look at. Hope this helps!


woah, looks great – have been (somewhat desperately) looking for something like this!


It's midnight here, and the article is too long, but I did a quick read, and lose a job after a interview recently.

There're a lot of things to think about, like how to solve this problem? If I can do the interview again, what should I do?

Then I come up with a theory that's the solution must be simpler than I thought, yeah, It's must be. But what is this?

Then somehow, I forgot to think of the solution, got high a little bit, etc

Then ... f*ck off, I fail because they didn't want me, that's it, haha. Move on to the next interview. My theory is proved now. LOL


Eeeew hard-coded <br> in the middle of sentences. You should have
a doctor look at that!


Hi! Where is the hard-coded
? I have the doctor on the phone as we speak.


An example:
<p>My opinion tend to match the one of the aforementioned author although I like to<br>
believe that such a skill (being good at whiteboard interviews) is about having<br>
a set of very good to have other skills, soft and hard.</p>

This renders really badly for certain viewport sizes. Excellent article though, I really enjoyed it!

Oh! That's bad! Thanks for telling me! I checked my article, no extraneous html tags so I guess the markdown parser that dev.to uses could be the issue. I'll forward this issue to someone!

And thanks for reading my article :)

I think I've found the issue! It should look better now :)
Thanks for the feedback!


White board interviews 'should' be about how you think on your feet and whether you can explain your process. 'But' they seldom are. Frequently, the interviewers are technical people and they are expecting a specific set of solutions - ones they have seen before for a given problem.

It is possible to practice, even memorize, specific algorithms. There are books out there that are set up in a nice format to do so. I have read through and worked with many algorithms, but refuse to memorize them. Because I LIKE thinking through a problem and devising new strategies.

I often fail whiteboards! And I'm okay with that. The few times I've turned the interview around (because I wasn't totally whipped) have been when I started speaking to what I do know, to what I can do, and why. It is unfortunate that many interviews are about regurgitation.


Hello !

I tried your problem, just to see if I can do it, I've used an ASCII sum, I think it should work, what do you think?

Go here: repl.it/@hydroweaver/how-to-lose-a...

I apologize for the code not being readable, I'm trying to slowly get there :)


Nice article. I too suffer from lack of skill at whiteboard interviews. Bummer you missed your chance this time at a big five. Keep at it; you can do it. A thousand no's but one yes is still a yes. Keep ya' chin up, you got this.


Really enjoyed your post, unfortunately, you didn't get the position but it seems you have learned a good deal with the interview process.
What I have been hearing on all the podcasts that I follow is that when you are in the interview you should talk through your process and also ask questions and include the interviewer as you try to deliver the code. Sometimes the test that you get won't have a quick solution and what the interviewer wants to see is how you react to pressure and if you are a good fit for the team.

I think being a self-taught coder makes things harder, we are used to having no one to talk to and it feels awkward to do it at first, I guess practice could help with that. One thing that could definitely help would be pair-programming so two of you could share ideas while coding.

Finally, the big 5 are very algorithm based and people that took a CS degree will always have some advantage in this scenarios. Doing exercises in sites such as codewars could perhaps prepare you for some of the questions that you might get in the whiteboard exercise.

I wish you the best of luck on your search :D


Is it a misuse of reduce to modify acc (because, ideally in functional programming, things are immutable), or does returning acc from the reducer function mitigate that?


Hey! Thanks!

I would go for the mitigation :P

const groupCitiesByRotatedNames = cities => newArray

I guess you could return always a clone of acc? For the purpose of the article, I would not give too much importance to this to be honest :)


Man, do I empathise! Thank you for sharing your experience!


You caught me with the first couple paragraphs.
I'll save this as a good read for later +Reading list


Noes! Let's outlaw whiteboard interviews instead -- don't encourage this -- they're on the way out in their traditional form.


Ottimo articolo!
Mi è piaciuta molto la tua sincerità, e l'onestà di riconoscere le proprie mancanze
Stessa esperienza mia fatta svariate volte)))
In bocca al lupo!


Non ci arrendiamo!

Grazie Francesco! Crepi! :D


Really nice use of .reduce() there in the getWordRotations, been studying the implementation and curious how this thing knows when to return the array 🤔


Ok never mid, it's [...word] spreading it into an array which is just being used as an 'iterations count'. Noob moment there 😝


And how to get a job in 10 minutes => loopcv.pro