I'm a fullstack developer, author and inventor. Sometimes a photographer and designer of my logos and UIs/UXs.
Mostly I'm working with JS and Web itself.
I've published a paper (Big O of Intelligence) about algorithm complexity of human-involved algorithms. Hope it would be useful for software architects.
Senior Software Engineer started programming over 20 years ago.
C C++ python
flask QT django
AWS GCP Airflow
k8s terraform
JS CloudDB's
rust vue TS
API backend dev
#Intp #mathematics #nerd
Haha, that reminds me of the time I did by hand something similar in my notebook for my DSA course. Surely it looks neat. Personally, I would prefer it wasn't on a black background. It would have been so much easier to read 😄 But I am one of those people whose IDE is not black so perhaps that why 😄
I am a tall (1,95m) coding & drawing enthusiast that likes all type of coding and drawing cartoons. I like to work (coding & drawing) on the go with my surface
#cypress #js #csharp
This is a good point, of course rote memorization will not replace actual understanding, and one would hope any decent interviewer would be able to instantly tell the difference. I don't think the point of charts like these is to cheat at interviews.
That said:
I've never had an interview where someone asked me about any of these CS algorithms/data structures.
This likely varies by job domain/region/experience/whatever - I've only had one interview where I wasn't asked some arbitrary academic question about a data structure I'd never need to know in practice. Technical interviews are pretty varied, and usually broken, but this sort of thing has definitely been a theme for me. Usually in the context of a challenge problem, like you said, but I've been asked to cough up and compare and contrast options to fit a problem. A huge theme of my interview experience is "okay, tell me what the Big-O of your current solution is, and then improve it given the data is constrained by whatever". Studying a chart like this helps me, at least, even though I do understand conceptually why the values are what they are.
So, yeah, I agree, that's ridiculous. I do sorta see what they're getting at though - they want to hear you talk it through. My similar example is "how many gas stations are there in the Continental US?". Who knows or cares about the answer, but a dev employer would care about how you approach the problem.
In a nutshell, I am an enthusiastic Java developer with more than 10 years of experience ranging from banking solutions to national and startup projects. These invaluable practical experiences have he
Senior Software Engineer started programming over 20 years ago.
C C++ python
flask QT django
AWS GCP Airflow
k8s terraform
JS CloudDB's
rust vue TS
API backend dev
#Intp #mathematics #nerd
Software Engineer. I am starting a platform for teaching people to be a better developer, you can sign up for updates here: https://subscribe.levelups.dev
I've published a paper (Big O of Intelligence) about algorithm complexity of human-involved algorithms. Hope it would be useful for software architects.
Thats bonkers. :)
Haha, that reminds me of the time I did by hand something similar in my notebook for my DSA course. Surely it looks neat. Personally, I would prefer it wasn't on a black background. It would have been so much easier to read 😄 But I am one of those people whose IDE is not black so perhaps that why 😄
This is why I don't like big-O.
Unless you are in O(n2) or more territory, the implementation is a lot more important than the complexity.
This is one of the most valuable topic I encountered during my study.
This is a good point, of course rote memorization will not replace actual understanding, and one would hope any decent interviewer would be able to instantly tell the difference. I don't think the point of charts like these is to cheat at interviews.
That said:
This likely varies by job domain/region/experience/whatever - I've only had one interview where I wasn't asked some arbitrary academic question about a data structure I'd never need to know in practice. Technical interviews are pretty varied, and usually broken, but this sort of thing has definitely been a theme for me. Usually in the context of a challenge problem, like you said, but I've been asked to cough up and compare and contrast options to fit a problem. A huge theme of my interview experience is "okay, tell me what the Big-O of your current solution is, and then improve it given the data is constrained by whatever". Studying a chart like this helps me, at least, even though I do understand conceptually why the values are what they are.
OH!
So, yeah, I agree, that's ridiculous. I do sorta see what they're getting at though - they want to hear you talk it through. My similar example is "how many gas stations are there in the Continental US?". Who knows or cares about the answer, but a dev employer would care about how you approach the problem.
A funny tweet but practical way to remember Big O notation :).
Its 2022,and your approach is still valid.I bet it will still be valid in 2040.
Thanks for that cheat-sheet.
my usual big-O score:
O(n3!)
awesome work.
this topic is so confusing at first and this is a great way to simplify it.
All credit to @ericrowell!