Careers

We’re very happy 😁 that you’ve come this far, we understand that in some way you’re interested in what we’re doing at moclojer. Seeking to live intensely everything you’ve read here on our site and to live with people who match our culture.

Which stack do we use to develop FUCK!NG products?

• Clojure
• ClojureScript
• PostgreSQL
• Redis
• RabbitMQ
• Cloud: DigitalOcean and/or GCP
  • Object Store for media files
• Supabase auth
• Resend

Don’t wait for the chance

We like to work with people with professional ambitions. If you believe that moclojer is a company that will help you grow professionally, let’s go together.

Steps regardless of your area of expertise:

• technical test
• review of the technical test
• discussion with the team 🎉

Product engineering

• testing: software implementation (full stack, back and front in Clojure)
• Code review:** asynchronously via GitHub (in your repository)
• conversation with the product engineering team

Follow the steps below to apply:

1. create a git repository with the test implementation - we encourage you to make it public
2. after implementation, send an e-mail with the subject “product engineering at moclojer” to hey AT moclojer DOT com

Engineering test

• develop a product using Clojure and ClojureScript (you choose whether it should be monolithic or separate front and back);

  **I don’t know Clojure/Script, now what?

  • try frontend or backend
  • if you really can’t do it, do it using the technology you’ve mastered
  • obs: in the code review, we’ll ask you how you studied Clojure - we encourage our team to be curious and study new technologies

• Develop a product using the public API pokeapi.co, this is the time for you to be creative (we’re leaving the scope of the product that will be developed open on purpose)

• We use Docker (compose) to use the environment: docker compose up

  all external service dependencies should work (go up), using compose

• Use TailwindUI on the frontend

• Have a registered area, allowing the user to do something with the API data, e.g. favorite a Pokemon - this is just an example

• We want to understand your creative potential: have a cool idea for developing the product

• Describe your decisions in the README, remember that the README will be the documentation, we want to understand how you arrived at the architecture decisions, what you’re using, why you’re using it, why you’re using X and not Y, etc.

• We are not defining the architecture you should use, use the one you are most familiar with

• Unit testing is part of software, take care with what you are developing - quality is not negotiable.