First, you need to have installed docker/docker-compose in your computer and also git. Initialize docker and clone the repo in the desired folder Once you do that, from the folder that has de docker-compose.yml file run the command "docker-compose build" and once it fininshes run "docker-compose up" to connect the database, the interrupt with "Ctrl+C" and tun the command docker-compose run --rm server sh -c "python manage.py makemigrations" then run docker-compose build again and the server will be available in http://localhost:8000/api (you can check that link in your browser, you will have the DRF default documentation available) and the client will be available in http://localhost:3000
Once you have the server and the client running, you can browse to the client url and register the repo you want to manage (with the link an the name), this web app is intended to manage cloned repos locally, it does not manage the remote repo since we wanted to avoid Github authentication bc it would difficult the review of the web app.
After you do that you will be redirected to the a view with a list of branches, this could take some seconds, bc in this step, the databse is being populated witha ll the information of your repo. then you can access to all the information such as branch details, commits details, create prs, manage prs and more.
Interview test for fullstack Software Engineers
If you're reading this, it means we're interested in working with you and solving amazing and difficult problems in real-estate tech in Mexico.
This README provides the instructions to a small, self-contained test for a FullStack Software Engineer position.
We're looking for a talented and driven full-stack engineer, comfortable with building responsive front end experiences, as well as with designing and building rigorous APIs and backend services.
This means that this test is designed to gather signal on your coding structure, the tradeoffs and decisions you make on API design, and how you build a lightweight frontend app to show the data coming from your API. We're excited to see what you build!
Today, we'll be building an API wrapper around the git information of this project. We suggest forking this repo and start working on it on your private fork, the url of which is the only thing you need to send us when you're done.
The main objects we'll be dealing with are:
- Commits
- Authors
- Branches
- PRs
We'd like to see a visual representation of the git history of this repo as a JS web-app, using the API previously described. To be specific, we'd like to see the following:
- A view where we can see the existing branches
- A branch detail view where we can see all the commits to one specific branch, with commit messages, authors and timestamps.
- A commit detail view where we can see the commit message, timestamp, number of files changed and author names / emails.
- A "PR" create view, where we can choose two branches (base and compare), and merge them together, just like Pull Requests work in Github.
- A "PR" list view, where we see all created PRs and the following info: Author, Title, Description and Status (
Open
,Closed
,Merged
). If the status isOpen
, there should be a button that allows us to mark it asClosed
.
For the PR create view, we'll ask the user for a PR title and description, and we'll give them 2 options: either save it (Status = Open
), or merge it. Note that merge operations can fail due to conflicts or other reasons, so make sure you handle and show whatever error happens when merging. There's no need to do something about these errors other than show them in the frontend. After a successful merge, the PR should move to a Merged
status.
We expect this test to take around 4 hours, but not significantly more (your time is very valuable!). We're giving you a week from the date you receive it to complete it and send us your repo URL, using whatever stack you feel most comfortable with. Due to this, we ask that you also provide a README
with instructions for running your project, both back and frontend, along with setup instructions (or provide a Dockerfile and a docker run
instruction).
It's up to you to design how this should look code-wise, but we don't expect you to model all git objects in a DB. We're ok with reading them using a library wrapper for git like GitPython, on-demand. The only DB design required is the one for PRs.
We'll grade this project according to completion percentage of the features requested, good coding style for both back and frontend. For us, good coding means:
- It's readable. We read code much more often than we write it, so it's important that we're clear on what we're doing and comment any hairy parts (which we don't really expect to have in this test!).
- It's reasonably well ordered and with a logically thought-out structure. We like to do separation of concerns, and deal with routing, DB models, serialization, etc in their own file structure / files.
- Clear, understandable variable names. No one wants to read the whole file to understand what the variable
c1_2
means.
We also care about being able to run your test without significant effort on our part, so make sure you test the instructions you provide on your README.
- Design chops: we care that you know enough CSS not to be surprised when you need to work on it, but we're not picky about your solution's UX/UI.
- Your code has tests.
If you come across any questions or anything we didn't cover on this README, feel free to reach out to us and we'll get you an answer as soon as possible. Happy coding!
{
"id": 9,
"name": "Studio Apartment",
"link": "https://github.com/jonathanh21/fullstack-interview-test"
}