Assignment Submission Guidelines

All applicants are required to follow submission guidelines detailed below. During the multi-stage evaluation process, your application can be rejected if we find that you haven’t followed guidelines.

🚨You won’t be allowed to re-apply if your application is declined for not following guidelines. 

1. Use rtLearn Repo for GitHub Code Hosting

We use git and GitHub at work. We expect all applicants to use both from the beginning.

Further, we use GitHub to review all code using some automation. For our automation, to work we require all applicants to create a GitHub repository using this special link — https://rt.cx/ghc-php. 

The above link creates a special GitHub repository under the rtLearn GitHub organization. We will refer to this repo as the rtLearn Repo throughout the process and guidelines. 

When working with rtLearn Repo, please ensure you adhere to following to avoid disqualification:

  1. Do NOT delete the .github folder. The folder has code that starts automated code review. One way to ensure that you do not delete this folder accidentally is to avoid git push --force.
  2. Do NOT delete/edit phpcs.xml file. This file tells the automated system to do a less stringent review of your code. If you delete that file, the automated system will do an in-depth code review that will likely result in a lot of feedback that you will need to process.
  3. Do NOT delete feedback branch. The code inside .github folder works on the feedback branch. If you delete this branch our automated feedback system will break.
  4. Do NOT close default pull request named Feedback. This pull request is where we wish to give our feedback. If you close this or mess up with the above pointers, we will have a hard time leaving our review on PR.
  5. Do NOT create new pull requests. This is the only thing that is different than how we work in real life. In real work, we do create PRs for every change we are sending for review. But in the rtLearn Repo, the default Feedback pull request will take care of it.
  6. Do NOT use GitHub web interface to uploads codes. Please use the git command for coding. If we see “Add files via upload” in commit messages, then we will assume that you have used GitHub’s web interface rather than git on your machine to work on the project.
  7. Update the website field of your rtLearn Repo with your live demo link. If you don’t which field we are talking about, you can check this screenshot below: (not needed because of discussion #97)

2. Write README

Write a nice GitHub Readme using markdown syntax. Make sure you include details about the problem you are solving, any assumptions you have made, a live demo link, and any other details useful for reviewers in the readme file.

While writing a nice readme can be subjective, if you do not replace the default readme file from auto-generated repo, then your application will be declined immediately.

3. Git commit messages

It is important that you are using git all along. One way we verify is that by going through your git commit history. 

If we find you have committed all code in a single commit, then it is likely that you have copied code from somebody else or simply started to use git at the end of assignment.

Since both are unexpected, your application will be rejected immediately.

4. Publicly accessible live demo

For Web Hosting, we recommend Heroku platform that provides a free tier that is sufficient to handle hosting requirements for the coding challenges mentioned above. So it is highly recommended to use Heroku hosting for live demo purposes. 

If for some reason, you are not able to get a Heroku account, you can try any other hosting. Please note that we won’t be able to accept assignments without a live hosted demo. Live demo is a must. Heroku is optional. You can also host MySQL separately using a service such as Free Remote MySQL.

Also, you are OK to set up a Linux server at home as long as you can ensure your machine has a 24×7 internet connection and electricity. Also, you will need a public IP or something like ngrok.

With so many hints given to you, if we do not see a public demo of your assignment, your application will be rejected immediately.

5. Email sending services

For email sending, you can use a service like SendGrid, AWS SES or anything that can get the job done. Most of these services are free. In some cases, they need a credit card to verify your account. 

If nothing above works for you, you can still use Gmail and it’s SMTP option to get the job done. During our testing, your application is unlikely to generate more than 20 emails going to one or two email addresses. Of course, if you have misconfigured something, then we can’t help you with that.

So as you see there are ways to get email going, if your assignment does not send us an email when expected, your application will be rejected immediately.

6. Do not use libraries or frameworks

Since the purpose of this assignment is to test your basic knowledge, you must not use any CSS or JavaScript framework. Not even Twitter Bootstrap. Not even jQuery. Even if you need to do AJAX calls, you should use native JavaScript code. 

The same restriction applies to PHP frameworks. No Laravel. No Symfony modules. Not even PHPMailer. 

You are more than welcome to use curl and php extensions for MySQL. It is also okay to copy relevant parts of code from existing libraries. 

But if we see PHPMailer, Laravel or any other framework, your application will be rejected immediately.

7. Live demo Link

Each assignment requires a live demo. Please use your private Github repo’s website field to specify your live demo URL (not needed because of discussion #97). Also, include the same live demo URL in your Readme.md content.

If you miss either, your application will be rejected immediately.

8. Avoid common mistakes

Please check list of a few common mistakes you need to avoid. If you miss out on any of the following, your application will be rejected immediately.

  1. Beware of SQL injection vulnerabilities. See BobbyTables.com and BobbyTables.com/php. (Sanitize input.) See filter_input() or MySQL sanitize strings or prepare() & bind() values.
  2. Beware of Cross-Site-Scripting vulnerabilities (XSS). (Escape output and validate input). This means don’t echo or print anything that might come from $_POST or $_GET (user input) without first stripping tags or sanitizing the value.
  3. Validate any email subscribe and unsubscribe actions with a verification token.
  4. Any Cron scripts or SQL dumps should be stored in non-public directories (outside of webroot). If Cron must be publicly accessible due to hosting constraints, then either rate-limit it to not run faster than every 5-minutes or protect it with a password.
  5. Don’t commit database credentials to the repository. Use examples. Use a configuration file for common/repeating settings such as DB credentials, email credentials, or “From” addresses. Include a SAMPLE configuration file with sample values.
  6. Use __DIR__, basename(), or both when using require or include. Starting from the current directory scans all folders in include_path.
  7. require and include are language constructs, not functions. Don’t use parenthesis.
  8. Don’t hard-code the server address or protocol. See $_SERVER.
  9. Use single-quotes if not parsing variables in strings in PHP.
  10. Be mindful of spelling and grammar for any message output.