@@hnasr so you pay to be a member even if you are the owner of the channel? how many subscribers do you need to have this feature? I really like it !!!! I want to use it!
FUN FACT - There are a lot of interviewers who want to show off their skills other than evaluating the candidate. Everyone is different and every problem can be solved differently. Thanks Nasser for speaking out loud. ✌️
I gave my first interview last week and it was just like this.I got the offer. My first job ! Thanks Hussein for awesome guides you have on your channel.When i watch your videos i more driven towards what i am doing .
Why would you apply for any job unless you are a Senior Developer? If you are unemployed you aren't good enough to work in the industry so why are you wasting peoples time?
I absolutely love your enthusiasm when you speak about the interviewer's response, and how their eyes open up. I actually am dying to have one of those conversations. Cant get past the recruiters though
5:15 Separate the frontend from backend, if you lag its front end. Separate reverse proxy and backend by using a mock db and a call with something like postman, if it lags its the reverse proxy. Make a raw call to the db if it lags its the db, or just find out by process of elimination. Several combinations can also be the cause but this is a simplistic answer to your question.
This is one of the questions that I ask when I take interviews. Not the exact question - but something similar where answers are open ended. Asking these kind of questions will allow even the interviewer to gain knowledge. Sometimes you get brilliant answers that you would have never even thought of before.
The same question to ask by my interviewer and the ans given by me is the same as he said in the video about optimising the query and adding indexing to the database and also talk about frontend. I have given almost 7 technical interviews and cracked each one without solving coding questions as he said getting the right code does not matter if you invest to develop something is important.
Unless it's an entry-level job, all questions should be general like this. It's virtually impossible to have good knowledge of all technologies, so not knowing something shouldn't be viewed as a bad thing - it's how you go about learning that is important.
If I gave this as an interview question, I'd expect the first part of the response to be a couple of clarifying questions, like.. Is it EXACTLY 60 seconds each time? When the UI "freezes" does it become completely and totally unresponsive? Those two alone will narrow it down a lot. If it is exactly 60 seconds each time to the millisecond then I doubt it will be a data access issue, even the in built query caching will be sufficient to return it faster the next time, and if the input variables change each time you would expect the time it takes to respond to also vary. The data is eventually displayed, so it's not going to be a timeout issue. If it's a WebUI and that's freezing, then you're maybe looping through an incredibly large data set which just happens to take 60 seconds to process. If it's an application UI freezing, you probably only have a single thread and you're going everything in there. From there there's still a huge amount of possibilities for what it could be, and an even larger of ways for testing for each of them. My money is on clicking the button sets a cron job to run in exactly 59 seconds, and takes 1 second to complete 😂😂😂
It is a JavaScript UI (React) and the Dev did a setTImeout(getData, 59000)... Thinking being that they can get a tuneup contract in 3/4 months and come in and just remove the setTimeout
@Hussein, I really love to hear you talking. You amaze me with your tremendous knowledge and keenness to learn new things. Software Engineering is a rampage now a days but you not only teach us new things but also how to become a calm, cool and a passionate Engineer. Kudos to you ! Please keep up the great work !
These is a very good question. Basically it will show how much the candidate understand how the internet works. And what their strong skill set are focused on. I basically stopped algorithm BS questions. I need to know if the candidate understands how the internet or how web/desktop application works plus the tools involved in them. I usually give simple but architectural complicated projects to my candidates which shows what tools they use, why they use it and how their code is structured. basically with a web browser information, you can easily know what froze the app, like if the whole DOM freezes to if the request gets stuck at connected to if the request gets stuck at receiving data. Chrome network log shows These information that you can use to suspect if it’s the frontend, proxy, Webserver or dB level
The generalist actually emerges as the most productive in the age of cloud computing. I think what your getting at in this vid is that fundamentals of software engineering doesn't boil down to just algorithmic questions , which I agree with. (learning algorithim was very helpful for me anyways)
Great question. Highlights how they approach problems and break them down. I’m a full stack bootcamp instructor. My students like to rush to writing code to fix an issue. I tell them slow down and walk through the whole stack to find the problem.
Love that you ask real world questions of things which would happen. I have always felt it is much better to just talk about the real thing you face in your company. If they can bring something to the discussion, excellent. If an interview is handled more like a conversation you get a much better view of the candidates and they can understand what they will be facing.
Using the sentence that the 'application freezes' clearly means the JS call stack is executing a blocking call which is causing this to happen. That is the only reason. Make your API call ASync and the app will not freeze. Now if you would tell the candidate that the 'API is taking 60 secs' to return the response then they could debug the backend services/proxy for the problem.
That's really a good way to assess a candidate instead of being a cocky interviewer by forcing the conversation in 1 direction which the candidate might not have worked on.
Great interview question! Thanks for sharing. I much prefer these types of interview questions over regurgitating something I learned in college a million years ago.
I think this is a damn good question. My personal short answer would be, distributed tracing tool is designed for this type of question. It will help you to identify how the request time is spent amongst all the microservices in the stack. If you don't have distributed tracing installed, then use mocking technique combine with binary search to first locate the service that has issue, and check the log, dive in.
Google has Dapper for distributed tracing and it is amazing. And but I totally agree. The FIRST step is identifying which layer in the stack is causing/suffering the latency. I would not be too excited about a candidate who immediately chose their favorite layer and then only talked about that. That's like the drunk trying to find his keys and only looks underneath the lamppost because he can't see anything anywhere else.
First thing I would do is to check where exactly the wait is happening, client side or server side. With Wireshark you can see if the reply from the server is taking a long time or not. If not, then I'll investigate on the client, otherwise I'll concentrate the effort on the server. On the server, split again between the database and the actual server application: a breakpoint should be enough to check this.
Good question Hussein! I like it very much because it really tests someone's troubleshooting skills. When you have a problem in Production that is affecting customers you need it solved as soon as possible and you definitely want to hire a developer who can do that. Knowing how to troubleshoot problems comes with experience and you can easily tell if someone has never done much of it before. It also amazes me when a developer won't even look at the available logs when there is a problem.
I'm watching right now, at minute 5:58, and I just found your question! My answer: From my experience, I would start by checking the base of the flow, specifically how the backend application maps objects from the database. Maybe we have a recursive mapping or something wrong there. After that, I would use Test-Driven Development and write a test in the backend application to check what is happening. Step 3: What is happening with the load balancer? I will check what is happening in the load balancer between the frontend and backend. BUT! If on my computer the call is faster, first of all, you might need to check the cloud infrastructure for your deployment. Which region has the database, which region has your services, and what resources are used for your deployments. YEAH! Very nice question. I would love to receive this in an interview!
Hussein, you truly inspire me and I hope to gather enough wisdom sometime in the future to do what you do and put my ideas and help other people on the internet.
one or two troubleshooting questions are great to understand how the person approaches a problem, his knowledge and work experience, and also how he approaches stuff he doesn't know and how it communicates that to others. I love them on both sides of an interview.
I will start this first principles thing by physically checking all the cables in all the routing paths from app to the user that will make me busy for awhile while. I might go down to a subatomic level just to check if everything's is alright back there. AS a old saying goes: "Trust but doublecheck".
@@JeemmaiThe interview was fine, even though I did not get the job that time. Got another one, though ;) Each inteview gives more experience and makes the next one easier. Good luck on your interview! 🙌
Also since the question BEGINS with the UI, that's where the investigation begins. First, you begin understanding if the latency traces back to the server. It doesn't mean front-end is your expertise or your crutch. If you start with database performance optimization you're flat out wrong. There's a logical order of progression.
Also ... having been working with backend stuff for 20+ years ... I must admit, I can't remember the details of quicksort on the spot, apart from it being some recursive bisection. I would say it's not important to memorize quicksort on the spot and be able to look implement it without looking it up ... it's more important to know that it's O(nlogn) with O(n2) worst case. - and where to look up the actual algorithm.
3 года назад+6
Even this is not important. You can look it up in a second.
This is the question I’d like to receive during my interview! I strongly agree with your approach. Giving open questions without one/two right answers gives a huge opportunity to discuss the topic and also allows interviewee to shine in some areas where they feel strong. I appreciate the video! And immediately subscribing. Cheers! 🙌
I actually took psychology after I had my EE degree. And the only great thing I learned there was: "ask open questions, you will get to see much more of a person, than asking for a single answer." And it's so true!
As a generalist, I got a good chuckle from this. All I 've got is a developed approach to attack that common real-life question. However, level of interest might not be a good gauge as some of us are numb across the board. We get excited once we find the root and deliver the goods.
There is no single place that you can pin on for performance issues. It could happen at several levels 1 ) Non indexed foreign key huge tables can cause it 2) Making api call and blocking UI Thread without calling the API async 3) Bad backend code which does not honour coding practises like sold principles, or design patterns. 4) Sending unessary headers 5) In Dot Net, sending native req tbough managed dot net pipeline. e.g Webconfig has property RunAllManageeRequest true. So when Websevers needs load some inage it will send it through dot net framework which is not necessary. The list goes on.
Check your drive for activity (cache overrun, reentrant logging), but based on 30 years experience the problem is in the database!! Next, your JVM needs more memory. Also, I think you can be actual full stack - but you have to spend years doing non-programming - a few years SQL development and maybe 5 as DB Admin, network manager, system admin, etc. And to be really good at backend, it helps to have built some front end level stuff. My best indicator of someone that will be fantastic is if they have a lab at home. Every single person that has something like a RaspPi cluster, or their own Kubernetes rack at home has been phenomenal and work far and above the normal 40 hour person.
that 60 second thing is the answer, you look for configs on each part of the stack for timeouts, keepalives, etc for that number (including dns! most people ignore that), if you find something, you start the hunt there...
And THIS is a great question and attitude towards job interview. Interviewee doesn't feel completely stupid and demotivated because he/she talked about the topic they know and just couldn't answer a question or two so he/she comes out of the interview with the feeling "Maybe I couldn't answer the second question but at least I got the first one. So maybe I'm not complete utter rubbish at this"
Wow, thank you so much for the great content, Hussein! This interview question really opens my mind, and it is also a great question to ask other people when we want to learn things from different perspectives. I just started learning backend engineering, and I've been following your tutorial. Thank you!!
Great video. An experienced engineer wouldn't try to guess. They would ask what telemetry or logs are available, and start isolating parts of the stack. You're right though, most candidates will gravitate towards what they are most comfortable with. But -- never troubleshoot or fix performance without metrics.
yeah except most companies have this inflated ego thinking that you will be building them this new dropbox and you have to know how to design an architecture for 500 millions users with millions requests a second just in case and also you will be starting at an entry position and at this bracket we expect you are working to gain experience aka you might as well pay us...
My first thought: Sounds like a blocking (sync) function somewhere is hitting a timeout (60 sec). I always log function calls with timestamps so I think I would figure it out pretty fast.
You probably get this a lot, but you honestly produce the highest quality content on backend engineering on RUclips. Thank you for all that you're doing to help the community!
JoRyGu i thank you very much for your words dear 🙏 gives me pleasure to give back to the community.. my favorite parts are the discussions on the comments section i love how each engineer contribute with valuable opinions that form interesting discussions
This is what I like about back end developers versus front end developers. A front-end developer will give you a list of fish to bring to an interview and instill the thought that without memorizing those you won't be able to get a job. A back-end developer however will teach you how to fish so you can feed yourself at the interview and potentially ace it. Much more logical and down to earth
I'm a Frontend developer. So personally I'd: first use something like postman and see if it still takes like 60sec to retrieve response if not then the Frontend is okay let's move on then is backend I'd check how log it takes to get to bd stuff like: app.get('/someroute', (req, res) => { console.time('xyz') /*None be stuff like validations, processing etc. goest here*/ console.timeEnd('xyz') /*Database stuff goes here*/ }) if none db stuff takes lot of time then we need to optimize backend codes else we'd need to check the database(relations, structures etc.) also I'd love to hear your desired answer
I so agree! I actually made a video "Why coding interviews suck" They don't prove anything! I also use open questions and I find things that I think they had trouble with in the projects they listed on their CV. When a person dives in to technical depth (not debt) I ask follow up questions and see how they dealt with issues. Then I know what part they've played and what I can expect from them. And I can cage where to put them in the team. Sometimes (like you said) you hear things and think: "They will fit even better on this part or even another team!" I much rather hire someone, who has no experience in the language or framework that we use but demonstrates the ability to think and problem solve. I know that they'll master that language or framework too. And I especially like it (and I hope they do) tie in their experience with the job outline I gave. I do that always when I apply for a project as freelancer. I am honest saying what I have no experience with but that I am willing to learn, and I drive home the experiences I have and they miss. I just joined a team who does SSIS/SQL reporting that needs to migrate to the cloud. I never worked with SSIS (and I don't care about it, and made that very clear) and I am not really a SQL backend developer (I use SQL only to select data and I can tune SQL, don't care for SQL stored procedures because it's ugly). But I know CI/CD, I know how to get COTS applications to conform to CD, all of them are different and all of them require specialized attention and we will figure that out. I have a wealth of infrastructure experience, not as much on Azure but that translates well, and a more than you have as we already ran on Azure with a COTS application. And I give reasons as to why they need IaC, and why they need to stop using SQL scripts to promote changes but start using dtproj file to build SSIS and use dacpac files. All terms they had never heard before. So they were like: "This guy doesn't know SSIS/SQL, but he's obviously a developer who has coded ETL and knows and demonstrated knowledge about packages of SSIS. And he knows CI/CD, IaC and is pragmatic in the approach fitting with out 15 year old application. And he comes from CISO. We call CISO and het a reference." Well the reference was good so I started the next week. Because sometimes things can sound too good to be true. I've done a lot and anticipated a lot and they just verified that with my former PO. And they were sold when he said: "He's coming back to this company? Why didn't he come back to CISO? I am a bit sad about that!"
My answer to your question? Check the logs. Heck, I say the same thing to my juniors all the time (and SQA people sometimes). The Front End logs should at least reveal whether the request was sent to the back end (and how long it took to send and how long it took to receive the response from the back end). So this will let you identify if the issue is on the front end. If it is a front end issue, then hopefully you have detailed logging that identifies which step is taking too long or debug step by step. If the issue is not on the front end then check the logs of the middle and back ends. Same thing. Detailed logging will at least tell you where or in which part the issue lies. Then debug or go through the code in that section. The really difficult problem is if the issue is not in the logs. Then I would suggest doing debugging from the start (front-end) and go through to the code (all the way to the middle/back) trying to identify which step is taking too much time.
I really liked the question , if it was me answering the question I would probably borrow some techniques for solving and troubleshooting networking issues which is based on making comparisons between the "normal" behaviour and the one we currently have starting from collecting the information about the situation without analyse anything, after collecting the informations from each part we can compare it to what a normal behaviour should be at that moment we can be quite sure about where we need to fix things.
I just paused when you asked the question then I try to answer it in my head and as it turns out I am more interested in backend lol as i majority of my answer was composed of something going wrong at the backend. you're right, I guess. this really tells you which way you lean on more if you are indeed a "full stack"
I remember watching this 3 years ago. Back then I was a Jr. dev and was not interviewing anyone. Now that I've started interviewing folks as a Sr. I always make sure to ask this question to the right candidates.
Remarkable, as a bug bounty hunter specializing in various aspects related to Web Applications, I find it incredibly intriguing to come across such discussions.
I would take a TCPDUMP on the client-side and on the server-side and analyze the time taken on the TCP handshake to make sure all good from the network latency perspective, then I will check the DeltaTime between the packets to understand which data is causing the delay. If there is a 60seconds delay from the server-side, next time I would take TCPDUMP in the application server and database server and again analyze what causing increased DeltaTime. This way we can finally get to the entity in the entire stack which is adding the DeltaTime taken of 60seconds, once we identify that then we can tweak its configuration or code accordingly.
The industry should understand this, as our current gen Software Engineering Interviews are more focused on Leetcode problems and Algorithms which a lot of candidates learn by heart from various courses. Yes having a good grasp of Algorithms is important for a SWE but in real world cases the person is going to develop & maintain software services, products. So it is important to know how much Architectural knowledge the person has or how to figure out with problems and come up with some optimize solutions.
One really great question to ask in an interview is, "What is the hardest software problem that you tackled and solved?" And then a related question, "What is the hardest software problem that you've attempted to solve but failed to actually solve?"
My answer would be, first i implement a waitng animation for the customer, which makes him feel comfortable. A nice processing animation or something similar. Then i check the api calls and see how long it takes to fetch the data, if this is fine then i look up in the frontend. If its not fine then will look up in the backend and look whats happening there. In the most cases its a serial chain issue. Some method waits to start and then another method wait for this method and so on. If I understand how it flows, i find the the bug. If not then I would ask another dev to help me to find the issue or how he would identify the issue. I take the advice and if i had no clue about it, that it even exist, I teach my self what he mentioned. Go back to code and fix it. It can take one hour to 2 weeks. The probaility to solve it increases expontential with the time, because i get more familar with with the whole set Up of the System and so on. If everything goes wrong, there is still this beautiful animation which makes the customer comfortable. :' D I gave myself for this answer a 6 of 10. Any other ratings?, could be fun : D
Can't agree more with you, in fact, I myself have developed similar open-ended questions with no 1 right answer. It helps me understand the thinking capabilities of the candidate as well. Hypothetical high 5!
Just discovered your channel, your videos are great, you explain things very well and even your accent is fun to listen! Also, it feels like you have fun making videos which is not the case in many other good tech channels.
Abhishek Agarwal so many things, load balancing algorithms, timeouts, backend connection pooling, caching.. there are things an engineer can do out of the box and there are instances where they might need to switch reverse proxy or worse case customize a brand new one.. Everyday I learn new things which make this question even more broad and take time to answer
Knowing if it is front end problem is not that hard just make the request from postman and see how long it will take , and you will save your self some time digging through your react app, and you start your journey on the backend and the DB
breaking down structure of enterprise lvl software in order to customise them is good way to pick-up new knowledge along with stumbling on issues- it's time consuming though much)
Damn, I thought the good ending would be that you don't focus on any specific part of the stack in the first place 😅 I consider myself heavily focused on backend and yet I would've first tried to narrow down which part of the stack is the one causing problems - replacing the frontend with curl, replacing the backend with a fake one, removing the DB in favor of a hardcoded response, ditching the proxy... focusing on a specific part of the stack first might be a waste of time in a real scenario. However, as someone who interviewed people in the past I can see the point of having the candidate talk with focus on their area of expertise - even if it's not the most optimal way to approach the problem, it gives you a lot of info about their skillset.
I am a career changer in Tech and I will be having my second stage interview in few days for my first job in tech, this video was so helpful. Thank you so much for this Hussein.
There is Generlist & Sniper technique to do this. Sniper: guessing random places, putting console.logs in frontend, backend to find the problem. Generlist: split system in components, frontend, backend.... debug on frontend & find some information, is it taking exactly 1 min ? always happening ? & some other testing, if problem is not on frontend I will switch to backend, will split backend in two parts, cloud (ngnx) and code API,,,, do same process for those.
@4:54 Full-stack is resourceful in many companies. Firstly, interviewing is not about impressing the interviewers. Secondly, take interest in the candidate no matter who they are without being judgemental. Think of it like a JOB (which it actually is) and not as an ego battle. Some intereviewers boast about how they reject a candidate after conducting the interview which is despicable. People lose their nights studying for some things to get the money to feed themselves and their families. Have some respect. Choosing between backend and full-stack also depends on interests and curiosity. Not all organisations solve software problems like Google or Netflix. Some need a well-rounded software engineer who can work across the platform. If you take the backend role in such organisations where there is Agile of 1 or 2-week sprints, the chances are that you would repeat the same kind of development activity every sprint. Choosing to work across the platform develops both the individual and the business output in such cases. Sadly, full-stack engineers are being abused for this. If you want to berate full-stack engineers, then what makes you not say that backend engineers are just territorial folks who are just lazy?
I do agree with mostly being a generalist whenever you are responsible for the entire stack. In my first position as a professional software engineer, I had to manage the virtual machines, security, maintenance, development pipeline, design, programming, financials, and more. Sadly it wasn't until later I realize what I was capable of or what I was worth. I definitely wouldn't say I was proficient in all of those areas and would definitely say our project timelines as well as the quality of the work could have improved if we delegated (hired) more. Unfortunately, it just wasn't the case. I also wanted to add, It definitely indicates a level of fluency if they solve the problem with a focused approach, but I wouldn't always assume that's their preferred area. It just may be what they have been mostly exposed to. Again, I loved the video and your interviewing style!
I'd hope the very first question they'd ask back is when the actual request begins to be processed by the back end. This alone should clarify a lot about where the problem might be or it could point to failures on multiple levels.
I love this question. Some IT folks tend to blame other disciplines for performance issues until a case has been made against them. I think this question may bring that tendency to light. With my systems background I would like to see an approach that involved scoping and isolating the area of the system responsible for the sub optimal performance. Diving in too deep initially in any one area before proper scoping of the issue shows poor troubleshooting technique. Bypass proxy and call web front end directly, call backend directly using code or tools, and run query/stored procedure directly. What did we find? That sort of thing.
Without looking at the other comments. In a production app, I'd hope we have DB metrics as well as overall performance monitoring (Sentry). If I don't have Sentry, I would first start with hitting the API directly. Taking the exact curl the UI sends, I would bypass the LB (if possible) and see if it chokes within the API. If it does, I could connect to the DB and run the same query, if it even takes slightly longer than expected I could see if there are any indexes missing or optimizations to my query or to the db setup itself. If the SQL query seems fine, I would review the code to see if there are any possible places for hang up and try to debug through it. Whether it's a request, sort, etc. If API is fine, I would hit the LB and see if it chokes there, maybe it's misconfigured or the thresholds are so low that it's spawning a new server every request. If all looks well in the API and the LB, I would look at the client. Maybe it's not using an async/await on the request and the UI is just stuck processing the request. It actually would still mean a problem elsewhere, but still bad practice. Maybe the UI is taking a really long time to process the response, or the response is including invalid/too large of data that's unnecessary. Or a dev accidently added a sleep() somewhere for exactly 60s and it was missed in code review :)
I don't know if I am right but immediately after listening to question, binary search comes to my mind. Simply draw a data flow diagram, pin point components and then simply start at the middle and check time taken by component to process the request. If its more than usual, move right or else move left
The problem could be in any layer of the architecture, it could be even how the database is designed and the complexity of the query with poor usage of joins and the lack of indexes, the query could be using some recursive logic causing performance issues. It could be that the web API technology could be obsolete or can be making a lot of heavy CPU usage, it also can be the web proxy, it can be the UI which is not using async calls or is blocking the UI main thread, it also could be a network issue or the VM or hardware where the database is running is very poor or the network bandwidth configuration, maybe there is a database that is an OLTP with millions of records in the table and the performance is degrading because of the amount of data. The payload data could be very big or the ORM is performing very poorly. There are a lot of possibilities. That would be my short answer off the top of my head, I have faced many of these problems before. Sorry about my written English, it is not my first language. Maybe I should apply for the job interview who knows.
lol my response would be “check the logs of each server to see where delays are getting introduced and then go from there. Probably not the db if it’s one minute every time, but it could be.” I feel like that’s the most sensible answer but I also feel like maybe I’m missing something
seems like an easy question to me. Even if the reverse proxy sucks or the database is bad the application should not freeze for a full minute. It's just bad front end software
As a engineer , first is to locate the problem , Then talk about short term and long term solution For me, first will check if API is callable with no delay in public network, try a couples If no delay, then pay more attention in frontend, Else go to backend, just narrow down question like a binary tree
Get my backend udemy course
backend.husseinnasser.com/
how did you comment an image
Members of the channel get special emojis
@@hnasr so you pay to be a member even if you are the owner of the channel? how many subscribers do you need to have this feature? I really like it !!!! I want to use it!
@Hussein Nasser Do you have a course for absolute beginners on backend? if yes I'll like to enroll
Enjoying your content
2:54 for the question
Thanks
Correction - the start of the question. I'm at 4:42 and still don't know what the question is.. Prob would have walked out of the "interview" by now.
9:16 for the uneasy question
Answer: ruclips.net/video/2FTkEhEqzIg/видео.html
FUN FACT - There are a lot of interviewers who want to show off their skills other than evaluating the candidate. Everyone is different and every problem can be solved differently. Thanks Nasser for speaking out loud. ✌️
The kind of people who ask about a database isolation level
Yes u r right I've had the exp when the interviewer was talking instead of me during all interview and I got the offer lol
She ended up accepting another offer. Totally relatable.
she: I can optimise your reverse proxy
company : ok here’s your offer
she: ‘meh’
I gave my first interview last week and it was just like this.I got the offer. My first job ! Thanks Hussein for awesome guides you have on your channel.When i watch your videos i more driven towards what i am doing .
Congrats!!!
@@hnasr thanks :)
Why would you apply for any job unless you are a Senior Developer? If you are unemployed you aren't good enough to work in the industry so why are you wasting peoples time?
@@BillClinton228 To get job as junior developer?
@@BillClinton228 somehow you just answered your self if you realise it.
started watching your videos from some time, must say that the way you explain and discuss things is very impressive and rare at the same time.
Thanks a ton !
This is how interviews should go. Love it.
I absolutely love your enthusiasm when you speak about the interviewer's response, and how their eyes open up. I actually am dying to have one of those conversations. Cant get past the recruiters though
5:15 Separate the frontend from backend, if you lag its front end.
Separate reverse proxy and backend by using a mock db and a call with something like postman, if it lags its the reverse proxy.
Make a raw call to the db if it lags its the db, or just find out by process of elimination.
Several combinations can also be the cause but this is a simplistic answer to your question.
This is one of the questions that I ask when I take interviews. Not the exact question - but something similar where answers are open ended. Asking these kind of questions will allow even the interviewer to gain knowledge. Sometimes you get brilliant answers that you would have never even thought of before.
The same question to ask by my interviewer and the ans given by me is the same as he said in the video about optimising the query and adding indexing to the database and also talk about frontend.
I have given almost 7 technical interviews and cracked each one without solving coding questions as he said getting the right code does not matter if you invest to develop something is important.
Unless it's an entry-level job, all questions should be general like this. It's virtually impossible to have good knowledge of all technologies, so not knowing something shouldn't be viewed as a bad thing - it's how you go about learning that is important.
If I gave this as an interview question, I'd expect the first part of the response to be a couple of clarifying questions, like..
Is it EXACTLY 60 seconds each time?
When the UI "freezes" does it become completely and totally unresponsive?
Those two alone will narrow it down a lot. If it is exactly 60 seconds each time to the millisecond then I doubt it will be a data access issue, even the in built query caching will be sufficient to return it faster the next time, and if the input variables change each time you would expect the time it takes to respond to also vary. The data is eventually displayed, so it's not going to be a timeout issue. If it's a WebUI and that's freezing, then you're maybe looping through an incredibly large data set which just happens to take 60 seconds to process. If it's an application UI freezing, you probably only have a single thread and you're going everything in there. From there there's still a huge amount of possibilities for what it could be, and an even larger of ways for testing for each of them.
My money is on clicking the button sets a cron job to run in exactly 59 seconds, and takes 1 second to complete
😂😂😂
It is a JavaScript UI (React) and the Dev did a setTImeout(getData, 59000)... Thinking being that they can get a tuneup contract in 3/4 months and come in and just remove the setTimeout
My take home here is the God feeling thing you said
@@gavinharris8619 😂😂 best answer so far.
Shit, very insightful. Thank you for this
tfw Thread.sleep(60000)
Adjust the speed to 1.25x and now you are perfect to go. BTW, great video!
Right 😁
You mean 1.5 lol
haha thanks
Chill dude
Thanks, i was at 1.5x
@Hussein, I really love to hear you talking. You amaze me with your tremendous knowledge and keenness to learn new things.
Software Engineering is a rampage now a days but you not only teach us new things but also how to become a calm, cool and a passionate Engineer. Kudos to you ! Please keep up the great work !
❤️❤️ thank you Abhinav
These is a very good question. Basically it will show how much the candidate understand how the internet works. And what their strong skill set are focused on. I basically stopped algorithm BS questions. I need to know if the candidate understands how the internet or how web/desktop application works plus the tools involved in them. I usually give simple but architectural complicated projects to my candidates which shows what tools they use, why they use it and how their code is structured. basically with a web browser information, you can easily know what froze the app, like if the whole DOM freezes to if the request gets stuck at connected to if the request gets stuck at receiving data. Chrome network log shows These information that you can use to suspect if it’s the frontend, proxy, Webserver or dB level
If someone asked me that I would probably like to ask them back what position exactly I'm being interviewed for
Exactly why I posted my comment just now lol
be careful not to come off as a know-it-all asshole!
The generalist actually emerges as the most productive in the age of cloud computing. I think what your getting at in this vid is that fundamentals of software engineering doesn't boil down to just algorithmic questions , which I agree with. (learning algorithim was very helpful for me anyways)
Some people built the cloud!
Great question. Highlights how they approach problems and break them down. I’m a full stack bootcamp instructor. My students like to rush to writing code to fix an issue. I tell them slow down and walk through the whole stack to find the problem.
Love that you ask real world questions of things which would happen. I have always felt it is much better to just talk about the real thing you face in your company. If they can bring something to the discussion, excellent. If an interview is handled more like a conversation you get a much better view of the candidates and they can understand what they will be facing.
Using the sentence that the 'application freezes' clearly means the JS call stack is executing a blocking call which is causing this to happen. That is the only reason. Make your API call ASync and the app will not freeze. Now if you would tell the candidate that the 'API is taking 60 secs' to return the response then they could debug the backend services/proxy for the problem.
That's really a good way to assess a candidate instead of being a cocky interviewer by forcing the conversation in 1 direction which the candidate might not have worked on.
Great interview question! Thanks for sharing. I much prefer these types of interview questions over regurgitating something I learned in college a million years ago.
I think this is a damn good question. My personal short answer would be, distributed tracing tool is designed for this type of question. It will help you to identify how the request time is spent amongst all the microservices in the stack. If you don't have distributed tracing installed, then use mocking technique combine with binary search to first locate the service that has issue, and check the log, dive in.
Google has Dapper for distributed tracing and it is amazing. And but I totally agree. The FIRST step is identifying which layer in the stack is causing/suffering the latency. I would not be too excited about a candidate who immediately chose their favorite layer and then only talked about that. That's like the drunk trying to find his keys and only looks underneath the lamppost because he can't see anything anywhere else.
First thing I would do is to check where exactly the wait is happening, client side or server side. With Wireshark you can see if the reply from the server is taking a long time or not. If not, then I'll investigate on the client, otherwise I'll concentrate the effort on the server. On the server, split again between the database and the actual server application: a breakpoint should be enough to check this.
tcpdump was my first thought, not sure why someone would optimize DB, or a reverse proxy, if the issue is with the mouse...
Good question Hussein! I like it very much because it really tests someone's troubleshooting skills. When you have a problem in Production that is affecting customers you need it solved as soon as possible and you definitely want to hire a developer who can do that. Knowing how to troubleshoot problems comes with experience and you can easily tell if someone has never done much of it before. It also amazes me when a developer won't even look at the available logs when there is a problem.
I'm watching right now, at minute 5:58, and I just found your question!
My answer: From my experience, I would start by checking the base of the flow, specifically how the backend application maps objects from the database. Maybe we have a recursive mapping or something wrong there. After that, I would use Test-Driven Development and write a test in the backend application to check what is happening.
Step 3: What is happening with the load balancer? I will check what is happening in the load balancer between the frontend and backend.
BUT! If on my computer the call is faster, first of all, you might need to check the cloud infrastructure for your deployment. Which region has the database, which region has your services, and what resources are used for your deployments.
YEAH! Very nice question. I would love to receive this in an interview!
Hussein, you truly inspire me and I hope to gather enough wisdom sometime in the future to do what you do and put my ideas and help other people on the internet.
This is my second visit to your videos. Such a genuine effort by you. Basically reflects your genuine personality! Keep it going!
Thank you for your kind words ❤️
one or two troubleshooting questions are great to understand how the person approaches a problem, his knowledge and work experience, and also how he approaches stuff he doesn't know and how it communicates that to others. I love them on both sides of an interview.
Omg i saw this two days before my interview for a devops position, and I got exactly the same question 😍 Thank you 🙌
wow congratulations, I am learning from the comments too
It is such a pleasure to even listen to you man, the way you talk and present yourself is so engaging!
I hope i get asked about this, real engineering question with no bs!
but no, they'll just ask to invert a binary tree 🤷♂️
Thats a wonderful evaluation process for testing his/her knowledge, experience and thought process towards a solution approach for the problem.
I will start this first principles thing by physically checking all the cables in all the routing paths from app to the user that will make me busy for awhile while. I might go down to a subatomic level just to check if everything's is alright back there. AS a old saying goes: "Trust but doublecheck".
I am so glad I found this video today! Thank you! I am currently preparing for my interviews and this gives my some peace :)
same here, how was your interview
@@JeemmaiThe interview was fine, even though I did not get the job that time. Got another one, though ;) Each inteview gives more experience and makes the next one easier. Good luck on your interview! 🙌
Also since the question BEGINS with the UI, that's where the investigation begins. First, you begin understanding if the latency traces back to the server. It doesn't mean front-end is your expertise or your crutch. If you start with database performance optimization you're flat out wrong. There's a logical order of progression.
Also ... having been working with backend stuff for 20+ years ... I must admit, I can't remember the details of quicksort on the spot, apart from it being some recursive bisection.
I would say it's not important to memorize quicksort on the spot and be able to look implement it without looking it up ... it's more important to know that it's O(nlogn) with O(n2) worst case. - and where to look up the actual algorithm.
Even this is not important. You can look it up in a second.
This is the question I’d like to receive during my interview! I strongly
agree with your approach. Giving open questions without one/two right answers gives a huge opportunity to discuss the topic and also allows interviewee to shine in some areas where they feel strong.
I appreciate the video! And immediately subscribing. Cheers! 🙌
I actually took psychology after I had my EE degree. And the only great thing I learned there was: "ask open questions, you will get to see much more of a person, than asking for a single answer." And it's so true!
As a generalist, I got a good chuckle from this. All I 've got is a developed approach to attack that common real-life question. However, level of interest might not be a good gauge as some of us are numb across the board. We get excited once we find the root and deliver the goods.
There is no single place that you can pin on for performance issues. It could happen at several levels
1 ) Non indexed foreign key huge tables can cause it
2) Making api call and blocking UI Thread without calling the API async
3) Bad backend code which does not honour coding practises like sold principles, or design patterns.
4) Sending unessary headers
5) In Dot Net, sending native req tbough managed dot net pipeline. e.g Webconfig has property RunAllManageeRequest true. So when Websevers needs load some inage it will send it through dot net framework which is not necessary.
The list goes on.
Thank you, Hussein. I agree with you that giving the open-ended question candidate to check their problem solving skills.
Every technical panel/hiring manager has to watch and learn from this
6 minutes to ask the damn simple question. 😂
Check your drive for activity (cache overrun, reentrant logging), but based on 30 years experience the problem is in the database!! Next, your JVM needs more memory. Also, I think you can be actual full stack - but you have to spend years doing non-programming - a few years SQL development and maybe 5 as DB Admin, network manager, system admin, etc. And to be really good at backend, it helps to have built some front end level stuff.
My best indicator of someone that will be fantastic is if they have a lab at home. Every single person that has something like a RaspPi cluster, or their own Kubernetes rack at home has been phenomenal and work far and above the normal 40 hour person.
that 60 second thing is the answer, you look for configs on each part of the stack for timeouts, keepalives, etc for that number (including dns! most people ignore that), if you find something, you start the hunt there...
I have been through these types of questions in my interviews many times and I can absolutely relate to what he is talking about.
And THIS is a great question and attitude towards job interview. Interviewee doesn't feel completely stupid and demotivated because he/she talked about the topic they know and just couldn't answer a question or two so he/she comes out of the interview with the feeling "Maybe I couldn't answer the second question but at least I got the first one. So maybe I'm not complete utter rubbish at this"
I can binge watch your channel and computerphile for my whole life guys you're the best
Wow, thank you so much for the great content, Hussein! This interview question really opens my mind, and it is also a great question to ask other people when we want to learn things from different perspectives. I just started learning backend engineering, and I've been following your tutorial. Thank you!!
all the best in your journey Tony! enjoy the process and stay hungry
You are the sunshine of my life. thanks for all the data requests with 200
Great video. An experienced engineer wouldn't try to guess. They would ask what telemetry or logs are available, and start isolating parts of the stack. You're right though, most candidates will gravitate towards what they are most comfortable with. But -- never troubleshoot or fix performance without metrics.
This video would be the perfect example in a class about "Beating around the bush".
That's a great approach in interviews.
There's no point in stupidly learning stuff, but *understanding* and *thinking* are the most important skills.
yeah except most companies have this inflated ego thinking that you will be building them this new dropbox and you have to know how to design an architecture for 500 millions users with millions requests a second just in case and also you will be starting at an entry position and at this bracket we expect you are working to gain experience aka you might as well pay us...
My first thought: Sounds like a blocking (sync) function somewhere is hitting a timeout (60 sec).
I always log function calls with timestamps so I think I would figure it out pretty fast.
You probably get this a lot, but you honestly produce the highest quality content on backend engineering on RUclips. Thank you for all that you're doing to help the community!
JoRyGu i thank you very much for your words dear 🙏 gives me pleasure to give back to the community.. my favorite parts are the discussions on the comments section i love how each engineer contribute with valuable opinions that form interesting discussions
This is what I like about back end developers versus front end developers. A front-end developer will give you a list of fish to bring to an interview and instill the thought that without memorizing those you won't be able to get a job. A back-end developer however will teach you how to fish so you can feed yourself at the interview and potentially ace it. Much more logical and down to earth
I'm a Frontend developer.
So personally I'd:
first use something like postman and see if it still takes like 60sec to retrieve response if not then the Frontend is okay
let's move on
then is backend I'd check how log it takes to get to bd stuff
like:
app.get('/someroute', (req, res) => {
console.time('xyz')
/*None be stuff like validations, processing etc. goest here*/
console.timeEnd('xyz')
/*Database stuff goes here*/
})
if none db stuff takes lot of time then we need to optimize backend codes else we'd need to check the database(relations, structures etc.)
also I'd love to hear your desired answer
i can attest to this. this is the most successful kind of question you can ask
I so agree! I actually made a video "Why coding interviews suck" They don't prove anything! I also use open questions and I find things that I think they had trouble with in the projects they listed on their CV. When a person dives in to technical depth (not debt) I ask follow up questions and see how they dealt with issues. Then I know what part they've played and what I can expect from them. And I can cage where to put them in the team. Sometimes (like you said) you hear things and think: "They will fit even better on this part or even another team!"
I much rather hire someone, who has no experience in the language or framework that we use but demonstrates the ability to think and problem solve. I know that they'll master that language or framework too. And I especially like it (and I hope they do) tie in their experience with the job outline I gave. I do that always when I apply for a project as freelancer. I am honest saying what I have no experience with but that I am willing to learn, and I drive home the experiences I have and they miss.
I just joined a team who does SSIS/SQL reporting that needs to migrate to the cloud. I never worked with SSIS (and I don't care about it, and made that very clear) and I am not really a SQL backend developer (I use SQL only to select data and I can tune SQL, don't care for SQL stored procedures because it's ugly). But I know CI/CD, I know how to get COTS applications to conform to CD, all of them are different and all of them require specialized attention and we will figure that out.
I have a wealth of infrastructure experience, not as much on Azure but that translates well, and a more than you have as we already ran on Azure with a COTS application. And I give reasons as to why they need IaC, and why they need to stop using SQL scripts to promote changes but start using dtproj file to build SSIS and use dacpac files. All terms they had never heard before.
So they were like: "This guy doesn't know SSIS/SQL, but he's obviously a developer who has coded ETL and knows and demonstrated knowledge about packages of SSIS. And he knows CI/CD, IaC and is pragmatic in the approach fitting with out 15 year old application. And he comes from CISO. We call CISO and het a reference." Well the reference was good so I started the next week.
Because sometimes things can sound too good to be true. I've done a lot and anticipated a lot and they just verified that with my former PO.
And they were sold when he said: "He's coming back to this company? Why didn't he come back to CISO? I am a bit sad about that!"
My answer to your question? Check the logs. Heck, I say the same thing to my juniors all the time (and SQA people sometimes).
The Front End logs should at least reveal whether the request was sent to the back end (and how long it took to send and how long it took to receive the response from the back end). So this will let you identify if the issue is on the front end. If it is a front end issue, then hopefully you have detailed logging that identifies which step is taking too long or debug step by step.
If the issue is not on the front end then check the logs of the middle and back ends. Same thing. Detailed logging will at least tell you where or in which part the issue lies. Then debug or go through the code in that section.
The really difficult problem is if the issue is not in the logs. Then I would suggest doing debugging from the start (front-end) and go through to the code (all the way to the middle/back) trying to identify which step is taking too much time.
I really liked the question , if it was me answering the question I would probably borrow some techniques for solving and troubleshooting networking issues which is based on making comparisons between the "normal" behaviour and the one we currently have starting from collecting the information about the situation without analyse anything, after collecting the informations from each part we can compare it to what a normal behaviour should be at that moment we can be quite sure about where we need to fix things.
I just paused when you asked the question then I try to answer it in my head and as it turns out I am more interested in backend lol as i majority of my answer was composed of something going wrong at the backend. you're right, I guess. this really tells you which way you lean on more if you are indeed a "full stack"
I remember watching this 3 years ago. Back then I was a Jr. dev and was not interviewing anyone. Now that I've started interviewing folks as a Sr. I always make sure to ask this question to the right candidates.
Remarkable, as a bug bounty hunter specializing in various aspects related to Web Applications, I find it incredibly intriguing to come across such discussions.
I would take a TCPDUMP on the client-side and on the server-side and analyze the time taken on the TCP handshake to make sure all good from the network latency perspective, then I will check the DeltaTime between the packets to understand which data is causing the delay. If there is a 60seconds delay from the server-side, next time I would take TCPDUMP in the application server and database server and again analyze what causing increased DeltaTime. This way we can finally get to the entity in the entire stack which is adding the DeltaTime taken of 60seconds, once we identify that then we can tweak its configuration or code accordingly.
This is an excellent approach. Candidates should be treated with courtesy. The whole stack is not our expertise.
The industry should understand this, as our current gen Software Engineering Interviews are more focused on Leetcode problems and Algorithms which a lot of candidates learn by heart from various courses. Yes having a good grasp of Algorithms is important for a SWE but in real world cases the person is going to develop & maintain software services, products. So it is important to know how much Architectural knowledge the person has or how to figure out with problems and come up with some optimize solutions.
One really great question to ask in an interview is, "What is the hardest software problem that you tackled and solved?" And then a related question, "What is the hardest software problem that you've attempted to solve but failed to actually solve?"
My answer would be,
first i implement a waitng animation for the customer, which makes him feel comfortable. A nice processing animation or something similar.
Then i check the api calls and see how long it takes to fetch the data, if this is fine then i look up in the frontend.
If its not fine then will look up in the backend and look whats happening there. In the most cases its a serial chain issue.
Some method waits to start and then another method wait for this method and so on.
If I understand how it flows, i find the the bug.
If not then I would ask another dev to help me to find the issue or how he would identify the issue.
I take the advice and if i had no clue about it, that it even exist, I teach my self what he mentioned.
Go back to code and fix it. It can take one hour to 2 weeks. The probaility to solve it increases expontential with the time, because i get more familar with with the whole set Up of the System and so on.
If everything goes wrong, there is still this beautiful animation which makes the customer comfortable. :' D
I gave myself for this answer a 6 of 10.
Any other ratings?, could be fun : D
This is a legit question. Beats all of those typical algorithm based interview questions.
Can't agree more with you, in fact, I myself have developed similar open-ended questions with no 1 right answer. It helps me understand the thinking capabilities of the candidate as well. Hypothetical high 5!
Teşekkürler.
totally agreed. "Just be yourself". That make me got the job.
Question is at 2:54
Just discovered your channel, your videos are great, you explain things very well and even your accent is fun to listen! Also, it feels like you have fun making videos which is not the case in many other good tech channels.
Thank you Shreyas! Appreciate it 😊
BTW, how would you optimize a reverse proxy.....really curious to know🤔
Abhishek Agarwal so many things, load balancing algorithms, timeouts, backend connection pooling, caching.. there are things an engineer can do out of the box and there are instances where they might need to switch reverse proxy or worse case customize a brand new one..
Everyday I learn new things which make this question even more broad and take time to answer
@@hnasr That's awesome! Thank you.
@@hnasr Also interested in knowing about debugging such issues. Waiting for a video on rev.proxy/nginx
@@hnasr how can I work for you? 😬
You told the truth bro. Last 3-4 minutes were awesome!!
answer. use your profiler(s). web/js, backend, network and database.
Knowing if it is front end problem is not that hard just make the request from postman and see how long it will take , and you will save your self some time digging through your react app, and you start your journey on the backend and the DB
breaking down structure of enterprise lvl software in order to customise them is good way to pick-up new knowledge along with stumbling on issues- it's time consuming though much)
Damn, I thought the good ending would be that you don't focus on any specific part of the stack in the first place 😅 I consider myself heavily focused on backend and yet I would've first tried to narrow down which part of the stack is the one causing problems - replacing the frontend with curl, replacing the backend with a fake one, removing the DB in favor of a hardcoded response, ditching the proxy... focusing on a specific part of the stack first might be a waste of time in a real scenario.
However, as someone who interviewed people in the past I can see the point of having the candidate talk with focus on their area of expertise - even if it's not the most optimal way to approach the problem, it gives you a lot of info about their skillset.
I am a career changer in Tech and I will be having my second stage interview in few days for my first job in tech, this video was so helpful. Thank you so much for this Hussein.
Hussein, this is a standard backend engineering question. I received it in the last 3 interviews :) I think it overplayed now.
There is Generlist & Sniper technique to do this.
Sniper: guessing random places, putting console.logs in frontend, backend to find the problem.
Generlist: split system in components, frontend, backend.... debug on frontend & find some information, is it taking exactly 1 min ? always happening ? & some other testing, if problem is not on frontend I will switch to backend, will split backend in two parts, cloud (ngnx) and code API,,,, do same process for those.
@4:54 Full-stack is resourceful in many companies.
Firstly, interviewing is not about impressing the interviewers.
Secondly, take interest in the candidate no matter who they are without being judgemental. Think of it like a JOB (which it actually is) and not as an ego battle.
Some intereviewers boast about how they reject a candidate after conducting the interview which is despicable. People lose their nights studying for some things to get the money to feed themselves and their families. Have some respect.
Choosing between backend and full-stack also depends on interests and curiosity. Not all organisations solve software problems like Google or Netflix. Some need a well-rounded software engineer who can work across the platform. If you take the backend role in such organisations where there is Agile of 1 or 2-week sprints, the chances are that you would repeat the same kind of development activity every sprint. Choosing to work across the platform develops both the individual and the business output in such cases. Sadly, full-stack engineers are being abused for this. If you want to berate full-stack engineers, then what makes you not say that backend engineers are just territorial folks who are just lazy?
You're so positive!
We are Generalist in full stack content. Perfect statement.
Well-spoken. Also, a fantastic question to get candidates thinking. Love it.
I do agree with mostly being a generalist whenever you are responsible for the entire stack. In my first position as a professional software engineer, I had to manage the virtual machines, security, maintenance, development pipeline, design, programming, financials, and more. Sadly it wasn't until later I realize what I was capable of or what I was worth. I definitely wouldn't say I was proficient in all of those areas and would definitely say our project timelines as well as the quality of the work could have improved if we delegated (hired) more. Unfortunately, it just wasn't the case.
I also wanted to add, It definitely indicates a level of fluency if they solve the problem with a focused approach, but I wouldn't always assume that's their preferred area. It just may be what they have been mostly exposed to.
Again, I loved the video and your interviewing style!
I'd hope the very first question they'd ask back is when the actual request begins to be processed by the back end. This alone should clarify a lot about where the problem might be or it could point to failures on multiple levels.
I love this question. Some IT folks tend to blame other disciplines for performance issues until a case has been made against them. I think this question may bring that tendency to light.
With my systems background I would like to see an approach that involved scoping and isolating the area of the system responsible for the sub optimal performance. Diving in too deep initially in any one area before proper scoping of the issue shows poor troubleshooting technique. Bypass proxy and call web front end directly, call backend directly using code or tools, and run query/stored procedure directly. What did we find? That sort of thing.
Without looking at the other comments.
In a production app, I'd hope we have DB metrics as well as overall performance monitoring (Sentry). If I don't have Sentry, I would first start with hitting the API directly.
Taking the exact curl the UI sends, I would bypass the LB (if possible) and see if it chokes within the API. If it does, I could connect to the DB and run the same query, if it even takes slightly longer than expected I could see if there are any indexes missing or optimizations to my query or to the db setup itself. If the SQL query seems fine, I would review the code to see if there are any possible places for hang up and try to debug through it. Whether it's a request, sort, etc.
If API is fine, I would hit the LB and see if it chokes there, maybe it's misconfigured or the thresholds are so low that it's spawning a new server every request.
If all looks well in the API and the LB, I would look at the client. Maybe it's not using an async/await on the request and the UI is just stuck processing the request. It actually would still mean a problem elsewhere, but still bad practice. Maybe the UI is taking a really long time to process the response, or the response is including invalid/too large of data that's unnecessary.
Or a dev accidently added a sleep() somewhere for exactly 60s and it was missed in code review :)
I don't know if I am right but immediately after listening to question, binary search comes to my mind. Simply draw a data flow diagram, pin point components and then simply start at the middle and check time taken by component to process the request. If its more than usual, move right or else move left
The problem could be in any layer of the architecture, it could be even how the database is designed and the complexity of the query with poor usage of joins and the lack of indexes, the query could be using some recursive logic causing performance issues. It could be that the web API technology could be obsolete or can be making a lot of heavy CPU usage, it also can be the web proxy, it can be the UI which is not using async calls or is blocking the UI main thread, it also could be a network issue or the VM or hardware where the database is running is very poor or the network bandwidth configuration, maybe there is a database that is an OLTP with millions of records in the table and the performance is degrading because of the amount of data. The payload data could be very big or the ORM is performing very poorly. There are a lot of possibilities. That would be my short answer off the top of my head, I have faced many of these problems before. Sorry about my written English, it is not my first language. Maybe I should apply for the job interview who knows.
Finally I found you. Love you hear you always.
that is good to hear such concern on nity-gritty case after you've dealt with likewise prblm)
lol my response would be “check the logs of each server to see where delays are getting introduced and then go from there. Probably not the db if it’s one minute every time, but it could be.” I feel like that’s the most sensible answer but I also feel like maybe I’m missing something
seems like an easy question to me. Even if the reverse proxy sucks or the database is bad the application should not freeze for a full minute. It's just bad front end software
dude I subscribed to your channel just 2 days back. great content. Gonna check all your videos.
Thanks for subbing! welcome to the community, much love
As a engineer , first is to locate the problem , Then talk about short term and long term solution
For me, first will check if API is callable with no delay in public network, try a couples
If no delay, then pay more attention in frontend, Else go to backend, just narrow down question like a binary tree