This was interview in so called startup.

BTW I don't get point in company calling themselves as startup when they are 5-6 years old, just call your self small sized company.

1 - online interview with HR, Normal.

2 - online technical interview - 1 hour of discussion with Lead.

3. On-fucking-site technical interview - ~1 hour of detailed technical discussions.

4. Coding task- submitted successfully

5. Zoom meeting to discuss on coding task - just told it was good and started discussion on their dead project which was unrelated to job position but I've worked with that kind of thing so it was fine.

6. Trial Day Onsite - Gave me to draw a fucking BPMN chart - fuck you motherfuckers - I knew it was waste of time.

Fuck this kind of Hiring process which takes >1.5 month.

Who the fick asks for BPMN diagrams, Disaster Recovery diagrams and Business Continuity Plan for a SaaS product that is deployed in cloud (Azure) ??

This is a simple app/dashboard that just showcases some data in fancy charts. It shows the data YOU feed. Why do you need BPMN diagram? What am I supposed to put? "Client loads data" and "user sees data"?

I already linked Azure's page on DR. Do yiu want me to copy-paste the contents from that link?

Clients are too much PITA!!!

!rant (I got down voted for this on Stack Overflow, so I try to discuss the issue with a more professional crowd.)

In a Software Engineering class, we had an assignment to read Parnas' seminal paper on modularization [0]. In this paper, two approaches of dividing a software into modules are discussed:

Traditional Approach: A flow chart is drawn to work out the single processing steps and the program's high-level flow. Then every processing step is turned into a module. This approach doesn't yield very good results.
New Approach: Every design decision will be turned into a module by the means of information hiding. This approach leads to much better results.

My personal interpretation of the term design decision is that the modules are identified as data structures rather than as processing steps of an algorithm. This makes sense, because data structures are much more suitable for information hiding then processing steps of an algorithm. (The information inside a data structure is hidden behind functions, whereas a function only hides more detailed processing steps and no information; the information is actually passed in as arguments.)

Why does the second approach work so much better than the first approach? Here comes my second interpretation: The single processing steps of an algorithm are not replaceable (and thus not reusable), whereas it's possible to convert data structures into other data structures.

And here's my question: Could that be the reason why software development using workflow engines (based on BPMN, for example) never really took off?

My personal experience is that the activities created in such workflows are hardly ever reused, but there often are big data structures passed around all the involved activities, even if most of the activities use only one or two of them.

My question exaggerated: Could we get rid of all those clumsy workflow engines by giving managers Parnas' paper to read?

[0]: On the criteria to be used in decomposing systems into modules (Parnas 1972)

I had to write a js bpmn flow designer for a huge bpmn app on request and my crazy brain said fuck it I can do it in 2 months, let's just say I made my deadline with school and all. And it actually worked very well it needed only a bit of bugfixing when it hit QA.

Ok so I have a software quality exam tomorrow and I'm studying the theory the teacher gave us. This thing is repeting all the time that the best way to ensure quality is by using BPMS (Business Process management Systems) like Bizagi and the one from IBM, which generate software apps without coding, just defining processes. What do you guys think about this?