So, it’s finally done! I’ve created a tool to help every Javascript programmer to kick ass in a technical interview.

It’s not an app, it’s not a website. It’s a deck of flashcards. I decided to name it Flashcards.js

Flashcards.js questions deck

On the photo you see the Essential deck. It’s 54 cards with the most popular interview questions that people in European and Russian companies ask. I went to A LOT of interviews and I can say that people repeat themselves. Everyone is asking about the closures, about how to empty an array and so on.

Questions that are often asked

A lot of the interviewers google something like “frontend interview questions” and end up in this old Github repo. That’s why I included the majority of these questions to the cards.

Some people want to see if you respect JavaScript. That’s why they will ask about closures and prototypes. I included these questions as well.

Finally, I’m not the only person who was going on all these interviews. I was asking my friends and colleagues about their recent interviews and documenting everything they were saying.

The questions are solid, the questions are good. There is a huge chance that some of them will be actually asked in your next interview.

Paper form

Why paper and not an app or a website? You see, the paper form has its merits. You can put all 54 cards on a table when you prepare and tomorrow the interview will start. This is one of the things that you can’t do on your phone.

Cards laying on a table


First of all, I split the questions by popularity among the interviewers. See a little circles on the upper side of the cards?

  • Three circles means that the question is asked by everyone. If you don’t know the answer, you’re doomed. For example what’s a closure. Everybody asks what’s a closure.
  • Two circles means that I’ve seen this question being asked more than once, but it’s not pervasive. For example, the questions about Websockets. People in browser game industry ask them a lot, while other companies don’t
  • One circle are really specific questions that are rare but can catch you off-guard. Some of them are hard and require the knowledge of nitty-gritty details.

I split the cards on the following categories:

  • Browser: everything about DOM and how the browser works
  • Async: asynchronous behaviour, promises, event loop
  • Types: coercion, fundamental types, how the typing works in JS
  • Objects: this, prototypes, classes
  • Functions: bind, call, apply, functional programming
  • Code: coding puzzles
  • General: everything else

This pretty much covers every type of question that I was ever asked. It also reflect the structure of Kyle Simpson’s books You Don’t Know JS which I highly recommend. The book is awesome if you have a lot of time and need a long description with lots of examples, while the cards are great for quick review of your knowledge.

How to use them

Training with flashcards.js

Use them as you would use any flashcards. I prefer to concentrate on three circles first, and then I pick the theme that I’m unsure of. For example, the Objects them. I pick the cards one by one, read the question and try to answer it right away out loud.

It’s really important to say the answer out loud. Sometimes I ask my girlfriend to show me the cards and to control me. She pays attention to my rhythm of speech, looks at how confident I am. All these details play important role when you create the first impression on a workplace. You should be relaxed and you must feel professional.


Page Schemas screencast

Page Schemas is a great extension for Semantic MediaWiki that allows us to generate the structure of our websites from the XML description called schema. I’ve fallen in love with this extension long before it have been implemented (back then Yaron wanted to call it Semantic Schemas).

So, Page Schemas works like this:

  1. you go to a category page;
  2. you define all the properties, templates and forms that will be used for the pages of this category – this is called the schema;
  3. you push the Generate button and enjoy the result;
  4. if you need to make improvements in the structure of your schema (like add some fields, change the allowed values for properties or modify the template) – you edit the previously defined schema and re-generate all the pages
Page Schemas look like Create a class special page but:
  • It’s more powerful and beautiful: you can define multiple templates for forms (remember ‘Add another’ button?), define the parameters of the fields (like ‘values from category’)
  • It allows you to add and remove the fields and templates without all that tedious mucking about in mediawiki editor
  • it has very nice pluggable architecture and you can connect your own extension to it


Fighting spam in MediaWiki

Cleaning up spam on semanticweb.org and on letopisi.ru have resulted in a little tutorial and a presentation I want to show.

Ok, so here is some advice that can alone improve your spam situation.

  1. Healthy community. If your wiki has enough users who care about the content, they will clean up the spam manually.
  2. Heuristics and little tricks. For example you can set the waiting period for all the newly-registered users. That will help because the majority of bots register and immediately write something
  3. Questy captcha instead of any other captcha
  4. If nothing helps use behavior analysis tool called AbuseFilter