4 ms·

Regarding 4 - in the full version shared by the author at https://archive.md/A95Ju https://archive.md/A95Ju there is info on what they meant by "terminal-inspir

Regarding 4 - in the full version shared by the author at https://archive.md/A95Ju https://archive.md/A95Ju there is info on what they meant by "terminal-inspired"

minikomi 1y ago
It seems they wanted "keyboard driven", "fast/light", "quickly interactive" The youtube video provided by the OP seems more "web-app", "click driven". For contrast: * The OP's submission: https://www.youtube.com/watch?v=yY1sVXMkP_o https://www.youtube.com/watch?v=yY1sVXMkP_o * Someone interacting with aerc: https://youtu.be/kpAwwgnZUxg?t=308 https://youtu.be/kpAwwgnZUxg?t=308 * Someone interacting with mutt: https://youtu.be/C35NRp42bEQ https://youtu.be/C35NRp42bEQ
- MeetingsBrowser 1y ago
  > It seems they wanted This is the problem. Your guess is different from the author's guess, because nothing is explicitly stated. For others who did not click the link, the explicit requirements are: > - Email client can either be in the terminal (i.e. a TUI) or a web app > - Should have basic email viewing + sending functionality > - Can use a fake backend (DB, in-memory, etc) or real IMAP/POP/JMAP/etc backend > - Does not have to handle rich text messages, just plaintext > Your implementation should take inspiration from existing terminal email tools like aerc, mutt, or even something like himalaya. It should feel fast and intuitive, and you can choose which email flows you'd like to implement. The word "keyboard" does not appear. Inspiration from X, Y, and Z is entirely subjective, and you should not be punished for not reading the interviewer's mind.
  - stephen_g 1y ago
    Is it not clear that every single one of the example apps the spec cites are text-based UIs, as in curses-style, monospace text, and (yes) keyboard-driven? My takeaway from that is that if you don't make an app that is (quote) "in the terminal (i.e. a TUI)" but choose to make a web app, then it should look at act like a TUI.
  - Rastonbury 1y ago
    What I got from that is "fast and intuitive" is the must have. When you have a choice (backend bit), justify you decision. I'd try to use that to stand out or an additional cool feature. When I have to do such homework, I do the requirements to what I think an above average candidate would, they've seen this a million times, then add 1-2 bits of flair/coolness only a handful of people would do to pique their curiosity and want to ask about the next round
brudgers 1y ago
Reading the brief, the simplest thing that might work is: 1. Spin up an EC2. 2. Install Himalaya. 3. Do some configuration. Code quality and a sound engineering approach are there. Personal touches aren’t. Though they look for them, absent domain knowledge they probably don’t want to see them. Himalaya has documentation and a Github already. No need to invent the wheel. Won’t take an unreasonable amount of time. And looks like a first iteration of a tool.

Regarding 4 - in the full version shared by the author at https://archive.md/A95Ju https://archive.md/A95Ju there is info on what they meant by "terminal-inspired"

minikomi 1y ago

It seems they wanted "keyboard driven", "fast/light", "quickly interactive" The youtube video provided by the OP seems more "web-app", "click driven". For contrast: * The OP's submission: https://www.youtube.com/watch?v=yY1sVXMkP_o https://www.youtube.com/watch?v=yY1sVXMkP_o * Someone interacting with aerc: https://youtu.be/kpAwwgnZUxg?t=308 https://youtu.be/kpAwwgnZUxg?t=308 * Someone interacting with mutt: https://youtu.be/C35NRp42bEQ https://youtu.be/C35NRp42bEQ

MeetingsBrowser 1y ago
> It seems they wanted This is the problem. Your guess is different from the author's guess, because nothing is explicitly stated. For others who did not click the link, the explicit requirements are: > - Email client can either be in the terminal (i.e. a TUI) or a web app > - Should have basic email viewing + sending functionality > - Can use a fake backend (DB, in-memory, etc) or real IMAP/POP/JMAP/etc backend > - Does not have to handle rich text messages, just plaintext > Your implementation should take inspiration from existing terminal email tools like aerc, mutt, or even something like himalaya. It should feel fast and intuitive, and you can choose which email flows you'd like to implement. The word "keyboard" does not appear. Inspiration from X, Y, and Z is entirely subjective, and you should not be punished for not reading the interviewer's mind.
- stephen_g 1y ago
  Is it not clear that every single one of the example apps the spec cites are text-based UIs, as in curses-style, monospace text, and (yes) keyboard-driven? My takeaway from that is that if you don't make an app that is (quote) "in the terminal (i.e. a TUI)" but choose to make a web app, then it should look at act like a TUI.
- Rastonbury 1y ago
  What I got from that is "fast and intuitive" is the must have. When you have a choice (backend bit), justify you decision. I'd try to use that to stand out or an additional cool feature. When I have to do such homework, I do the requirements to what I think an above average candidate would, they've seen this a million times, then add 1-2 bits of flair/coolness only a handful of people would do to pique their curiosity and want to ask about the next round

brudgers 1y ago

Reading the brief, the simplest thing that might work is: 1. Spin up an EC2. 2. Install Himalaya. 3. Do some configuration. Code quality and a sound engineering approach are there. Personal touches aren’t. Though they look for them, absent domain knowledge they probably don’t want to see them. Himalaya has documentation and a Github already. No need to invent the wheel. Won’t take an unreasonable amount of time. And looks like a first iteration of a tool.