Allowed R6 · Within policy
{
"slug": "jobathon-technical-challenge",
"title": "Jobathon Technical Challenge",
"difficulty": "medium",
"tags": [
"system-design",
"frontend",
"oa",
"swe"
],
"is_free": true,
"locked": false,
"frequency": 0.5,
"last_reported_at": "2022-08-03T14:13:10.654900Z",
"url": "https://www.mokabla.com/en/c/kashier/jobathon-technical-challenge",
"agent": {
"page": "https://www.mokabla.com/agent/en/c/kashier/jobathon-technical-challenge",
"question": "https://www.mokabla.com/agent/_call/get_question?company=kashier&question=jobathon-technical-challenge"
},
"company": {
"slug": "kashier",
"name_en": "Kashier"
},
"body_md": "## What they ask\nKashier has hired through a one-day technical challenge (a \"Jobathon\") run with a government innovation centre rather than through a classic phone screen. The format: register online before the deadline, show up on the day at one of several hubs around the country (Smart Village in Cairo, Borg El Arab, New Assiut, Mansoura, Menoufia, Minya, Sohag), and work through a timed technical challenge in your discipline. The roles on offer were Full-Stack Developer, Android Developer, and Front-End Engineer, around eleven positions in total. Candidates who complete the challenge successfully are invited to a formal interview with the company.\n\nThe challenge content is not published. Given the product (a payment gateway with hosted checkout, payment links, and store plugins), a realistic full-stack version looks like:\n\n> Build a small \"payment link\" service: create a link for an amount and currency, render a checkout page for it, record a payment attempt with an idempotency key, and expose a webhook-style callback. Handle the obvious failures (expired link, duplicate submit).\n\nA front-end or Android variant would centre on the checkout screen: form validation, card number formatting and a Luhn check, loading and error states.\n\n## What they look for\n- Working software by the end of the day, with the core flow finished before any polish.\n- Payment-shaped thinking: idempotency, never trusting the client with the amount, clear states for a payment attempt.\n- Clean, readable code you can explain in the follow-up interview.\n- Speed under time pressure without cutting the error handling.\n\nIf you are targeting Kashier outside an event, expect the same themes in a normal technical round: integration with a REST payment API, webhooks, and checkout UX.",
"follow_ups_md": "- How do you make the webhook safe against replay?\n- What do you store when a payment attempt fails at the bank?",
"access": "Question bodies are paid content: a person buys 30 days of access per company (200 EGP or 200 points) in the human app. Agents get titles, tags and difficulty; bodies only for free questions."
}