Yet another article showcasing how the tech interview process is fundamentally flawed.
Personal anecdote: I recently underwent an interview process for a position in my field of expertise (computer vision) consisting of multiple in-person stages, whiteboard coding, product design and a take-home assignment that required developing a foundational (bubble-sort like) algorithm from scratch. After successfully completing all of these hurdles, I ended up with a low-ball offer targeting entry-level candidates. If we could have discussed the compensation up front, I wouldn’t even have bothered.
It's very weird how some of those tech interviews are done. I've luckily never had to do one of those, but from the YouTube videos of training interviews and example interviews, almost everyone seems to be asked to implement a slight variation on something to be found in a Data Structures & Problem Solving book by Weiss. Great if that is what you'll be doing all day, but regurgitating some way to get the smallest number in a list or making a directed graph for a word morphing joke hardly represents anything other than a persons skill to repeat what someone else did and wrote down decades ago.
This is infuriatingly stupid. Not only does that waste your time (which we can be uncharitable and say they don't care about), but it wastes their time! i.e. costs lots and lots of money.
Is cultural? I always discuss price AT THE START, when was hunting jobs, and now as contractor, and even when I sub-contract.
In the other side, I always pitch "We do this or that, this is what we need help for, and this is how much we can pay (or: how much is your rate?)".
Is an amazing filter. Specially when you don't have much cash to give. Because: If I can't pay... why lost more time? And if I can pay and the other accept it.. only need to solve if is capable.
This is also for my customers. I put a money estimate as soon as possible, or ask upfront what is the budget range.
Is an amazing filter. Because: If I the customer can't pay... why lost more time? And if can pay I only need to solve why I'm a good fit.
Did you try asking about comp before interviewing though? I usually do and most of the time you get a reasonable answer. Probably depends on how easy it would be for them to estimate your own comp though
I recently interviewed for a job running a kubernetes cluster. I have two years of experience running a kubernetes cluster, including writing a custom provisioner and several controllers in go.
They spent two hours doing coding interviews and 15 minutes asking me about kubernetes, if that.
And that might be a good thing. How often does a normal software engineer have to write bubble sort from scratch in his daily life? If someone from my team came to me telling me he had to sort an array and wrote bubble sort from scratch, then I'd probably not be very happy with that unless there is a really good reason to spend that time on it rather than using an existing solution.
Purely anecdotally: I've seen online discourse that suggests that the complex nature of the modern web requires FE devs be able to keep at least a couple efficient data-structure traversal tools in their toolbox.
Anyone with more experience could probably chime in.
I suppose that depends on what a programmer is asked to do. There are many roles and not all of them need the same thing regarding knowledge, computer science or abstract thinking.
If you are in a position where you mostly do the same thing over and over inside a relatively complete framework for a managed or scripting language, you are unlikely to find yourself building data structures, algorithms or understand what a query planner in an RDBMS might be up to. Those positions are far more prevalent than people might think.
On the other side are the people that have to make sure that they get as much speed and/or as little memory usage as possible because they work on software that will scale (i.e. a small data structure that is used to keep track of filesystem allocations - you don't want a slow structure that also eats up a lot of disk space). But there are far fewer people that actually do that, and in theory far fewer people are needed to do that because a 'good enough' filesystem will fit all of those people from the other category. If one filesystem developer can support 100 million managed-language-framework-MVC-website engineers it's a pretty good scale.
I've been a developer for almost 2 years (I know not that long) but I have never even heard of bubble sort. Looking it up, it is O(n^2). Is there a reason this is a common interview question? It doesn't seem like a sort one would ever really use, or at least it has very obscure uses.
I always thought merge/quick sorts accounted for 99.9% of use cases and only ever really learned about those.
I agree, what's more important IMHO is education/knowledge of existing data manipulation, after all 99% of the work is reuse not pure creation (incremental vs pure innovation).
Algorithmicians (? - well... algorithm researchers, obviously) and programmers are not working in the same field of work, even though the boundary might seem thin for most, there's a world between both.
And also, even if the sort was important in my app and there was a superior compelling reason to rewrite it internally (one common case is computing 2 things at once), I would probably google what people in the domain do and think first, try to find a few blog post from people who implemented a sort to look at tradeoffs (getting a feel for the politics is in the domain: they probably critiqued each other's "real life" loads, optimization goal: memory vs. CPU vs cache), and then find something on github that I can follow, and do my tweak on.
I was once asked to sort a singly linked list in an interview, and the bubble sort was the only one I could think of at the time. This was a small part of a larger coding test that I think was based on a problem they actually ran into, which a previous employee had solved badly. I got a low-ball offer and turned it down. It wasn't until a couple of years later that I thought about that problem again and realized a merge sort would have been perfect.
I agree. In a world where good standard libraries exist, and where Google exists, why would a good software engineer write any of the standard algorithms from scratch?
Whenever this comes up, I can only assume that people are talking about very different sorts of technical interviews than I’ve ever been subject to. I’ve been working as a programmer for 25 years now and must have been through at least two dozen technical interviews in that time (one just a couple of years ago) and I’ve never had this level of pedantry thrown at me. It sounds like the poster has been rejected from a job interview for missing a semicolon or writing “length” instead of “len”. Maybe I’ve just been lucky? I did once have somebody ask me if I knew SQL - I said I did since I had written some queries using it, but not much. He asked me what command was used to add data into a database. I didn’t know (like I said, I knew the query syntax, but that was about it). That seems to me to have been a very reasonable question to ask, and a good, quick way to figure out that I didn’t really have much experience with SQL.
Somehow we arent really adept at interviewing at what the day-to-day requirements of a position.
Instead were much more interested in edge-case stuff like bubble sort.
I wonder if this is some assessment of "are they capable of substantially more complex tasks, and if so, safe to assume they're capable of less-complex minutiae.
Seems about right, as often these evaluation type things are proxies.
That's my experience as well - 30 years under the belt and I don't see interviews like this nor do I give them. I think the audience here is a bit different, startups are by definition immature and usually don't have the experience or means to set up a proper interview team that screens for the right things.
The flip side is that in mature companies like the one I work for, where professional interviews are more of the rule, we don't get the best candidates, at least not right now. I could imagine that super attractive startups can afford to set the bar higher and still get enough applicants.
>It sounds like the poster has been rejected from a job interview for missing a semicolon or writing “length” instead of “len”.
These kinds of anecdotes make me often wonder if candidates are "disqualified" for far more superficial reasons, and if interviewers hone in on pedantry like this to legitimize their reasoning perhaps even unconsciously. I have trouble believing most candidates wouldn't make at least one trivial mistake of that sort and I am equally reluctant to believe the same interviewers would disqualify any given candidate for a mistake so trivial.
The tech lead who doesn't know `len()` but claims to know Python? Yes, they're incompetent. It's okay; it's a common problem in our industry, and easily remedied by study and practice.
Chinese is not a great example. Native speakers have trouble reading and writing their own language; it is so complicated that people cannot remember how to write commonly-spoken words or how to read. [0][1] (Choice moment from [1] is when a university student says that Chinese literacy is as difficult as English!)
Perhaps we can do better as a community to design better languages, but also we should not condone people claiming that they know the languages when they clearly don't. Yes, Python could be easier; no, Python is not that hard.
In their defense, some other languages make the length of a string an attribute/property on a string instance. Python feels like the odd one out here making it a free function you must pass an instance to.
If the tech lead spent a lot of time working with another language that made the length an attribute, I think it would be reasonable for them to need to look it up often.
So you feel confident in asserting that, at the time that the person made that tweet, the quality of the Python code that they shipped was poor, or it took an inordinate amount of time to produce? All because they had to look up len()?
Anyone ever go in w/ an iron clad algorithm you've perfected then when asked 'Do you have any questions for us?' be like..yeah, I only work w/ the best developers can you beat my algorithm?
or hell just ask them if they can do a whiteboard problem for you. See how the recruiter likes it. See if they do as good as you. Flip the script so to speak!
Usually it's just 'How many years of experience do you have in XYZ?' and it's almost never enough. Doesn't matter if your experience is in something similar ('Oh you used Spring boot! We are looking for Spring MVC!') and of course they just care about decades of 'experience'--doesn't matter if you actually know it well.
Then the job ends up not having any relation to what was posted anyway, so it was all moot.
Yes, I am salty. I am sick of taking 'exciting' opportunities just to end up babysitting software that has no relation to the posted skills/requirements.
My favorite is "Yes! We'd love to have someone with broad experience who can dive in a learn new stuff!" followed by "you've read the $TECHNOLOGY_TOOL docs, but haven't deployed anything with it? Sorry, we're taking a pass..."
In theory, algorithms are an important aspect of CS. Having learned about them plus some experience, enables the logical thinking mindset required to develop better code.
In practice, algorithms are hardly useful, either because T&M don't allow it, or the problem gets escalated when adding dependencies to existing code and services.
In theory, some CS, algorithmic or systems thinking background may be that crucible required to avoid many known pitfalls and rabbit holes.
In practice, developing and maintaining IT systems have nothing much in common with sports. This being something more of a distraction by ignorance and management, than anything of tangible value to people and environment.
Asking hard brainteasers in interviews is questionable but bubble sort is so simple anyone should be able to do it or at least start writing a correct loop to go through the list and put a useful if statement in there.
If you don't remember bubblesort the interviewer could explain what the algo does and then you should be able to implement it. I'm all for looking stuff up on the web and we all have phones in our pockets but if there's to be a minimum bar it shouldn't be lower than bubblesort.
I was a little skeptical of take home coding exams but the more interviewing I do it seems to be a pretty efficient way to screen candidates as it is less stressful than live coding and more realistic "simulation" of the work they will do. It also allows you to deep dive into their thought process without having to worry about semicolons.
A persons ability to think through a problem and communicate it clearly will get them 75% through the hiring process in my books. (Another ~10% is curiosity).
Been a programmer for 20 years and doing the interview dog and pony show for the first time now. Tons of algo questions out there. Apparently memorizing algos is more important than actually knowing how to build an app front and back and knowing how a web browser, http, tcp works. And knowing dev ops and server admin and how to write maintable code. None of that matters as long as you can say which easter basket has the most eggs in O(1) time and constant space.
String length in Python is maybe too much exaggeration unless someone hasn’t wrote Python for a long time.
But, algorithms? Sure! Nobody remembers them for ever. Often you at least need to read how the algorithm works before implementing it. Obviously for most devs it is faster to just search for a sample implementation or a pseudocode.
> String length in Python is maybe too much exaggeration unless someone hasn’t wrote Python for a long time.
Or they use several languages. Say you have client side code in JavaScript, with the client served by PHP on the server. You've got some log analysis scripts in Perl. You've got some SOAP services in Java. You've got some machine learning stuff in Python. You've got a mobile app in Swift.
It's real easy to get confused about which of foo.length, strlen($foo), length($foo), foo.length(), len(foo), or foo.characters.count is the right one for the language you are dealing with at the moment.
Actually I always thought the opposite - if you started programming in the 80’s (maybe early 90’s), you had to write sort algorithms and you had to study them in college, so you’re going to be bound to remember them at least well enough to come up with the “base case” (i.e. bubble sort). I do assume that younger programmers, especially self-taught types, probably haven’t come across these to if they did, it was one lecture, once, ten years ago, memorized and forgotten because they never applied it again.
And for some algorithms (pretty much anything in cryptography) you really, REALLY shouldn't be implementing them yourself! The correct answer is almost always "use a library call" for how to do it.
Isn't one of the key skills in tech these days knowing how to avoid having to go low-level? And if not, where does it end? Should we know hardware design? Particle physics?!
The first time I heard the problem of detecting a circular link in a linked list, I figured out the tortoise/hare solution in probably 15 minutes without having heard it before, so it's not impossible.
[+] [-] glitchc|6 years ago|reply
Personal anecdote: I recently underwent an interview process for a position in my field of expertise (computer vision) consisting of multiple in-person stages, whiteboard coding, product design and a take-home assignment that required developing a foundational (bubble-sort like) algorithm from scratch. After successfully completing all of these hurdles, I ended up with a low-ball offer targeting entry-level candidates. If we could have discussed the compensation up front, I wouldn’t even have bothered.
[+] [-] oneplane|6 years ago|reply
[+] [-] 99052882514569|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] mamcx|6 years ago|reply
In the other side, I always pitch "We do this or that, this is what we need help for, and this is how much we can pay (or: how much is your rate?)".
Is an amazing filter. Specially when you don't have much cash to give. Because: If I can't pay... why lost more time? And if I can pay and the other accept it.. only need to solve if is capable.
This is also for my customers. I put a money estimate as soon as possible, or ask upfront what is the budget range.
Is an amazing filter. Because: If I the customer can't pay... why lost more time? And if can pay I only need to solve why I'm a good fit.
The less hidden variables the better for all...
[+] [-] opportune|6 years ago|reply
[+] [-] empath75|6 years ago|reply
They spent two hours doing coding interviews and 15 minutes asking me about kubernetes, if that.
[+] [-] starbugs|6 years ago|reply
And that might be a good thing. How often does a normal software engineer have to write bubble sort from scratch in his daily life? If someone from my team came to me telling me he had to sort an array and wrote bubble sort from scratch, then I'd probably not be very happy with that unless there is a really good reason to spend that time on it rather than using an existing solution.
[+] [-] Tehchops|6 years ago|reply
Anyone with more experience could probably chime in.
[+] [-] oneplane|6 years ago|reply
If you are in a position where you mostly do the same thing over and over inside a relatively complete framework for a managed or scripting language, you are unlikely to find yourself building data structures, algorithms or understand what a query planner in an RDBMS might be up to. Those positions are far more prevalent than people might think.
On the other side are the people that have to make sure that they get as much speed and/or as little memory usage as possible because they work on software that will scale (i.e. a small data structure that is used to keep track of filesystem allocations - you don't want a slow structure that also eats up a lot of disk space). But there are far fewer people that actually do that, and in theory far fewer people are needed to do that because a 'good enough' filesystem will fit all of those people from the other category. If one filesystem developer can support 100 million managed-language-framework-MVC-website engineers it's a pretty good scale.
[+] [-] Gunax|6 years ago|reply
I always thought merge/quick sorts accounted for 99.9% of use cases and only ever really learned about those.
[+] [-] Sarki|6 years ago|reply
Algorithmicians (? - well... algorithm researchers, obviously) and programmers are not working in the same field of work, even though the boundary might seem thin for most, there's a world between both.
Must all painters be artists?
[+] [-] nraynaud|6 years ago|reply
[+] [-] mark-r|6 years ago|reply
[+] [-] AnimalMuppet|6 years ago|reply
[+] [-] dickeytk|6 years ago|reply
That’s one any engineer should be able to implement without any help. It’s the more complex/useful ones worth discussing.
Even Obama knows this: https://m.youtube.com/watch?v=k4RRi_ntQc8
[+] [-] tiborsaas|6 years ago|reply
- Graphics
- Machine learning
- Gaming
Imagine yourself working in these fields and not being able to implement algorithms, you wouldn't be a super useful teammate.
[+] [-] commandlinefan|6 years ago|reply
[+] [-] delinquentme|6 years ago|reply
Somehow we arent really adept at interviewing at what the day-to-day requirements of a position.
Instead were much more interested in edge-case stuff like bubble sort.
I wonder if this is some assessment of "are they capable of substantially more complex tasks, and if so, safe to assume they're capable of less-complex minutiae.
Seems about right, as often these evaluation type things are proxies.
[+] [-] zwieback|6 years ago|reply
The flip side is that in mature companies like the one I work for, where professional interviews are more of the rule, we don't get the best candidates, at least not right now. I could imagine that super attractive startups can afford to set the bar higher and still get enough applicants.
[+] [-] Eleopteryx|6 years ago|reply
These kinds of anecdotes make me often wonder if candidates are "disqualified" for far more superficial reasons, and if interviewers hone in on pedantry like this to legitimize their reasoning perhaps even unconsciously. I have trouble believing most candidates wouldn't make at least one trivial mistake of that sort and I am equally reluctant to believe the same interviewers would disqualify any given candidate for a mistake so trivial.
[+] [-] lidHanteyk|6 years ago|reply
Chinese is not a great example. Native speakers have trouble reading and writing their own language; it is so complicated that people cannot remember how to write commonly-spoken words or how to read. [0][1] (Choice moment from [1] is when a university student says that Chinese literacy is as difficult as English!)
Perhaps we can do better as a community to design better languages, but also we should not condone people claiming that they know the languages when they clearly don't. Yes, Python could be easier; no, Python is not that hard.
[0] https://www.youtube.com/watch?v=HQh1_zyig1M
[1] https://www.youtube.com/watch?v=zxHskrqMqII
[+] [-] drizze|6 years ago|reply
If the tech lead spent a lot of time working with another language that made the length an attribute, I think it would be reasonable for them to need to look it up often.
https://apidock.com/ruby/String/count https://docs.oracle.com/javase/7/docs/api/java/lang/String.h... https://developer.apple.com/documentation/swift/string/30035...
[+] [-] Eleopteryx|6 years ago|reply
So you feel confident in asserting that, at the time that the person made that tweet, the quality of the Python code that they shipped was poor, or it took an inordinate amount of time to produce? All because they had to look up len()?
[+] [-] gremlinsinc|6 years ago|reply
or hell just ask them if they can do a whiteboard problem for you. See how the recruiter likes it. See if they do as good as you. Flip the script so to speak!
[+] [-] Gunax|6 years ago|reply
Usually it's just 'How many years of experience do you have in XYZ?' and it's almost never enough. Doesn't matter if your experience is in something similar ('Oh you used Spring boot! We are looking for Spring MVC!') and of course they just care about decades of 'experience'--doesn't matter if you actually know it well.
Then the job ends up not having any relation to what was posted anyway, so it was all moot.
Yes, I am salty. I am sick of taking 'exciting' opportunities just to end up babysitting software that has no relation to the posted skills/requirements.
[+] [-] jagged-chisel|6 years ago|reply
[+] [-] _y5hn|6 years ago|reply
[+] [-] zwieback|6 years ago|reply
If you don't remember bubblesort the interviewer could explain what the algo does and then you should be able to implement it. I'm all for looking stuff up on the web and we all have phones in our pockets but if there's to be a minimum bar it shouldn't be lower than bubblesort.
[+] [-] stephenmm|6 years ago|reply
A persons ability to think through a problem and communicate it clearly will get them 75% through the hiring process in my books. (Another ~10% is curiosity).
[+] [-] dplgk|6 years ago|reply
[+] [-] stunt|6 years ago|reply
[+] [-] tzs|6 years ago|reply
Or they use several languages. Say you have client side code in JavaScript, with the client served by PHP on the server. You've got some log analysis scripts in Perl. You've got some SOAP services in Java. You've got some machine learning stuff in Python. You've got a mobile app in Swift.
It's real easy to get confused about which of foo.length, strlen($foo), length($foo), foo.length(), len(foo), or foo.characters.count is the right one for the language you are dealing with at the moment.
[+] [-] commandlinefan|6 years ago|reply
Actually I always thought the opposite - if you started programming in the 80’s (maybe early 90’s), you had to write sort algorithms and you had to study them in college, so you’re going to be bound to remember them at least well enough to come up with the “base case” (i.e. bubble sort). I do assume that younger programmers, especially self-taught types, probably haven’t come across these to if they did, it was one lecture, once, ten years ago, memorized and forgotten because they never applied it again.
[+] [-] SAI_Peregrinus|6 years ago|reply
[+] [-] kiba|6 years ago|reply
[+] [-] growlist|6 years ago|reply
[+] [-] arthev|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] kps|6 years ago|reply
[+] [-] mark-r|6 years ago|reply