Plik readme na githubie

Witam, chce napisać plik readme na githubie aby udokumentowac projekt. Czy ktoś byłby chętny zerknąc na to i stwierdzić czy jest ok ?

# Project Name
> Rental movie

## General info
The aim of the project was to implement a movie rental company that provides registration and login services. After logging in to the application, we get other permissions that can be expected from the rental company.

 
## Features
* add / edit / delete movie
* evaluation of movies by a logged in user
* presenting the best offer
* information about the last viewed movie
* sort by rating
* button colors change
* registration / login
* search engine
* setting the status change option to inactive / active for the movies selected by the user

## Technologies
Project is created with:
* react 17.0.1
* react-router-dom 5.2.0
* axios 0.21.1
* bootstrap 4.5.3
* firebase
 
## Setup
Clone this repo to your desktop and run npm install to install all the dependencies.

## Contact
Created by mail@mail.pl - feel free to contact me!

 

Nie wiem czy ktoś czyta plik readme :) Jedyne co zazwyczaj jest interesujące z 'plików' to licencja na jakiej kod został udostępniony (nie licząc kodu). Czasem instrukcja 'instalacji/kompilacji' dla starych projektów.

W każdym razie polecałbym Ci zobaczyć jak wygląda readme w jakichś większych projektach (np. w bibliotekach od których zależy Twój projekt).

Projekt do cv, jako ze doswiadczenia nie mam to chciałbym aby jakos ten pliczek wyglądał, zeby rekruter mogl sie na szybko zapoznac co jest na githubie :p ale skoro mowisz ze nikt raczej tego nie czyta to moze usune to co tam napisałem :)

Moje doświadczenia z prowadzenia rekrutacji są takie, że:
- dostajesz 5, 10, 15, 25+ CV;
- co najmniej połowa CV ma się nijak do oferty pracy;
- jeżeli CV wygląda znośnie tj. łatwo znaleźć kluczowe technologie, które są wymienione w CV + kandydat spełnia wymagania lat pracy (nie dotyczy juniora);
to się zaprasza takiego kandydata. Krążenie po githubach osób nie ma sensu, bo jest zbyt czasochłonne i często nie ma większego fragmentu kodu na którym warto by było oko zawiesić.

Na rekrutacji zadajesz pytania adekwatne do poziomu doświadczenia. Jak nie ma podstawowej wiedzy to kandydat sam widzi, że nie ma wiedzy. Przykładowa weryfikacja kandydata:
- wymyślasz losowe zadanie algorytmiczne, które nie wymaga zaawansowanej znajomości algorytmiki (wiesz, że na kartce jest do rozwiązania w max kilka minut -> czytaj: najprostsze rozwiązanie nie przekracza 5 linijek kodu);
- patrzysz jak kandydat sobie z zadaniem radzi, jakie ma pomysły, czy rozwiązanie jest optymalne, czy ma pomysły na optymalizację, jakie błędy popełnił i czy podpowiedzi pomogą w znalezieniu błędów.
Potem możesz robić kolejne proste zadania, weryfikujące uniwersalną wiedzę (np. pytania z baz danych jeżeli w pracy będzie często używana). Na koniec jak widzisz, że kandydat ogarnia możesz wymyślić mu problem jakiś do zaprojektowania. Zadanie z projektowaniem rozwiązania do przedstawionego problemu jest zadaniem otwartym i nie ma jednego poprawnego rozwiązania. Można wówczas wybadać kto ma jaką wiedzę/doświadczenie/pomysły i gdzie widzi ryzyka itp. Juniora inaczej się rekrutuje niż regulara/seniora. Zadania z projektowania nie ma sensu dawać juniorowi, a nawet jeżeli się ktoś pokusi to brak odpowiedzi i tak nie eliminuje juniora. Regulara/seniora już tak.

Dla mnie ważna jest również komunikatywność kandydata. Nie musi być nie wiadomo jak wygadany, ale jednak potrafi np. opowiedzieć jak zaprojektowałby rozwiązanie do wymyślonego problemu albo potrafi opowiedzieć o jakimś projekcie domowym/firmowym co robił, czy pamięta jakieś ciekawsze wyzwania o których mógłby opowiedzieć. Można być przeciętnym w komunikacji, ale dobrym w kodowaniu -> kandydat przejdzie rekrutację. Można być dobrym w komunikacji, ale średnim w kodowaniu (junior) -> przejdzie również rekrutację. Ale jak ktoś nie jest komunikatywny to i nawet jeżeli będzie miał 10 lat doświadczenia to nie przejdzie rekrutacji, bo po prostu będzie takiej osobnie trudno zleca się zadania i je odbiera po ich zrealizowaniu (o ile się w ogóle dogadasz z taką osobą i zrobi to o co prosiłeś/zleciłeś). Możliwe też, że niekomunikatywny wymiatacz algorytmiczno/programistyczny też przejdzie rekrutację, bo firma będzie widziała zastosowanie dla takiego programisty pomimo, że komunikacja leży (ale takich osób w sumie nie spotkałem nigdy na rekrutacji -> jednocześnie zdarzyło mi się poznać osoby mało komunikatywne w firmach).