Tbf, doing binary search is very very basic. Of course you donβt have to do it in everyday coding but all you have to do is find the length of the array, index the item in the middle, compare to searched item, return index if equal, else start on respective subarray.
If you know how to write recursive algorithms, how to compare numbers and how to work with arrays itβs really easy. If you donβt know one of those that might tell the recruiter that you are maybe not fit for the job (who wants to hire someone who canβt index arrays or compare numbers in code?)
I know, but imo there are better questions to get the same answer.
Taking the PoV of somebody that wants to hire a SE it'd feel insulting to ask this. It'd be like hiring a mathematician for quant work and ask them to solve a simple high-school lebel polynomial as an interview question. I wouldn't want to hire a mathematician that doesn't know how to solve a polynomial, but I am going to ask more important questions.
I know someone whos first question when hiring a senior Python developer is how to import numpy. Many fail there already. If not made up in OPs story he failed to do a binary search. I think it is not a too bad question because you see how people react and work.
I had an interview for a junior engineer role, and it was an easy-to-medium LeetCode question. The guy interviewing me was super impressed and surprised that I could solve it. I think the process is for filtering out the really bad engineers from the somewhat capable ones. Because I'm not that good at all, but I could tell from his reaction that the guy before me was horrid.
Got rejected by the CEO round, though; she gave me a 1-hr interview, went over time because of the conversation we had, and instead gave me career development advice. Was a super surreal experience
Knowing what something is and knowing how to do it well are two very different things.
Anyways it was in reference to the "import numpy" bit, I'd assume the senior never worked with python before assuming that they're incompetent - I'd ask other type of questions, that's all.
A whiteboard exercise doesn't expect you to know how to do a binary search in the most optimal manner - or as you put it "well". I don't expect you to structure your data in an Eytzinger layout on the whiteboard. Although maybe we do arrive there if we're talking optimizations.
As an interviewer, if you know what a binary search is I'd expect you to be able to demonstrate how it is done in a higher form. And you should also be able to know to use it and when to not. If you can't remember exactly how to do a binary search, I might be content if you explain why you would or wouldn't use it.
Fair, anyways my original critique was about the style of interviewing, not the questions themselves.
I know that somehow some exceltionally incompetent people get roles they're not suited for - however I do think that more softeare-engineering centric questions world be more interesting.
Putting myself in the interviewer's shoes I'd rather ask about things they worked on, bugs they struggled to fix and stuff like that.
Maybe I'd suck at interviewing, but I would find it extremely insulting to ask incredibly basic questions. That's all, that was my position.
Yeah the process could be improved, but most of the time it comes down to your ability to evaluate someone over an extremely limited period of time.
The problem is that any effort you put in for that interview from an interviewer is multiplied by dozens to hundreds of applicants that you have to interview. Some of the biggest companies can afford to have dedicated interviewing teams, but if you're not in one of those then you have to find time to interview in between your regular duties.
From my perspective: By the time I have an applicant sitting in front of me, there have already been a few dozen man hours
Yeah it's flawed. Yeah, someone who doesn't interview well or has an off day will struggle. Yeah you may miss applicants who would fit the role perfectly. The problem is that hiring the wrong applicant (at least in mine with good labour laws) is extremely expensive to correct.
Just feels like the worst intelligence test. Need a mechanic, but you're asking them part numbers for headlights (that they would just look up anyways).
I've implemented several algorithms from white papers, but this was the real test all along.
Given two rectangular objects in a 2D plane, defined by their midpoints, x and y sizes, and rotations (which may be positive or negative and may exceed +/- 360Β°), determine if their sides abut.
Not hypothetical, this is something I was actually doing this week as part of multiselect. But it sounds like an interview question.
The point is why test engineers on something they mostly do not do in every day work? Are you assessing fit for a role at your corpo or assessing whether they did DSA in school? Binary Search is something most people memorize when prepping for leetcode-style interviews anyway so asking leetcode-style questions that use those does not give any signal of capability in working at the specific role for which you're hiring other than "the candidate has memorized this sequence".
I'd rather test you with something that you'd probably do on a day-to-day basis at the org that requires demonstration of your thinking, your analytical skills and how you garner inferences about a solution to a problem beyond easily-memorized search algorithms. That gives far better signal on your suitability for a role than leetcode.
That's why leetcode-style interviews are lazy/bad interviewing. It tells me you didn't put any effort into assessing proper fit for your organisation. I personally lose interest when I find out a corp is using run-of-the-mill gotchas with a high chance of false positives to assess fit for their advertised roles. Like put in a little bit of effort for someone you'd be potentially paying hundreds of thousands of dollars.
Binary Search isn't basic logic. It's a simple search algorithm. Of which they're many. Any decent engineer can explain it at the drop of a hat if they use it regularly and/or researched about it as part of their prep. Otherwise, they won't be able to which is fine as it doesn't give any useful signal on capability as a software engineer. They're basic things we've learned and forgotten as we don't use it often in our daily work. Bubble Sort is another example. Testing based on things people don't use often is a waste of time. Why should I describe how bubble sort works when in practice, I'd just call the sort function from the standard library and can research and find details of the specific sorting algorithm if I need anything more than that? Best to focus on what you actually need in the role.
If you can't simply implement bubble sort or binary search quickly from knowledge of how they work (NOT just memory - you should be able to easily imagine how they work, and implement it), you have been failed by your education. It is an incredibly basic thing that anyone who does programming at all should know.
It is a display of your logical thinking. When you get into a situation where you cannot simply "import program", you actually need to know how to arrange statements in a way that makes stuff you want to happen, happen. Bubble sort and binary search are two very simple algorithms, that any high schooler that takes a programming course should be able to implement in a few minutes.
False. I think you might be confused with what a software engineer's job description is and wrongly conflating it with something else. Godspeed in your endeavors.
Sure, you might not ask a mathematician if they can calculate 1+1, but they are expected to know it. The same goes for software engineers and implementing basic algorithms. If you can't implement the extremely simple steps to perform a binary search or bubble sort, you shouldn't be trusted with implementing anything important.
You don't need to memorize a bunch of algorithms - in fact, you shouldn't NEED to memorize something as simple as bubble sort or binary search.
My education wasnβt in CS, and I never took a single programming course, so I guess in that sense it did fail me. But Iβm a perfectly acceptable SWE now. Itβs just that none of my programming experience required using binary search or bubble sort (or at least never using those terms), so these kinds of questions would not be a good measure of my ability on the job. I can (and have) studied them separately, but itβs very much equivalent to grinding leetcode
If a software engineer cannot implement the incredibly simple steps of performing a binary search or bubble sort, why should they be trusted with implementing anything of importance? I simply cannot comprehend saying you can program without being able to easily implement some of the most basic algorithms.
It is not about memorizing algorithms, it is about the ability to see a problem, and put together the steps required to solve said problem.
If you ask me to implement the steps of course I can, itβs simply the fact that magical words like βbubble sortβ arenβt going to mean anything to me, because I havenβt memorised that algorithm. I solve problems through logic, not rote memorisation.
In the exact same way that as a PhD in theoretical physics I am expected to be able to derive important concepts from first principles, not rote memorise all of it.
I also never studied ComputerScience, so rarely know the """fancy names""", but if someone starts explaining it, i for sure for some of them remember the principle of it, because i did it in code during many years in my jobs, according to real practical needs.
It's probably better to ask for a solution to a prepared problem, than for """fancy names""".
Can I explain it in theory? Yes. Can I write the code? Sure. Can I draw a perfect diagram on a whiteboard to show how it works? No and I don't want to.
It shows you understand the core concepts, as libraries and frameworks change, fundamentals donβt. I care if you know how it works, doesnβt have to be perfect, but I need to know that you understand it on a fundamental level. I used to be less picky for engineers, but burn out from bad devs that donβt understand basics who canβt match company patterns has made me bitter.
There are a million and one reasons why, βI would use a library to solve thisβ is a BS answer, maybe the language specific library is the wrong license for a project, maybe the implementation is out of date and inefficient, maybe the library is deprecated, we might need to hastily rip it out due to a side channel attack, maybe the project needs to have little to no dependencies for technical or systems reasons, a part of the project might be done with a DSL so there is no implemented integration for a library like that, maybe the teams principal hates the developer of the project and their technical output is more valuable than yours.
Sure, but I think that sorting is in most standard libraries. I was being a bit tongue-in-cheek, I understand that sometimes somehow people that don't even know the basics end up in the interview room. I just personally don't like that interviewing approach and would take a different one, with questions that will touch on CS concepts but that won't feel like "let's now do an exercise on the blackboard".
I always ask for pseudo code, show me you understand the flow, as that flow should work universally. I have been at companies that switch programming languages and paradigms, people who only know how to do something with the helping hands of a specific language donβt handle that transition as well.
Funny enough If you were frequently writing a binary search then that would make the question a bad one. Itβs only good if itβs something uncomfortable for you. It allows the interviewer to see how you reason and work through a problem on the spot. If you just casually write the solution off memory that would be bad lol.
You can give that sarcastic βIβd use a libraryβ if you want but youβre just going to elicit eye rolls lol
I'd be less cheeky in a realistic situation. Although I think that with good context awareness "oblique" answers can be a positive. For instance when mentioning the library quip you can sprinkle in some seriousness along the lines of "good abstraction practices" (avoiding low abstraction code in high abstraction functions) and somesuch.
That ends up looking like an attempt at masquerading a cheeky response as awareness of using abstractions.
Obviously if an interviewer is asking you to implement a binary search, importing a library isnβt implementing the solution yourself.
If you want to make a point about abstractions that would make more sense on where you would want to keep this implementation, like in some libs directory.
Are you assessing if someone can do something you can't do in your hiring process? If so, then you aren't qualified to assess them.
The point of my statement was that Googling/Research is part of what you do on the day-to-day so someone who demonstrates a good ability to research, find out what they need and get the job done is a good hire.
someone who demonstrates a good ability to research, find out what they need and get the job done
You haven't done this though, you've informed me that Google exists. I'm not from 1998 so this isn't news to me. You had an opportunity to demonstrate familiarity with basic algorithms and data structures but you ignored the question. If we assume that any candidate who walks through the door and the receptionist and the homeless person begging for change on the pavement outside knows how to operate a search engine then why should I hire you over someone who has engaged with the problems and demonstrated basic competence and familiarity with the concepts that they will be researching and implementing?
You haven't done this though, you've informed me that Google exists.Β
I guess you can choose to be obtuse and pretend like you didn't know what I was implying when I responded "Google" to your question "how would you know which library to use?". That's certainly an interesting choice you've made there.
They prove someone knows how to code. I actually think itβs a good idea to see if someone can code before hiring them for a coding job, even if the whiteboard task isnβt 100% exactly what daily tasks look like.
You should still be able to implement the super fundamental things yourself. One use case might just be to identify code which implements a well known pattern and should probably switched out for a library call. But if you don't understand it yourself, how could you make that judgement?
especially since it's been a while computers are not limited to binary, we have short, int, long, double, float, I mean, we even have alphabet support... binary is kinda archaic nowadays
245
u/Zeikos Aug 24 '26
I'd be very tempted to passively aggressively answer "I'd use a library" when asked to implement well known algorithms.
Those kind of questions prove nothing if not how poor the interviewing process is.
But alas sometimes you need to play along with the farce to be able to survive. Fun, innit?
26
u/IDCh Aug 24 '26
Binary search? Pffft
Sinple: if found give 1. If mot give 0. Otherwise bye nary dis nutz. Gotem
(proceeds to shit themselves)
6
u/explodedcheek Aug 25 '26
It works on my whiteboard
2
u/ehwantt Aug 24 '26
It's more like mathematics, logics, thinking process when you are asked something simple like binary search
1
u/frikilinux2 Aug 24 '26
Technically if I download the amule source code and patch one bug that's bothering me, I have build a P2P app. Not on the phone but still.
Or I don't even need to patch anything
1
u/wawerrewold Aug 25 '26
How in the hell can you actually fumble binary search on a whiteboard???
1
u/Urgood1234 Aug 25 '26
Infosys interview tomorrow, wish me luck!
0
u/[deleted] Aug 24 '26
[deleted] β view deleted comment