Audition for the Role of Architect: Introduction

I came across an old email with an invitation to an interview. With yellowed gifs in the signature and expired sealing wax of certificates. It's an old story, pandemic-related, so I think I can tell you about it. I'm the only one who doesn't look at deadlines NDAwhen I sign? Just in case, it's worth depersonalizing and redoing. Especially since there is no bonus for brand promotion, and punishment will always be found. So here we have an anonymous club for hiring people who look like architects.

Vasya Lozhkin and his anonymous club.

As always, I will share my personal experience and impressions in a toxic way. There will be no “correct” answers. There will be mine. If you think that there is a correct architecture, then it is too early for you to come here. Did I warn you about toxicity? My Napoleon complex is fueled by the positive result of the interview, growth and a cocked hat. There could be a link to courses here. Or therapy. Or sports betting, since I did not accept the offer, and looking at the news and the falling price of their shares now – I see the future! In fact, I saw a better offer from another company, but that's another story.

The interview… The interview doesn't change.

First, let's figure out the process. The beginning is standard – bait from the recruiter. A phone call with a general description of the company and the role: a replacement is needed for a team of 4 D'Artagnans. A well-known and stable company, a successful B2B product that has not yet become covered in cobwebs, but has begun to crumble and the dust is settling on the profit. And it is also not sexy and they do not want it. Enterprise is a world of old people (or is it correct to say alternatively young people?), and they all look at those who are younger. Therefore, the development of next-gen is in full swing, and apparently the musketeers, since one could not stand it. Since my track record already has a couple of notches with the processing of legacy and migration to a new brave world, I can try on the service of the king. Moreover, I am pretty tired of the gray cardinal at my old place. Then a standard interview with the hiring manager. No, about GOF don't ask. My resume, whiskers, paws and tail answer such questions. They talked mostly about my past experience: what problems I encountered; when I was last on the B2B market; technologies and processes that I don't know and, of course, about my values ​​in non-monetary equivalent. All companies are unique, but they all want to fangy-mangy. If this is your first time, then dress in everything clean and get ready in advance. Inventing battles with unicorns is not my thing. I gave out what I knew. Experts advise embellishing, but I am not an expert. I may have to work there later. And experience tells me that someone who could not become an architect for stakeholders can become a full stack for architects, for the same high price.

Attention, black box!

And here is the main stage – Panel Interview. Yes, this is when you are brought to the panel and you need to stand out so that you are chosen from all the industry workers presented. This is almost standard practice. In this company, however, there are rather strict customs. Everything happened via Zoom in 2 stages. It started in the morning. The committee – all those 4 architects, the manager and HR. Everyone says a few words about themselves, about the project and all sorts of little things. Actually, a kind of culture fit test. You see those with whom you will directly, perhaps, work, and they see those who are still easy to get rid of at this stage. And then they announce the task: “In a few minutes, a document with a diagram of the old architecture and an invite to the next Zoom in 4 hours will fall into your mailbox.”

Tasks:

  1. Analyze the current architecture and identify the main business requirements (literally: the problems that it solves).

  2. Tell us about the disadvantages and problems of this solution. Give an assessment of the system.

  3. Offer your solution that could support the new requirements (no one has voiced what, apparently they are looking for a very smart person).

  4. Make a presentation (no more than half an hour) for the committee.

  5. Be prepared to defend your decision and answer additional questions.

- This is not your architecture. This is not even my architecture. This is their architecture.

– This is not your architecture. This is not even my architecture. This is their architecture.

Description of the task:

The system receives a recorded audio/video data stream from the operator, who also adds various metadata. The recording and data are saved in a repository (orange block), where the processing process (yellow block) periodically looks. This process raises various handlers (blue), which analyze the data and add their results to the meta of the same recording. The handler can work for several minutes to generate a result. Another process – categorization (green block), with a lower frequency (but not less than once every half hour), looks into the repository and applies various rules to the metadata of the new recording. A recording can match (satisfy the rules) several categories. If there is a match, a call is made to the configured API.

Diagram:

Legacy session processing: input stream->repository->processing engines->categorization->callout” title=”Legacy session processing: input stream->repository->processing engines->categorization->callout” width=”704″ height=”438″ data-src=”https://habrastorage.org/getpro/habr/upload_files/54d/f8b/ea4/54df8bea4bc61f698091176c950de911.jpg” data-blurred=”true”/></p><p><figcaption>Legacy session processing: input stream->repository->processing engines->categorization->callout</figcaption></p></figure><p>Restrictions:</p><p>Two blocks remain unchanged forever – the black square (recorder) and the Categorization configurator.  One is most likely tied to hardware, and the other, apparently, is some kind of No-Code UI that the user knows and loves.  So these two gravestones are our starting point.  In honor of entropy and the second law of thermodynamics, of course!</p><p>What I remember from the farewell talk, but is missing from the task file: the handlers finish at different times and do not always return the result. The categorization of the record can occur several times, but the subsequent call to the IP address should not be duplicated. That is, if we made a call to category A, and later it turned out that the record has categories A and B, then we need to additionally call only B and, if available, AB. Everyone's favorite <a rel=exactly once.

Tests.

Of course, I read about the company beforehand, but there were only marketing materials. In general, it was clear that they provide some services for processing sessions with operators. Now it became clear that this is not online, but processing of the recording after the end of the stream. Something like:

  • take a recording of a lecture about IT

  • run it through analyzers (participation activity, involvement, duration)

  • collect the resulting analysis into groups (IT, interesting, distance learning)

  • send by subscription (interesting in IT)

Only it's completely different and not like that.

Apparently there are many customizations and extensions for the client, which is actually a standard in B2B. There is a platform and a set of tools (the same processors). There is BRMS (categorizer) and integration points (called by APIs). The attached diagram was even worse than what I drew here (just 5 blocks with labels for three stages of processing). Most likely they didn’t bother too much and made a sketch for the interview. Although, maybe they are just bad with the old documentation. Which adds to the anxiety. Because my experience clearly shows that clients will not want to move to a new system if all the old functions are not there. This means that they will have to drink Legacy live and blindly.

There are practically no details of the work, as well as any mention of technology. It's not even clear what kind of repository this is. This is important for two reasons:

  • Any assumptions and suppositions should be documented. And since the input data is almost empty, you need to think out a lot. This will justify the decisions and will help with additional questions during the project defense. Some questions can be initially cut off by setting your own additional condition. Let's say that the original records cannot be stored for more than 6 months, which means you don't need to think about data security policies, retroactive analysis, all sorts of graphs and reports for years back. Here you will definitely be asked: “Why exactly 6 months?” And what does that mean? It is necessary to prevent this question with another assumption: the source of the record is anonymous (there is no possibility of implementing “the right to be forgotten“), but we want to work in the GDPR zone. With anonymity, any entry immediately becomes inactive (the inactive user standard is 6 months of inactivity). To store data longer (from a year to two), you need to warn clients and justify the need to the regulator. The subtleties of the interweaving of legislation and technology are like a joke among our own (something that evokes ancient emotions among Harold).

Hide the pain Harold meme

Hide the pain Harold meme

  • Despite the fact that we are at the level of creating an iconostasis, we will have to avoid the names of our former ones. Technologies. Here is the drama – they are looking for an architect for an existing team for an ongoing project. The last thing an employer wants is to hire a person with inappropriate experience, who will have to be trained for a long time and tediously, instead of quickly and efficiently operating. Not guessing the technologies in their legacy is as dangerous as not matching the tech stack of a new project. They did not indicate anything in the diagram, which means it is worth operating with general names. Like not MSSQL, but on-prem Relational DB. It is worth preparing a couple of examples for each guess and choosing the right one as the cards are revealed.

Consider circumstantial evidence – if the first calls were in Teams, then you should expect a Microsoft stack. AWS – Chimes, Google – Meet. Cisco Webex is not used by software companies: “Astrologers announce a telecom week: +1 to Java, +1 to *nix-s.” Nonsense, I do not believe in astrology! I believe in recruiters. Searching for ads from an employer we are interested in will immediately show you the range of specific technologies in demand by them. It is worth doing this before the interview, so as not to be disappointed after the fact.

Dogma: scene with Desert Eagle

Dogma: scene with Desert Eagle

Usually you are given a presentation template, thereby indicating what and how they want to hear. Not in this case. So the presentation is yours, but steal the color scheme and logo from the company's official website. This is a kind of clothing, and I would like the first impression to be deceptively positive.

Consider the time – I was given half an hour for the presentation itself. And it is necessary to fully show and tell the answers to all questions. This means you shouldn’t invest too much in the details. Most likely, questions regarding legacy are not the most important. They just want to make sure you understand what they don't want to see in the new product. So it’s worth planning your time so that:

Speaking of time, 4 hours is all you have to work through all the points. So get yourself covered from head to toe Agile and start immediately thinking about a presentation or some kind of online board. You should have material to demonstrate whenever the clock is stopped by the notification that a call has begun. The details can be discussed, but the thesis and the diagram are the basis.

The rest in the next episode. If you show interest. Although, who am I kidding – I myself am interested to know how it all ends. Well, what a graphomania.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *