A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms. Software architecture refers to the high level structures of a software system, the discipline of creating such structures, and the documentation of these structures.
Originally published on FullStack.Cafe - Never Fail Your Tech Interview Again
Q1: What does “program to interfaces, not implementations” mean?
Topic: Design Patterns
Difficulty: ⭐⭐⭐
Coding against interface means, the client code always holds an Interface object which is supplied by a factory.
Any instance returned by the factory would be of type Interface which any factory candidate class must have implemented. This way the client program is not worried about implementation and the interface signature determines what all operations can be done.
This approach can be used to change the behavior of a program at run-time. It also helps you to write far better programs from the maintenance point of view.
🔗Source: tutorialspoint.com
Q2: What are the differences between continuous integration, continuous delivery, and continuous deployment?
Topic: DevOps
Difficulty: ⭐⭐⭐
- Developers practicing continuous integration merge their changes back to the main branch as often as possible. By doing so, you avoid the integration hell that usually happens when people wait for release day to merge their changes into the release branch.
- Continuous delivery is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. This means that on top of having automated your testing, you also have automated your release process and you can deploy your application at any point of time by clicking on a button.
- Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change to be deployed to production.
🔗Source: atlassian.com
Q3: What does SOLID stand for? What are its principles?
Topic: Software Architecture
Difficulty: ⭐⭐⭐
S.O.L.I.D is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin.
- S - Single-responsiblity principle. A class should have one and only one reason to change, meaning that a class should have only one job.
- O - Open-closed principle. Objects or entities should be open for extension, but closed for modification.
- L - Liskov substitution principle. Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.
- I - Interface segregation principle. A client should never be forced to implement an interface that it doesn't use or clients shouldn't be forced to depend on methods they do not use.
- D - Dependency Inversion Principle. Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.
🔗Source: scotch.io
Q4: What Is BASE Property Of A System?
Topic: Software Architecture
Difficulty: ⭐⭐⭐⭐
BASE properties are the common properties of recently evolved NoSQL databases. According to CAP theorem, a BASE system does not guarantee consistency. This is a contrived acronym that is mapped to following property of a system in terms of the CAP theorem:
- Basically available indicates that the system is guaranteed to be available
- Soft state indicates that the state of the system may change over time, even without input. This is mainly due to the eventually consistent model.
- Eventual consistency indicates that the system will become consistent over time, given that the system doesn't receive input during that time.
🔗Source: fromdev.com
Q5: What Is CAP Theorem?
Topic: Software Architecture
Difficulty: ⭐⭐⭐⭐⭐
The CAP Theorem for distributed computing was published by Eric Brewer. This states that it is not possible for a distributed computer system to simultaneously provide all three of the following guarantees:
- Consistency (all nodes see the same data even at the same time with concurrent updates )
- Availability (a guarantee that every request receives a response about whether it was successful or failed)
- Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system)
The CAP acronym corresponds to these 3 guarantees. This theorem has created the base for modern distributed computing approaches. Worlds most high volume traffic companies (e.g. Amazon, Google, Facebook) use this as basis for deciding their application architecture. Its important to understand that only two of these three conditions can be guaranteed to be met by a system.
🔗Source: fromdev.com
Q6: Do you familiar with The Twelve-Factor App principles?
Topic: Software Architecture
Difficulty: ⭐⭐⭐⭐⭐
The Twelve-Factor App methodology is a methodology for building software as a service applications. These best practices are designed to enable applications to be built with portability and resilience when deployed to the web.
- Codebase - There should be exactly one codebase for a deployed service with the codebase being used for many deployments.
- Dependencies - All dependencies should be declared, with no implicit reliance on system tools or libraries.
- Config - Configuration that varies between deployments should be stored in the environment.
- Backing services All backing services are treated as attached resources and attached and detached by the execution environment.
- Build, release, run - The delivery pipeline should strictly consist of build, release, run.
- Processes - Applications should be deployed as one or more stateless processes with persisted data stored on a backing service.
- Port binding - Self-contained services should make themselves available to other services by specified ports.
- Concurrency - Concurrency is advocated by scaling individual processes.
- Disposability - Fast startup and shutdown are advocated for a more robust and resilient system.
- Dev/Prod parity - All environments should be as similar as possible.
- Logs - Applications should produce logs as event streams and leave the execution environment to aggregate.
- Admin Processes - Any needed admin tasks should be kept in source control and packaged with the application.
🔗Source: 12factor.net
Q7: What are Heuristic Exceptions?
Topic: Software Architecture
Difficulty: ⭐⭐⭐⭐⭐
A Heuristic Exception refers to a transaction participant’s decision to unilaterally take some action without the consensus of the transaction manager, usually as a result of some kind of catastrophic failure between the participant and the transaction manager.
In a distributed environment communications failures can happen. If communication between the transaction manager and a recoverable resource is not possible for an extended period of time, the recoverable resource may decide to unilaterally commit or rollback changes done in the context of a transaction. Such a decision is called a heuristic decision. It is one of the worst errors that may happen in a transaction system, as it can lead to parts of the transaction being committed while other parts are rolled back, thus violating the atomicity property of transaction and possibly leading to data integrity corruption.
Because of the dangers of heuristic exceptions, a recoverable resource that makes a heuristic decision is required to maintain all information about the decision in stable storage until the transaction manager tells it to forget about the heuristic decision. The actual data about the heuristic decision that is saved in stable storage depends on the type of recoverable resource and is not standardized. The idea is that a system manager can look at the data, and possibly edit the resource to correct any data integrity problems.
🔗Source: jboss.org
Q8: What Is Shared Nothing Architecture? How Does It Scale?
Topic: Software Architecture
Difficulty: ⭐⭐⭐⭐⭐
A shared nothing architecture (SN) is a distributed computing approach in which each node is independent and self-sufficient, and there is no single point of contention required across the system.
- This means no resources are shared between nodes (No shared memory, No shared file storage)
- The nodes are able to work independently without depending on each other for any work.
- Failure on one node affects only the users of that node, however other nodes continue to work without any disruption.
This approach is highly scalable since it avoid the existence of single bottleneck in the system. Shared nothing is recently become popular for web development due to its linear scalability. Google has been using it for long time.
In theory, A shared nothing system can scale almost infinitely simply by adding nodes in the form of inexpensive machines.
🔗Source: fromdev.com
Q9: What Does Eventually Consistent Mean?
Topic: Software Architecture
Difficulty: ⭐⭐⭐⭐⭐
Unlike relational database property of Strict consistency, eventual consistency property of a system ensures that any transaction will eventually (not immediately) bring the database from one valid state to another. This means there can be intermediate states that are not consistent between multiple nodes.
Eventually consistent systems are useful at scenarios where absolute consistency is not critical. For example in case of Twitter status update, if some users of the system do not see the latest status from a particular user its may not be very devastating for system.
Eventually consistent systems can not be used for use cases where absolute/strict consistency is required. For example a banking transactions system can not be using eventual consistency since it must consistently have the state of a transaction at any point of time. Your account balance should not show different amount if accessed from different ATM machines.
🔗Source: fromdev.com
Thanks 🙌 for reading and good luck on your interview!
Check more FullStack Interview Questions & Answers on 👉 www.fullstack.cafe
Top comments (22)
I've mentioned this in previous posts -- I applaud the effort here. But I hate that we interview this way. I really, really, really hate it. Let's take the question about SOLID.
Why do we ask candidates this question? Are we trying to see if they grasp the concepts of OOP? Or do we care about the candidates ability to remember mnemonics?
There are much better ways to figure out if candidates understand OOP. Like... why don't we show them a function that has massive side-effects or that does too many things and ask them how they'd improve on it?
And honestly, if a firm can't figure out if a candidate meets baseline technology competence in 1 or 2 coding interviews, it is doomed. If a firm is bringing a candidate in for a very expensive 4-5 hour loop and wastes all of that time doing coding interviews as in a manner that would be more fitting of an oral examination at university, then they aught not to wonder about all the candidates that turn out to be bad behavioral fits for their company core values.
I agree with your concern, but also want to point out that SOLID principles does not apply to OOP only, but for Functional Programming as well as more higher-level design such as system architecture. If you take a look at the 12-factors, most of the concepts can be compared to SOLID principles as well as Q8 about nothing shared architecture.
So SOLID is actually a more general approach and the awareness of it is particularly useful. Maybe if the expected answer shouldn't be what every single one of them means, but maybe with examples of how applying those can help with building a better architecture/system/code.
You are correct. I shouldn't have gotten hung up on OOP. But my point still stands: Do you care about the ideas or about the acronym?
What about candidates that come from coding academies, or that went to school in non-english-speaking countries? If they understand the concepts but have never heard the acronym, are they at a disadvantage?
My guess here is that you will say "No, or course not", but that the very nature of the question itself will create scenarios where the candidate acts uncertain, and this will cause unconscious bias in your impressions as the interviewer.
But it's also means they don't speak the common idiom and it's going to be harder to integrate into the team/project/culture. It sucks to filter out those kind of candidates, but it's a heuristics to filter some candidates in case you have a lot. Depends on what kind of role you're looking to fill.
I agree it's not perfect, but it's a trade-off.
I would propose that if the idiom is so important to the integration of people into your team and culture, that your team and/or culture is exclusionary, and you have a much bigger hiring and staffing problem than "how to effectively interview developers".
Idioms and Acronyms that are unique to the team/firm are something every new hire has to deal with, but it's usually not hard to get up to speed, all it takes is an atmosphere where colleagues welcome questions (i.e. a "there are no stupid questions" attitude).
I agree with that, but that's the only differential in a candidate that is put to a scale, you choose the one that knows, so it's a priority criteria and not an exclusion one.
And you can say SOLID is not unique to team/firm but a more broad one. It's definitely weird to ask a candidate about unique stuff for your company (I've seen it and you shouldn't)
Respectfully, I think that's a poor criterion even as a "priority vs exclusionary" one - seems the risk is high - or at least makes the selection completely arbitrary - of missing on the better candidate on the basis of not recalling an acronym, which carries no practical value when the candidate understands and practices the concepts it represents. I truly hope not many think the way you do, and I mean that as kindly as possible. But something so trivial should never be "the only differential in a candidate" - you ought to find some more meaningful way to distinguish candidates if you want to be successful.
I'm an engineer not a name dropper. Have I seen or read abou all of the above at some point. Yes, along with a gazillion other things. Have I memorized persons, item lists, definitions, etc. involved. No. Does that make me a bad architect?
You are asking the wrong questions. Instead of asking people to be a nice school boy, sit up straight, and define the five solid principles, ask them to talk about coupling and cohesiveness in relation to good system design. Ask open questions like that and see if something sensible comes out. Bonus points if they name drop some SOLID principles. Hint, if you understand both metrics, you'll realize that SOLID primarily drives both of those and why these are important. The goal is not verifying that they name drop whatever you think is fashionable but whether they can talk in a sane way on these topics. Ironically, you can sniff out the bullshitters easily because they will start name dropping things they don't really understand. I've seen this happen a couple of times in interviews.
Asking open questions and maybe leading the conversation is a much better way of figuring out what a person knows, and whether maybe they know something you did not know. Figure out what drives them. What they are passionate about. Don't be that B hiring Cs. You need to be looking for As. That means you need people that add something to your team that you don't yet have.
And another reason of the huge flaw in our current structure for interviewing people.
Most, if not all, of these questions don't tell me at all if you are what I'm looking for. All these tell me is that you know and remember buzz words
Wow this looks like a college test
Many negative reactions to this but no proposal for a better way to interview in tech... Every style of interview is flawed (whiteboard problem solving, homework technical case, onsite technical case, technical conversation) it just depends on what you are looking for. The only reason i have had for a person to know definitions of technical words is if they put it on their resume... If it's on their resume they should know what those words mean. I have never asked the question "what is unit testing" if unit testing was on candidate resume during the interview i will ask how he resolved technical challenges that comes with unit testing complex software or components to understand 1/if he knows what a unit test is 2/his reasoning around unit testing etc... that would be the same for SOLID or Consistent hashing if it's on your resume you should be able to know what it is and use it in your reasoning around architecting a system etc... not a perfect method anyway, but i have had the luck that every people i have recruited with this method have never been scrubs.
I've never done interviews but based on my point of view as a developer, I think that's the best way to assess a candidate. You should ask questions about his experience. Anything he puts on his resume is fair game. A programmer's task is programming, not knowing about everything about every programming languages or concepts in the universe. You should ask him how he program, how he goes from getting a task and implementing a practical solution by following enterprise pattern. But you need a good technical interviewer to help with this.
Thank you very detailed painted. I think you will be interested in this article about medical app development.
Since no one else mentioned it... you lost my attention by the end of Q1. Asking about coding to interfaces is a great question, but has absolutely nothing to do with factories.
If you need to design 3D software architecture diagram, you can try iCraft Editor : icraft.gantcloud.com/editor
"ATM" already has "machine" in the last letter, no need to duplicate that 😜 Nicely copied together though, thanks 👌
The title might be a little bit misleading but really appreciate the content. Never heard/have no idea some of the term. At least I can look at this post later as a cheatsheet 😁
And that is precisely the problem with interview questions like this - they beg for people to have a "cheat sheet" so they can talk about these things without really having a full understanding and being able to talk intelligently about them. I'd rather someone that doesn't know the acronyms but understands and practices the concepts.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.