@@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. ✌️
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.
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?
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.
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.
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.
@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 !
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)
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.
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.
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!
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
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.
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.
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".
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.
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
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"
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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"
Remarkable, as a bug bounty hunter specializing in various aspects related to Web Applications, I find it incredibly intriguing to come across such discussions.
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.
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
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...
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
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.
@@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! 🙌
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
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
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
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.
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.
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.
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.
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.
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! 🙌
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
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.
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
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...
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
You got the sibs subscriber. Man I was thinking that I was a piece of s*** because in my interviews I avoid to memorize things like double linked list, binary trees, link the list, etc you know.... Man, this kind of questions, are being selling in books for interview. In other words, there are marked off the memorization for interviews for getting success in interviews, instead of check the real potention of the candidate. Your methodology is insanely efficient, because check the real logical thinking of the candidate, and do not make the candidate slave of memorization.
I would try to narrow the problem first, send a curl or postman request, does it hang the same as explained? If it does, that rules out the front end piece. Then go from there.
The only thing I actually hate is being interviewed by a guy who had read some article on medium or some blog, about architecture or something similar, and then asking me to explain why is it good or not. While the guy who is interviewing have no idea what's good or wrong, as he just googled it for the first time in his life. But he wants to sound smart. These things happen most of the time. 95% of the apps, web or desktop are crap. Not stable, vulnerable etc. But people still get the job and work on those apps. If you ask me, that is good enough. As long as people are able to work, it's fine. Not every app needs to become facebook, instagram, youtube etc. I won't even mention that most of the people who worked for facebook say that the code base of facebook is full of spaghetti code, bad practices etc. Does facebook exist today? Yes. Enough for me..
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)
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.
He never says the application actually makes a request? He just says "a response is displayed". If you're actually trying to diagnose this, how do you not start by opening up browser devtools to confirm a network request is the culprit? I actually think this interview question is great because it forces you to be aware of your assumptions and confirm those before deciding to hop to a specific point in the stack?
@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?
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.
You probably get this a lot, but you honestly produce the highest quality content on backend engineering on TH-cam. 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
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!"
That's a dangerous question, because the interviewer has to be humble enough to consider experiences that are not their own, which often is not the case. What an interviewer wants to hear is often based on their personal experience, background, and social class.
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
algorithms questions are asked in a way whether candidates prepared for the interview or not, no one need to find the best solution by using algorithms which was evolved, optimized over years. answering these algorithm questions by knowing the answer, then interview doesn't serve the purpose of selecting candidates based on analytical thinking.
You caught me. I prepared my answer based on my best skills. To be honest it was my answer:- I'll go to the front end and then find out the request receiver URL for that button. Then I'll go to that function which is handling that URL. (For a side note, I am a python backend engineer.) Then I'll put a check on the beginning of that function and I'll put another check on the end of that function. Then I'll gradually move backward and forward those two checks, until I find that line which is causing the delay. Then I'll fix that. That might be a python problem or a database problem. if you read my answer then, please tell me are you satisfied with my answer? If not then tell me what is wrong?
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!!
Exactly 60 seconds every time? Well in that case I would ask first if there was a message-broker in there, because I would guess that the message is scheduled with a set delay. Otherwise you start with the top layer and verify and go down from there.
Yeah I was wondering what the information about “exactly” 60 seconds was about, that sounds like a timer is being applied for one minute in the pipeline, maybe some debug code that was left in by mistake.
You shouldn't try to "confuse them" even more. It's alright to ask open ended questions to learn how the candidates think.Also, knowledge is one thing, drive and determination is another. I've seen very knowledgeable engineers that are super lazy and don't get things done, and not so skilled engineers getting things done consistently. Always keep soft skills in mind when interviewing.
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
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
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: th-cam.com/video/2FTkEhEqzIg/w-d-xo.html
She ended up accepting another offer. Totally relatable.
she: I can optimise your reverse proxy
company : ok here’s your offer
she: ‘meh’
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.
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.
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.
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!
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 !
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.
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.
This is how interviews should go. Love it.
@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
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!
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.
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.
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!
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)
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.
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.
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".
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.
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
Thank you, Hussein. I agree with you that giving the open-ended question candidate to check their problem solving skills.
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"
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.
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.
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!
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.
It is such a pleasure to even listen to you man, the way you talk and present yourself is so engaging!
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...
This video would be the perfect example in a class about "Beating around the bush".
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.
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.
Every technical panel/hiring manager has to watch and learn from this
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
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.
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.
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.
Thats a wonderful evaluation process for testing his/her knowledge, experience and thought process towards a solution approach for the problem.
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"
6 minutes to ask the damn simple question. 😂
Remarkable, as a bug bounty hunter specializing in various aspects related to Web Applications, I find it incredibly intriguing to come across such discussions.
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.
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
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...
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
You are the sunshine of my life. thanks for all the data requests with 200
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.
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
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! 🙌
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
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 ❤️
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
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
i can attest to this. this is the most successful kind of question you can ask
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.
answer. use your profiler(s). web/js, backend, network and database.
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.
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.
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.
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.
This is an excellent approach. Candidates should be treated with courtesy. The whole stack is not our expertise.
I hope i get asked about this, real engineering question with no bs!
but no, they'll just ask to invert a binary tree 🤷♂️
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! 🙌
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
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.
totally agreed. "Just be yourself". That make me got the job.
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
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...
I can binge watch your channel and computerphile for my whole life guys you're the best
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 got the sibs subscriber. Man I was thinking that I was a piece of s*** because in my interviews I avoid to memorize things like double linked list, binary trees, link the list, etc you know.... Man, this kind of questions, are being selling in books for interview. In other words, there are marked off the memorization for interviews for getting success in interviews, instead of check the real potention of the candidate. Your methodology is insanely efficient, because check the real logical thinking of the candidate, and do not make the candidate slave of memorization.
I would try to narrow the problem first, send a curl or postman request, does it hang the same as explained? If it does, that rules out the front end piece. Then go from 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.
This is a legit question. Beats all of those typical algorithm based interview questions.
The only thing I actually hate is being interviewed by a guy who had read some article on medium or some blog, about architecture or something similar, and then asking me to explain why is it good or not. While the guy who is interviewing have no idea what's good or wrong, as he just googled it for the first time in his life. But he wants to sound smart. These things happen most of the time. 95% of the apps, web or desktop are crap. Not stable, vulnerable etc. But people still get the job and work on those apps. If you ask me, that is good enough. As long as people are able to work, it's fine. Not every app needs to become facebook, instagram, youtube etc. I won't even mention that most of the people who worked for facebook say that the code base of facebook is full of spaghetti code, bad practices etc. Does facebook exist today? Yes. Enough for me..
That is a true statement. People paint perfect portrait of their software when in fact not everything is pristine.
@@hnasr Exactly. Anyway, keep up with the awesome content you are sharing.
would be great to know what the girl was talking about when she spent 25 minutes talking about how she would optimize the reverse proxy
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)
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.
Question is at 2:54
He never says the application actually makes a request? He just says "a response is displayed". If you're actually trying to diagnose this, how do you not start by opening up browser devtools to confirm a network request is the culprit? I actually think this interview question is great because it forces you to be aware of your assumptions and confirm those before deciding to hop to a specific point in the stack?
@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?
that is good to hear such concern on nity-gritty case after you've dealt with likewise prblm)
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.
You probably get this a lot, but you honestly produce the highest quality content on backend engineering on TH-cam. 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
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!"
That's a dangerous question, because the interviewer has to be humble enough to consider experiences that are not their own, which often is not the case. What an interviewer wants to hear is often based on their personal experience, background, and social class.
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
algorithms questions are asked in a way whether candidates prepared for the interview or not, no one need to find the best solution by using algorithms which was evolved, optimized over years. answering these algorithm questions by knowing the answer, then interview doesn't serve the purpose of selecting candidates based on analytical thinking.
if all steps take the same amount of time debugging then you binary search and start in the middle
You caught me. I prepared my answer based on my best skills. To be honest it was my answer:-
I'll go to the front end and then find out the request receiver URL for that button. Then I'll go to that function which is handling that URL. (For a side note, I am a python backend engineer.) Then I'll put a check on the beginning of that function and I'll put another check on the end of that function. Then I'll gradually move backward and forward those two checks, until I find that line which is causing the delay. Then I'll fix that. That might be a python problem or a database problem.
if you read my answer then, please tell me are you satisfied with my answer? If not then tell me what is wrong?
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
Exactly 60 seconds every time? Well in that case I would ask first if there was a message-broker in there, because I would guess that the message is scheduled with a set delay. Otherwise you start with the top layer and verify and go down from there.
Yeah I was wondering what the information about “exactly” 60 seconds was about, that sounds like a timer is being applied for one minute in the pipeline, maybe some debug code that was left in by mistake.
I know nothing that has a 60 seconds timeout default. I will ask if this "issue" is hypothetical or a real case.
Finally I found you. Love you hear you always.
You shouldn't try to "confuse them" even more. It's alright to ask open ended questions to learn how the candidates think.Also, knowledge is one thing, drive and determination is another. I've seen very knowledgeable engineers that are super lazy and don't get things done, and not so skilled engineers getting things done consistently. Always keep soft skills in mind when interviewing.
You told the truth bro. Last 3-4 minutes were awesome!!
first step go chrome network look for time to first byte and procesing time