# Job Description - Python Django ## For recruiters only - Salary ranges between 40 - 50K - Preferably owns means of transport ( nearest metro connectivity is Huda. We will provide 1 single shuttle that will leave at 10:00 AM from Huda ) - MUST reside in Gurgaon ( or in 30 minutes of travelling distance ) ## Company F Two, Private Limited, a product company based out of Gurgaon, is looking for it's first employee. We're the team behind Square1 ( funded by India Accelerator ) - the modern enterprise e commerce solution used by the likes of Vodafone. We believe developers shouldn’t spend time in the weeds of process, infrastructure, and communication. Our products remove that pain, allowing you to design, code, and ship brilliant software. We exist for our team. Our products and customers allow us to do the best work of our lives, together. #### Our office: 401, Tower 4, DLF Corporate Greens, Sector 72A, Gurgaon, Haryana. #### Working hours: 10:00 AM to 7:00 PM, Monday through Friday. ## Requirements ### Experience 1 - 3 years ( or equivalent ) ### Technologies - Python, Django - HTML, CSS, Javascript, Jquery - Bootstrap, CSS Preprocessors - Linux / Unix ### Skills - Software design and architectural skills. - Basic understanding of JAvascript frameworks. ( React / Vue / Svelte / Angular ) - Understanding and familiarity with database design. - Familiarity with UNIX / LINUX. - Familiarity with API design and principles. - Experience integrating with third party services. ( Twilio, Postmark, Sendgrid, Hubspot, etc. ) - Basic Experience / knowledge of containerization, container orchestration. ( Docker, Docker Swarm, Kubernetes, Nomad ) - BAsic Understanding of different clouds - AWS, GCP, DO, ABC. ### You - *prefer* to work in a start up, and join as the first technical employee. - are exceptionally motivated, and are looking to grow into an exceptional full stack developer. - are comfortable working independently, taking responsibility, and are self driven. - are looking to design beautiful products that you are passionate about, and proud of. - are not scared of challenges, new technologies. - are exceptionally comfortable with computers and computer science. - agree with our good - bad list. ## Good / Bad List 1. A good developer **knows how to code well and is passionate about their craft**. They care about the quality of the code and work hard to maintain it. A bad developer creates technical debt by sacrificing quality to meet a delivery deadline. They don’t keep other developers in mind when writing code and fail to make it easy to understand their work. 2. A good developer **tests their own code instead of relying on QA to find every bug**. Having said that, they value the safety and self-documenting properties of automated tests. They plan for ways in which their new work can introduce issues and have a plan B. A bad developer fails to document their work. They never ask for a code review for changes they make and have no interest in reviewing other people’s code. A good developer is independent enough to know when the time is right to include others during a project. A bad developer sits on their hands after running out of tasks or hitting a roadblock. They fail to find consistency with existing code structure when making code updates or changes. 3. A good developer is **motivated by the success of their project**. They keep the user in mind when building features. They are **innovative in their thinking** and think about the future to see the patterns of issues their systems and customers could encounter. They build long-term solutions for these issues. A bad developer puts technical correctness above user experience. They blame customers for not using the product "correctly.” A bad developer fails to take ownership and responsibility for the entire product and bugs. They make sure everyone knows exactly who was responsible when a bug was created by someone else. A good developer makes sure that the team is in tune with what is being released. They work closely with marketing and customer success to ensure that everyone is ready for each release. A bad developer releases work before the marketing and success team knows and therefore causes issues for customers. 4. A good developer **is eager to learn new things**. They strive to understand how all the pieces of the architecture work together and what state they are in. **They question the design and ideas behind features** to solve for a solution. They understand what makes a good user experience. A bad developer is attached to their favorite technology. They think a single method or process is the "ideal,” and that product history and situation should never drive decisions. They bring unnecessary dependencies into the project to suit their preferences. 5. A good developer **can communicate issues across the team** as they happen to avoid internal confusion and customer frustration. They are glad to listen to advice and feedback. A bad developer is unwilling to shift their focus from whatever they’re doing to a help a customer in need. They lack empathy for customers and users. A good developer **works closely with other team members** to make sure nothing gets lost in translation. They are a good teacher and share their expertise with the rest of their team. A good developer respects other people's time. They pull together all the background info before sending a task to another team member. A bad developer fails to specify needs and expectations from other teams ahead of time. They are reluctant to help other team members. A bad developer blames other factors when their code causes an issue or fails to solve a problem, for customers, or their project. 6. A good developer knows how to estimate their time on a task and makes sure they **finish their work in a reasonable amount of time with realistic deadlines**. They prefer to use existing solutions, but **aren’t afraid to invent something new** if it's necessary. A bad developer creates stress for themselves and for the team by failing to prioritize their time. They will spend weeks on unnecessary work because they failed to ask insightful questions before getting started. A good developer builds for project performance. They build within limits and always consider memory, storage, I/O, and network functions. A bad developer complains about the limitation of their resources. 7. Good developers assume that what exists was designed with thought or prior reasoning in mind. A bad developers assumes the previous author was unqualified and aims to change things instead of understanding history. A good developer doesn’t strive for change to benefit their personal presence, and **know the difference between standing on preference and principle**. Bad developers crave complexity to maintain control. They don’t recognize the difference between naive shortcuts and simplicity.