from #435

While GitHub is popular, there are developers that rarely use source control at all, or just prefer another platform, so the website should be the go-to place for interview questions. Ours is kind of old and would be cool to have a better website.

I thought about Docusaurus but any other tool would be great to have.

Please note that after #445 each topic should have its own dedicated page.

Things to discuss:

• which tool?
• which design?

I definitely don't have time to build this in the near future but can definitely help/guide anyone who's interested.

I tried to find javascript books which go beyond just basic DOM manipulation and help us to answer interview questions like "Explain event delegation" (and more). I could not find any so far. Most books don't cover js in enough detail. So, can we also have a list of books to read ?

Maybe adding questions about promises and also difference between promise and jquery deffer would be nice. With recent changes promises will play important roles.

One of my favorite interview questions. You'd be surprised how many interviewees messed this up. An excellent answer (and discussion) can be found on StackOverflow. I'm not sure if this question belongs to JavaScript or jQuery though -- it's a bit of both.

Fixes # 565

Type of change

• [x] Other (please elaborate) Added Hindi translation for questions

Checklist:

• [x] My content follows the style guidelines of this project
• [x] I have performed a self-review of my own content

This pull request is for adding Hindi translation of questions. I have just added the folder hindi in src/translations folder and given source path in src/data/translations JSON file. Branch created for this purpose is named as hindi_translation#565. I am new to open source so if there is any error or mistake please let me know. Thank you.

So at the time of this writing, this project counts 31.661 stars which indicate how popular it is -- hanking in 60th in number of stars, just 2 positions behind Angular.

However, the web evolves fast and while most questions here remain relevant, I guess we're in a good time for an update -- there are lots of improvements we can do to help more developers. I tried to list some:

Better guidelines: what questions do we want? what makes a good question? (related: #307, #331, #335, #361, #421, #433)

We should describe more fully what questions we want to be added. Plus, in this project standards, what makes a good question? Being crystal clear here reduces stale PRs and encourage more contributors. Even a small addition such as a descriptive issue/PR template is helpful.

Also, I think questions regarding performance, http(s) and some front-end security best practices are valid and should be included too.

Re-organize questions (#257)

The web evolved a lot since this project was created -- specially JavaScript. Breaking down questions and dividing into sub-groups seems to be a necessity. How can we make it in a nice way?

Indicate resources with good answers (#338)

I like the idea of a "questions only" project but if we really want to help interviewers/candidates the best we can, having an area with some resources is a nice to have. While some searching might give the answer users are looking for, they might be misleading. The side effect of this might be that resources can potentially be oppinionated but I'd like to open discussion for this.

Create a new website

While GitHub is popular, there are developers that rarely use source control at all, or just prefer other platform, so the website should be the go-to place for interview questions. Ours is kind of old and would be cool to have a better website.

I spoke to a friend (@edkf) who's interested in making a design mockup to make it look cooler. I thought about using Docusaurus just because it's easy and designed for docs but if overkill I'm open for any other tool to make it.

Automate translations

As far as I know, the electron-i18n project was very successful using Crowdin as a tool for translating the project. Accepting translation PRs means that we rely 100% on maintainers which usually do not speak the translated language. Having it open for live edits might have better eyes to review translations. I'm not familiar with the tool but this might take some work to automate things, but would be nice.

Dedicate a -- very special area -- for contributors.

I really like the All Contributors specification and we should definitely use it. The website has some early contributors and a link to show all the other 100 ones. While this is cool this can be better with a cool link/avatar exposed for each contributor so maybe some of them might use this project's popularity to land a good opportunity, who knows? that's why we're doing this!

cc @h5bp/frontend-interview team. This is just a tracking list of nice's-to-have, we can break it down in smaller issues and address each idea separately as we define things.

By the way this is not tied to maintainers only and all feedback is welcome.

Last week, while being interviewed on the changelog podcast, I was asked why this project doesn't have a proper website. It's not well known but we do have a Github Page that is just a nicer looking version of the markdown file at http://h5bp.github.io/Front-end-Developer-Interview-Questions/.

I've also been asked countless times about what questions a "Junior" or a "Senior" Developer should know or be asked from this document. Terminology like this, of course, can be polarizing. Everyone's concept of a Junior or Senior Developer is different and every role has it's own specific challenges and knowledge requirements. Although those specific labels aren't helpful, I've begun to think that including meta-data and having the ability to label questions would be infinitely helpful for discoverability.

Sub-categorization is already being talked about in @richgilbank's issue #257, although I think we need to think about this a bit more broadly. Currently, we're extremely limited in how we can format and showcase content based on using only a markdown file. That said, I think there's a serious need to broaden the horizons of this project and build a proper website.

The HTML5 Please site is a good example of the kind of labelling/filtering we could add to questions to make search/discoverability much easier. But that's just the beginning.

Thoughts, feedback and suggestions are welcomed.

this looks like it could do the trick: https://github.com/marketplace/actions/eleventy-action

name: Eleventy Build
on: [push]

jobs:
  build_deploy:
    runs-on: ubuntu-20.04
    steps:
      - uses: actions/checkout@master
      - name: Build
        uses: TartanLlama/actions-eleventy@master
      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          publish_dir: _site 
          publish_branch: gh-pages
          github_token: ${{ secrets.GITHUB_TOKEN }}

Here is an addition to JS section: 4 questions about latest ES6 standard.

1. What is the most modern approach to accessing the list of arguments passed to a function?

This question identifies if candidate is aware of rest syntax, which is the modern standard for handling parameters passed to a function. Explaining what is the problem with arguments, imo, should count as bonus points.

2. What are the benefits of using spread syntax and how is it different from rest syntax?

If a candidate knows in which cases to opt for spread syntax, it means that he/she is writing more concise, cleaner code (e.g. replacing apply). Knowing the difference is really important since both syntaxes look exactly the same, but the aims are different.

3. How can you share code between files?

This one tests candidate's knowledge about ES6 modules, which is an essential part of modern day web development.

4. Why you might want to create static class members?

The purpose is to elicit an explanation of "static vs. private", plus common use case for static class methods.

This is actually my last question in my interview just about 3 weeks ago. My interviewer wrote out this sentence 2B || !2B and asked me what is the result.

My answer: true as I considered 2B as a variable and it would be true. His answer: 43, consider this 0x2B || !0x2B

What is yours ?

• The document in Indonesian was horribly translated by google translate. It was also a little outdated in comparison to its english version. My changes are mostly fixing weird sentences and keeping the doc up to date. Hopefully it is more legible now for Indonesian readers. :tada:
• While I am at it, I added a couple of missing links to the table of content for english version. And fix a little typo for consistency. :smile:

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

• [ ] New Question
• [ ] Revision of an existing question
• [ ] Infrastructure change (automation, etc.)
• [x] Other (please elaborate)

Checklist:

• [x] My content follows the style guidelines of this project
• [x] I have performed a self-review of my own content

Pull requests should be thought of as a conversation. There will be some back and forth when trying to get code merged into this or any other project. With all but the simplest changes you can and should expect that the maintainers of the project will request changes to your code. Please be aware of that and check in after you open your PR in order to get your code merged in cleanly.

Thanks!

Adding a list of files to translate and a list of language codes and folder names. I'm going to, one time, update the translations to get this into the shape we expect the project to be in, in the future.

Workflow?

1. Questions are edited in English
2. There are no translations in development or PR branches
3. development a new (soon to be) protected branch, is the target for PRs and ongoing development.
4. We create an Action for merges into main (monthly?) that
   1. Runs tranlsate.mjs (not the garbage version in this PR as of this writing, but a good version) which uses Azure translator api to translate to our target languages. We can add as many languages as we can translate for less than 2,000,000 characters a month.
   2. Creates a GitHub release (because why not)
   3. Build eleventy and pushes to gh-pages

Questions:

1. Still use eleventy and link to translations?
2. Would we want to copy the same multiple md file structure of the root for the translated folders?
3. What would we have to do to make sure we can still use eleventy on the automated translated markdown files.
4. Would it be better to serve the users preferred language?

Would it be possible to add some dynamic programming questions or data structures

eg) Implementing a Hashtable or Linked List or implementing Conway's Game of Life, seems like recruiters ask those types of questions even if you are probably just getting hired to maintain a landing page 🤔.

from #435

As far as I know, the electron-i18n project was very successful using Crowdin as a tool for translating the project. Accepting translation PRs means that we rely 100% on maintainers which usually do not speak the translated language. Having it open for live edits might have better eyes to review translations. I'm not familiar with the tool but this might take some work to automate things, but would be nice.