Leetcode has taught me that I'm a bad engineer
I've been at it intensively for a couple months and my mind simply refuses to cooperate. If anything, after having done 400+ problems I seem to be worse at them than when I started.
Since your time is more valuable than mine, let me summarize:
7+ YoE, MSc. in some science (like it matters)
Last 4 years been mostly ETL with Spark and some backend thrown into the mix with a "senior" title for devops and mentoring noobs.
I used to think this job was a creative one, since writing frameworks and libraries for further use, documenting code and extreme programming made me think that I was building something new and useful.
In fact, due to having extreme ADHD the only thing that kept me distracted during all my overtime was the ability to pursue fun and challenging things. MPP and all the cool stuff you can do with modern tools is fun, interesting and challenging.
Leetcode isn't about fun and challenging things, it's about thinking in one particular way, spitting out solutions using the same exact data structures and jumping through hoops on command without philosophizing or creating anything that can be reused/extended.
This is also what Software Engineering has become: you memorize, regurgitate and participate in agile the masquerade. Creativity is shunned. Tried architectures/patterns are what is expected.
I wish I had practiced law for the past 7ish years instead, because at least all of my skills would still be relevant.
473 comments
[ 8.6 ms ] story [ 368 ms ] threadThe nice thing is that there are lots of jobs out there that don't require leetcode skills. Sure, there are many jobs that do, too, but you can avoid them by looking at the job req.
Source: I too am bad at leetcode but have had many jobs in my career, including three different employers since 2019.
ask the first recruiter? put it in your emails? ask your friends about their employers?
Alternatively check out my other post in this thread if you’re looking to target those non-LeetCode jobs specifically!
https://airtable.com/shr5TdnpVYVTpeRrN/tbluCbToxQ2knSLhh
Similar to the first link, as a github repo: https://github.com/poteto/hiring-without-whiteboards
Information related to companies, their culture/values, and hiring process: https://www.keyvalues.com/
Also, I've found that smaller companies and consulting companies tend to avoid leetcode style interviews. #anecdata
Yup -- brain fog, paralysis and negative performance are the sure-fire signs of burnout (as least as pertains to your capacity for grinding LC). Excellent preparation for the daily grind of actually working for companies that rely on these tests.
Leetcode isn't about fun and challenging things, it's about thinking in one particular way, spitting out solutions using the same exact data structures and jumping through hoops on command without philosophizing or creating anything that can be reused/extended.
Exactly. And these are apparently precisely the "skills" these companies are "desperately" seeking to find among the engineers they invite for an on-site interview.
And don't forget the strong "culture fit" signal indicated by the sheer willingness to grind, grind, grind.
You memorize, regurgitate and participate in the agile masquerade. Creativity is shunned. Tried architectures/patterns are what is expected.
That's ticket. This is exactly the mindset these companies are after. That's why they swear up and down on the efficacy of these tests.
On the bright side: at least you've been freed of any illusions, by this point, about the intrinsic value of your advanced hard science degree.
The science degree was useful for when I did advanced math, before the finance industry figured it would just abandon complex math in favor of statistical learning.
Don't get me wrong, I burned out for other reasons, but if you're looking for a job writing math oriented software, they are out there. Maybe consider finding a new area. Maybe take a break first though :-)
I’m very happy with my current employer. They’re hiring. Want an intro?
I see someone at microsoft was a fan of The Shamen.
https://www.youtube.com/watch?v=SpjnzxtZ6Qg
But, is that it? In the US, at least, not a lot of employers will give a straight up test of general mental ability (IQ test), likely because they see it as potentially attracting lawsuits. This is because IQ tests show a well-documented racial disparity in scores, which has not been shown to be correlated with anything genetic. Rather, the problem is either traced back to differences in family socioeconomic status growing up, or cultural bias issues with the tests.
Everything in the previous paragraph can be verified in a few minutes of Googling, so, I'm not going to litter this comment with citations when the obvious keywords will produce the information mentioned here. But, everything else, including what's to follow this, should be considered pure speculation on my part.
Given all this context, I can only think of 2 obvious reasons companies resort to using LC or LC-style interviews:
1. As a proxy for a test of general mental ability, as previously mentioned, or
2. Cargo culting, as with the whole "How would you move Mt. Fuji?" phenomenon.
I don't personally have a great deal of insight into which it is, or, if there's a third explanation that I'm completely missing. I also don't know whether there's any research supporting or refuting the idea that LC puzzles provide a valid interview signal for software engineers. All I really know is that these type of problems exercise skills that are not what one uses on the job as a SWE, so, it seems rather illogical to use them as a main component of your hiring process.
https://en.wikipedia.org/wiki/Imperial_examination
https://en.wikipedia.org/wiki/Eight-legged_essay
If conscientiousness is what companies are going for, I think they're still interviewing wrong.
In my case, when I grind those dumb problems I quickly go from needing 45+ minutes to implement a working sort function with file I/o to banging it out in 5-10 minutes. I dunno if I'd ever get good enough at those problems to make it into Google unless I got lucky, but I've gotten offers from the other FAANGs over the years
The whole thing is pointless, though. If a junior engineer asked me for advice, I'd tell him to get whatever job he can and work on saving money/building a startup in his spare time.
Grinding for months to get into Google is so soul crushing, and working for any big company is just awful in the long run compared to being independent
I started out thinking I was pretty smart but got blasted by a fairly simple question on my first screening interview. I started looking at random leetcode questions but that didn't really work - I soon figured out that I needed to learn the concepts one at a time. I think that is the way to do it, get a list of general topics, learn about it, then practice just those questions until it clicks.
That's not sour grapes, either. I have a CS degree and worked through math and logic puzzles for fun from the time I was 6, well before I ever knew what a computer was. Interviews like this are practically made for someone like me, but even there, the signal you're getting is I'll gladly do something I like doing anyway, not that I'm going to show similar conscientiousness when it comes time to get into your daily company grind that actually has nothing to do with solving interesting algorithms puzzles.
And as such, is likely to cause them to develop cynical attitudes about the industry -- and about the companies requiring these tests, in particular.
Essentially I agree with you - most of the reason is cargo culting Google.
Assessing software engineers is hard. A couple decades ago, Google (which at the time was a tech darling, and the #1 place to work) had a saying of "A players hire A players. B players hire C players". Essentially they were terrified of hiring bad people, because they figured the company would inevitably go downhill if they did. Their hiring process was essentially an expression of this idea - it was based on the philosophy of "we're all A players, but are you as clever as us?". Interviewing at google at the time involved sitting about 6 back to back whiteboard interviews with programmers. Each person would spend ~20 minutes asking you their favorite puzzles and things, and seeing how you did. Nobody can say this because it would be illegal, but it was in many ways a programming themed IQ test. Good questions were the ones which filtered candidates out. And its easy to recommend against hiring someone if they couldn't reverse a binary tree on a whiteboard in 20 minutes. (I mean, thats easy for me! They must be a C player.)
Other companies followed suit. I mean, hiring is hard. Why not just copy Google's approach? Microsoft did something similar. Facebook was full of ex-googlers, etc etc.
The problem is that being able to reverse binary trees doesn't correlate with how well you can manage a database, style a form, fix a memory leak or talk to your team. And the people who only had those useful skills are unhireable. Oops!
In my opinion, the right way to interview programmers is to make a list of skills you want your programmers to have (coding, debugging, CS knowledge, communication skills, architecture, ...) and then find ways to assess each one. For example, to assess debugging you can give your candidate some pre-prepared code with failing test cases and see how many bugs they can fix within 30 minutes or so. But that requires preparation and test calibration. Most companies struggle to convince their engineers to interview someone for 20 minutes - let alone spend a few days putting together a problem like that.
Knowledge of data structures and algorithms is useful, and it is a positive signal about a candidate. But (depending on the role) I'd weight it below communication skills, raw coding skill and debugging. Those are all much more valuable. We need to start treating them as such.
I heard that Google search is now performing badly in many key areas.
But that doesn't mean it's the fault of the engineers - and most likely it isn't.
Rather, the product people (who are also not dummies) basically realized that "dumber" results were more profitable, for various reasons -- most likely to do with "engagement" and prioritizing what 90 percent of the users will versus the needs of the other 10 percent.
The tricky thing is that no matter what test you contrive, it's more likely to say something about the developer's recent experience than about their competency in general.
For example, I'd say I have pretty good intuition for when to just read code or sprinkle printfs or fire up valgrind/gdb/asan when debugging C. Which I guess is to be expected given that I've been doing C almost exclusively for many many years. I'd do pretty bad with Haskell; the last time I really used it was around 13 years ago. The next guy might be a bit lost with gcc's error messages since the last time they used C in anger was 5+ years ago for a small project, but they'd do well if you hand them Python code that uses a well known unit test framework or whatever. I guess that's fine if you're a run of the mill crud company looking for "senior <foo-language> developer" but not if you're after general competency.
You can try hard to make the debugging be more about the system than about the implementation but it's not easy to separate the two. You can make different tests for people with different backgrounds but that only makes calibration harder.
One trick I've seen a company do is deliberately pick a very obscure language that most people have never heard of. That can eliminate some variables but not all of them (I took the test and did well but I also spent a fair amount of time studying the language to figure out if it's suitable for a purely functional solution before handing in a very boring piece of imperative code). Ultimately it wasn't much more than a fizzbuzz.
And if there's puzzling involved, I'd say there's an element of luck involved. At least that's how I perceive the subconscious mind to work when you're thinking about a problem that isn't immediately obvious or known to you beforehand. Which path does your mind set you on? Are you stupid or incompetent if it happened to pick the wrong one today and you spent 10 minutes thinking about it too hard? Are you super smart if the first thing that came to mind just happened to be the right one and you didn't doubt yourself before blurting out an answer?
If you're lucky and know the problem beforehand, you can always fake brilliance: https://news.ycombinator.com/item?id=17106291
That is to say, test calibration is hard and there are so many variables involved. It follows that there's no obvious right way to conduct interviews. And I guess it follows that companies who need people (and aren't necessarily experts at interviewing) effectively outsource the problem by conducting the same type of interviews they've seen elsewhere. Maybe that's less cargo culting and more just doing whatever seems popular and good enough?
I’ve done hundreds of interviews like this, and it’s fascinating watching what people do. Do they read the code first? Fire up a debugger? Add print statements and binary search by hand? I had one candidate once add more unit tests, to isolate a bug more explicitly.
After hundreds of interviews I still couldn’t tell you which approach is best. But if there’s one trend I noticed it’s that more senior people (& older people) seem to do better at this assessment. Which is fascinating. And that implies it’s not simply a test of what tools the person is familiar with most recently.
As for luck, I agree this is a problem. It’s mitigated somewhat by having a bunch of easy bugs to fix instead of one hard one. But even a debugging problem like this should be one of a set of assessments you perform. If you fail 5 small assessments in a row it’s probably not luck.
If you want to test raw coding ability, asking someone to implement some very basic graph or tree traversals is a pretty good way to see if they know the basics of conditionals, loops, recursions, maybe hashmaps.
If you want to see someone debug something, and you make them run their code it will inevitably fail or not compile the first time...so they'll have to debug.
I hear what you’re saying, but that doesn’t assess what I want to assess. We all have experience debugging our own code, that we just wrote. But how well can you read someone else’s code? How well can you find and fix bugs in it? It’s a different skill! And it’s vital in a team setting. Or when you’re depending on complex 3rd party packages (which is most of the time).
I want coworkers who can read the code I write and debug it when it breaks. That’s a much more useful skill than what leetcode problems train.
That isn't true; the correlation is visible when you look at the scores of people with mixed ancestry.
https://www.bmartin.cc/pubs/01BRrt.html
What we do is a craft. Those things on lc are the foundations of our craft. I want to know everything about my craft, and a lifelong student of it, so I like sites like lc.
I’ll take it over trying read page after page of some big comp sci book.
This is incredibly dependant on your company, team and role. I’ve been knee deep in data structures and algorithms for the last year. When I was at (FAANG) years ago I worked with people who did this stuff full time. You’ll find roles which use these skills in AI, AAA game dev, finance, operating systems and so on.
But probably 95% of commercial work is styling and wiring buttons. Even at big tech companies most of the work is plumbing. The skills you learn on leetcode are completely irrelevant in those roles.
We're in agreement that algorithms as such probably make up about 5 percent of industry work.
But the other 95 percent -- and I am talking engineering work, not product desgn -- is definitely not simply "styling and wiring buttons". And this is a very myopic view to have.
I recommend Introduction to Algorithms [1]. Books like that can be really dry and hard to read, and they usually are, but they contain fundamental knowledge about computation that is the only way to solve some hard problems (and there are many hard problems that remain open). Leetcode problems, if they're any good, will simply be exercises based on the concepts in such books. But you won't understand the concepts just by solving the exercises.
My experience is that I spent seven or eight years coding in Prolog (that's how I roll, OK? Don't judge!) and while I had become skilled at it, I didn't really understand how it worked until I started my PhD at which point I really had to sit my bum down and read a whole load of stuff I didn't even know existed.
You'll probably say "what do I care? I'm not in academia". Yes, but you think of programming as a craft, right? And a crafts-person is happy to constantly improve his or her craft. Well, a PhD is one way to do that, sticking with industry for many years, if you can find the right positions, is another. But one way or another you'll eventually find yourself at a point where just solving coding exercises doesn't give you anything new. That's when you turn to the books. If you don't, then you should be concerned: it means you're not really advancing, not getting better in your craft.
I'd have a lot more to say about programming as a craft. Instead, let me point to Peter Norvig's timeless essay:
Teach Yourself Programming in Ten Years
https://www.norvig.com/21-days.html
And to this book by George F. Luger who introduced me to the concept of the "Master programmer":
AI Algorithms, Data Structures, and Idioms in Prolog, Lisp, and Java
https://www.cs.fsu.edu/~cap5605/Luger_Supplementary_Text.pdf
I'm also linking those for anyone else interested in that kind of thing. Happy reading.
___________
[1] It's online here:
https://edutechlearners.com/download/Introduction_to_algorit...
No idea if that's a legit download or not.
Also lifelong student? Have you ever felt that everything you learn is just the industry moving in circles?
As a result everyone just makes up anecdotal "patterns" without proof that those patterns satisfy any quantitative "efficiency" criteria. Again this "efficiency" criteria doesn't really exist, we have some numerical metrics for measuring certain things but we can't really say definitively which is more organized the windows code base or the linux code base.
So in terms of these kinds of things. Nobody really knows who does what better. Does hiring people who can solve LC type problems result in more "organized" code? How can we know when we don't even have the word "organized" defined? The existence of this problem in CS doesn't make CS harder because everybody is basically ignoring this problem and just picking arbitrary solutions aka "patterns" to solve things.
Coding is like physical construction, unbounded by the rules of physics and therefore MUCH MUCH easier then engineering a boeing 747. Try learning building a 747 from a bootcamp. You can't. Coding bootcamps exist because it's freakishly easy to learn programming while engineering a 747 is freakishly hard, hence the lack of bootcamps for building airplanes.
It's like making legos to fulfill your goal. In the end the thing we build with these legos likely isn't the most theoretically efficient thing but it works and we didn't need super high intelligence to build it and we don't need someone smart either.
The thing with programming is this. It makes you feel smart. The reality is, your not.
No, this is exactly backwards: engineering software is much much harder than engineering a large airplane. The latter is bounded by laws of physics, which acts as a global coordinator between parts and teams. There are no global constraints in software engineering and therefore coordinating modules and teams are very difficult. We have to come up with a set of constraints to achieve these goals, but the search space for the correct constraints is almost infinite. Enforcing these constraints is another issue.
> Try learning building a 747 from a bootcamp. You can't. Coding bootcamps exist because it's freakishly easy to learn programming while engineering a 747 is freakishly hard, hence the lack of bootcamps for building airplanes.
This is a false equivalence. Coding bootcamps are akin to learning to assemble parts --- nothing like engineering software.
Your joking or highly highly misguided. Very few corporations have the ability to manufacture/designs planes. Tons of software engineering firms exist that hire coders out of bootcamp. Global constraints makes problems harder. Why? because these constraints are extremely hard to figure out. They can be modeled with differential equations but much of the constraints can only be determined through building an actual model and experimenting with them.
>This is a false equivalence. Coding bootcamps are akin to learning to assemble parts --- nothing like engineering software.
This is a true equivalence. Let me explain to you. THERE are many people who can't "engineer" software after they come out of a bootcamp. BUT there are tons of people who come out of a bootcamp and CAN engineer software. That's why people say you don't even need to go to school to learn how to program. You don't even need to go to school to learn how to "ENGINEER" it's easy.
Now for engineering a plane? I can assure you. An aerospace engineer can't EVEN engineer a 747 OUT OF UNIVERSITY; it's that hard. It's also fundamentally impossible for a plane engineering bootcamp to even exist due to the sheer challenge of it.
You have a misguided notion of how hard software engineering is. Software Engineering is Ironically the easiest "engineering" discipline out there yet one of the highest paid.
So what? The reason could as well be market dynamics. By the same reasoning we could also argue that software engineering is the hardest, because it is the highest paid one.
> You have a misguided notion of how hard software engineering is.
Software engineering is not programming, just like aerospace engineering is not assembling a plane.
> An aerospace engineer can't EVEN engineer a 747 OUT OF UNIVERSITY; it's that hard.
Let me rewrite that: A software engineer can't even engineer a Google out of university; it's that hard.
I don't think this discussion is being fruitful to me. I hear personal attacks instead of counterarguments to the ideas I presented. So, I won't be replying further.
Apologies for you thinking this it's not my intention to personally attack you, in fact I didn't. I think you're just perceiving it this way because my language is very to the point.
Saying you're misguided when you actually are is not an insult btw. It's not your fault or some kind of attribution to your intelligence when I say so. It's simply you are misinformed. Likely you are also very young.
Either way... I myself am a more logical person so "personal attacks" don't effect me if the possibility of new knowledge being imparted to me is greater than zero. This is the logical way of perceiving things. You obviously are less logical so your reasoning can be forgiven.
>So what? The reason could as well be market dynamics. By the same reasoning we could also argue that software engineering is the hardest, because it is the highest paid one.
lol market dynamics. No the reason is because it's harder. There's only two companies in the world that can build passenger airliners. There is tons of room for more competition. The duopoly is held because very few companies can build these things to the scale and speed as boeing or airbus. China is making a huge endeavor to gain these skills and after several decades their planes are still not ready for mass production. See below for evidence:
https://www.youtube.com/watch?v=4n3R1xQzs3E
This isn't the only example. Let's go with semiconductor manufacturing. Currently there's a shortage of computer chips. The "MARKET DYNAMICS" demands for tons and tons of companies to fill the space... but guess what? China and the US don't have the knowledge or the know how to fill the gap. TSMC and ASML two companies from Asia and Europe respectfully are just a few companies out of a handful that can do build chips at the 5nm process. Intel is still behind.
Meanwhile no company on the face of the earth has a monopoly on "software engineering." Why? because it's easy. Anybody can do it.
Take a look at this: https://en.wikipedia.org/wiki/Software_engineering#Tasks_in_...
There's zero science, axiomatic proofs or empirical evidence that is part of the definition. It's all just "planning" guidelines masquerading as some kind of mathematical formalism. It's not. It's just a made up series of steps for creating software. I can easily make the same set of formal rules for company bylaws or planning some event.
>Software engineering is not programming, just like aerospace engineering is not assembling a plane.
Software engineering? You mean agile? lol. or simple stuff like unit testing? Even agile isn't part of any theory. and best practices like testing are easy. These are just made up formal rules that we "think" work. Let me be honest with you, if engineering practices from software were applied to other forms of engineering you would be laughed at. Also people would begin dying if agile was used to hack on features onto an airplane. See the boeing 737.
>Let me rewrite that: A software engineer can't even engineer a Google out of university; it's that hard.
You realize google doesn't care what university you went to or even if you went?
https://analyticsindiamag.com/why-google-believes-you-dont-n...
Google is built and maintained by many people who never went to university. Additionally do you know about th...
> Try learning building a 747 from a bootcamp. You can't.
Yeah, try doing that with an engineering degree. You can’t.
Try grabbing a random Boeing engineer and get them to build a 747. They can’t. No one can.
Okay, I should be more charitable. You mean can’t contribute to a portion of the 747 project? Yeah, college isn’t necessarily going to help you much either, and you might be surprised what a smart person off the street can do… there’s a really good chance your boss just has a bunch of spreadsheets for all her maths. Yeah in the grand scheme of things you’ll have to learn how to do that too, but it may not be the barrier it seems.
I’m a SW Eng, but did and entry level EE gig, and basing my experience on that. College did not prepare me at all. Engineers routinely enter industry without knowing what a relay is (and we used ladder logc!). Btw, we had self taught non-college educated “engineers”… they'd usually be talented operators that knew the machine like the back of their hands. So that’s basically an ME without a degree.
I did a stint on an F-16 project after switching to computer engineering, and it was the same shit. Almost everything was learned on the spot from the veterans or google for general stuff.
So yes, I could have worked on F-16 off the street, as well as done EE work and it really seemed like my ME friends were grinding out the same BS.
Where are all these super special engineering people you so admire? Some of them do get very specialized education, but we were talking BS Engs.
P.S. I do agree about the accessibility of programming. There actually are many topics that are hard to self learn, for example comp arch would be very challenging without a good professor. There’s many others, that’s just what sticks out as “thank God I went to uni so I could learn X”
I think the analogy works. No single engineer whether out of university or not can build a 747.
However a single person built a search engine. Duckduckgo. The person didn't even have a degree in software engineering. He had a physics degree.
I see your point. Let me put it this way. Somewhere in building the F-16 or the boeing 747 there is a form of theoretical modelling that must be done as a fundamental thing in order to build it. You need to calculate the flight dynamics and mathematically model the control system using math skills that cannot be obtained by attending a bootcamp.
Most of these skills can only be obtained through several years of practice, and a bootcamp doesn't offer that. Granted there are many parts of engineering a 747 that don't need these deep design skills so you can get away with not knowing what an ODE is while being an engineer.
For a single person to be able to do everything (not familiar with your examples, so I can't speak to the truth of it, but accepting your premise), the implementation must be sufficiently simple. You CANNOT provide an adequate solution to a slew of technical problems by yourself. There are many topics in SW Eng that CANNOT be done by a single person. Impossible. You can build a plane by hand by yourself. People do all the time. I had a boss that did. Sure he's buying parts and not eg designing the body himself, but no one ever really did.
At one point there were no planes, but over time we learned to do it better and better. At every step engineers were learning the ropes from industry veterans, then adding their own innovations. Not that different from a guy putting together a plane from parts. You could point to more complicated areas where harder technical concepts are applied, but that really just works the same. You learn x software, and y methods (again from the veterans NOT from Uni), then you add your innovations.
You think Boeing is designing all their parts, on one team? No it's mostly people cobbling together parts from suppliers and other teams, digging under the hood for some things, tweaking similar designs, managing, "business stuff", ect. That's the vast majority of engineering, even outside of software. A high percentage of people won't touch the stuff they learned in school, or just a tiny piece of it. They're getting most of their information from the professional greybeards from within their industry.
I do agree that things are a bit different in software engineering, but not by as much as you seem to think. We could probably get a lot of traditional engineering prospects off the ground with an intensive camp. This makes a lot more sense in software for a variety of reasons (IMO mainly because there's SO MUCH of this kind of work to do), but I don't agree that it's impossible in other engineering domains.
It seems like you'd have to make a comparison that is not apples to apples, eg. comparing a master/phd educated, highly-specialized ME to an entry level software engineer. A better comparison is comparing a run-of-the-mill developer to a basic ME working in a plant. Things aren't so different there. You can also compare a specialized SW Eng, eg. working on algorithms themselves to the kind of aerospace engineers your picturing. Things don't look so different then, I think.
That's my point. In software engineering these specialists aren't required. Like actual deep mathematical knowledge isn't needed for software engineering.
>They're getting most of their information from the professional greybeards from within their industry.
Of course, I never disputed this. However there is a foundational knowledge in say something like ME which is more reliant on schooling. This foundational knowledge is required to understand the greybeard. For example kinematics and calculus. Just getting up to that point requires at a minimum.. two years of training in school.
Plenty of software engineers don't know calculus or trig. That much I can assure you because it's rarely required.
> That's my point. In software engineering these specialists aren't required.
That's not really true. I mentioned this in my comment. There are many areas of software and computing that DO require specialists. Elite teams or team members that tackle really really hard problems that much of the field then uses. So there's really no difference there at all.
Do you work in ME? It sounds like you have a glamorized idea of what a lot of other engineers do. I can assure you that the vast majority of them are not using specialized knowledge. It doesn't really seem that different to me. I can assure 100% that it's the same in EE, because I've done that, and it was almost exactly the same. (of course, it's fair to point out the similarities between EE and CS, but again all my ME friends reported the same kind of stuff).
A certain amount of People can get by, but the project itself cannot get by without a minimum people on that project knowing this stuff.
For your typical software project, the entire project can get by without anyone knowing anything from algebra and beyond.
>Linear algebra, trig, even basic diff eq and calculus is relatively easy to pick up independently IMO.
Less likely for people learn this stuff outside of a school. It can be done without school but the likelihood of learning these things without school is low because learning these things is about 10x harder than programming. Developing the intuition and familiarity with this is very rarely done independently.
Additionally, these are the bare minimum required for engineering. Complex analysis, control system theory, kinimatics, physics, circuit analysis and much much more are required for systems engineering. And almost nobody starts learning this stuff as a "hobby." Basically people pick up learning django or rails as a hobby or something along those lines.
>Do you work in ME? It sounds like you have a glamorized idea of what a lot of other engineers do.
I'm EE, switched to CS after graduation and I work in embedded systems with mechanical engineers and other EEs.
Yes the day to day doesn't require solving an ODE. But the basic knowledge is required in some aspect of the project. The same is NOT true for software.
>There are many areas of software and computing that DO require specialists.
Very few. ML or Data is mostly what I see but you're average web development shop has sw guys who are roughly homogeneous in terms of skills. Any specialization is domain knowledge as in he's the guy that coded that maze so he's the guy that knows it best.
There are "specialists" but the crossover is so close that all these specialties can combine and you encounter tons and tons of people who are "full stack" engineers.
https://hillelwayne.com/post/are-we-really-engineers/
No-one ever seriously asked me how to make a program bug free. They also didn't ask me to use formal methods or prove any properties of the system I'm asked to implement. Hell, I can tell that I want to spend time developing tests and they say no, nah, we don't want that. Everywhere I've been it's been more important to deliver stuff quick and cheap than it is to make it perfect. Maybe places where extreme focus on quality do exist, and you only hear about them when the extremely unlikely catastrophic failure happens. But that's not the norm.
Analogies to real world rarely fit but I think most software is like most construction: houses and flats and small commercial buildings where you can and regularly do get away with shoddy stuff and blemishes. The usual thing complaints are about are schedule and budget overruns, and then when everything is done, all the faults and rushed parts they find... Guess what, they like cheap and fast in construction too. In every place I've lived, I could point out many many little snafus from walls that aren't quite straight, misdimensioned boards and panels and other things that just don't quite fit, design issues such as doors obstructing important paths or not having room to fully open, etcetra.
And you get away with it because your house is not going to fall apart because of a missing nail. Likewise for most software. Just another bug? Fix it and move on. Or maybe even leave it in if it's not catastrophic and there's more important things to do. The bar for quality is generally pretty low.
So houses are made from shoddy workmanship. Software is also made with shoddy workmanship. How does this analogy prove that software engineering is not the easiest engineering field out there?
I would argue that it proves software engineering IS the easiest engineering field out there because you can get away with this shoddy workmanship. In fact the engineering process of software engineering are centered around shoddy workmanship and throwing in and developing features without any sort of plan. See agile for more info on this process.
Outside of this kind of stuff, software engineering is easier than most other forms of engineering due to an accepted lower bar of quality.
To bad engineers, I can see how it looks easy and that it is "moving in circles". It is still a relatively new discipline, and as such, still finding a lot of the process, tools, and techniques that other disciplines have developed. Plus Moore's Law and its ilk change things constantly.
LOL this is an insult. Let me put it this way, you're right but I can bet you haven't done anything worthwhile either. Anything you've built as a software engineer, I can 100% build as well. There is nothing you can do that I can't as a pure software engineer. In fact likely everyone on this thread can build anything you've built and likely do better as well.
But let me be clear. If you programmed CAD software that can simulate an entire boeing 747 flying through the air... that is a feat that not many software engineers can do. But this doesn't count because it's combining two engineering disciplines (even a PRB renderer doesn't count.
Something like an OS would be an example of a pure software engineering approach.
Also I never said software is easy. I said it's the "easiest." Big difference.
IN ALL of engineering it's highly unlikely for all engineering disciplines to be equally hard. highly highly unlikely. All engineering disciplines must overall stand at some general point in the challenge spectrum. You could say the answer is too complicated to answer as there are jobs in say chemical engineering that are much harder than certain jobs in mechanical engineering and vice versa but regardless a GENERALITY of hardness exists.
What engineering discipline in your mind is than the easiest if not software engineering? Tell me. What other engineering discipline to practitioners don't require any schooling are hired without a degrees and you can easily form a start up around with less effort? Why don't we see a bunch of spaceX startups but see a ton of startups building some stupid dashboard for a niche?
I'll give you a hint. Because when you compare rocket science versus computer science, one of these fields is GENERALLY easier.
> I can see how it looks easy and that it is "moving in circles". It is still a relatively new discipline, and as such, still finding a lot of the process, tools, and techniques that other disciplines have developed. Plus Moore's Law and its ilk change things constantly.
How it looks? I've been in this industry for years. I can assure you it's not a "look" thing. It's a TRUE thing. The industry does move in circles.
There's no mathematical theory on how to organize code so we make shit up and call them "patterns" but there's ultimately no actual proof that one pattern is better than another and we're not 100% clear about the tradeoffs diving in. That's why the industry moves in circles. It oscillates between two solutions and it can't figure out which is better.
For what use case is a monolith better or a microservice? What software design pattern is actually better for what use case? Can you plug it into an formal equation and optimize the best design pattern to use for a certain case? You can't... because no theory exists.
But no theory needs to exist. You can hack a half assed solution and that's really all that's needed. Even if you don't "hack" a solution together nobody can really prove whether your "designed" solution is better. A stupid engineer can design something and think he's a genius but without theory nobody can prove whether his design is the best one possible.
And that is why software is easy. Anything goes. It's like building 1/32 scale model of the eiffel tower out of toothpicks. Is there a theory behind it? No. Is it easy to do? No. Can anybody do it? Given enough time, Yes.
I don't understand your reasoning. You say that it's possible to "hack a half assed solution" that somehow works and from that you conclude that software is easy (or the easiest, doesn't matter)?
Aren't you contracting yourself? If software is easy why do you produce a half-assed solution? If it's so easy why isn't your solution of high quality like the 747? Maybe it's not so easy to write cheap, bug free, portable, maintainable, compatible, little-resource-consuming, high-performing software?
I can also build a half-assed airplane. It will crash often, not do what I wanted, and I will use a lot of off-the-shelf components (engine,...), just like modern software... That must mean building airplanes is easy, right?
Edit: It would be more correct to say it like this: Creating software is hard and poorly understood at the moment. Even worse, people writing software are not trained well. But since the expectations of our customers are low (compared to the expectations we have to, for example, an airplane), the market tolerates this.
Edit 2: By the way, I agree with most of what you have written about the industry moving in circles, half-assed solutions, using patterns and frameworks without any deeper understanding. But that's actually proving that software engineering IS hard. (or maybe it's easy but nobody cares)
That's why it's easy. Finding a formal theory for software organization is hard so it hasn't been done yet. We make do with design patterns and many of those patterns are outright mistakes.
As it stands without "Computer scientists" establishing a formal theory on this... Software engineering is a shot in the dark and therefore easy.
>I can also build a half-assed airplane. It will crash often, not do what I wanted,
An airplane can only crash once. And when it crashes, people die. That's why no airplane is ever half-assed. Building an airplane is hard because of these requirements. Building software is easy because the requirements ALLOW for it to be half assed. Does my OS crash once a day? Still somewhat useable... Does my plane crash once a day? Holy shit.
>Edit: It would be more correct to say it like this: Creating software is hard and poorly understood at the moment. Even worse, people writing software are not trained well. But since the expectations of our customers are low (compared to the expectations we have to, for example, an airplane), the market tolerates this.
Hence why Software engineering is one of the easiest engineering disciplines out there.
>Edit 2: By the way, I agree with most of what you have written about the industry moving in circles, half-assed solutions, using patterns and frameworks without any deeper understanding. But that's actually proving that software engineering IS hard. (or maybe it's easy but nobody cares)
I would argue that this is more, computer science is hard rather than software engineering. The development of new techniques and greater understanding is the domain of science and academia. Engineering is about solving existing problems with existing techniques. Software engineering as it stands is easy.
There's two ways of handling software that's safety critical. For software that needs an extreme level of safety... formal methods are employed to prove correctness and that software is bug free. For this part of computer science the foundational theory is well established. This part is really really hard which is why 99% of software engineers don't even know what I mean when I say the word "formal methods." It's so different from traditional software that it's never ever referred to when people use the term "software engineering." We have a rudimentary form of it in the form of type checking in our programming languages.
But there's another part of it as well involving empirical testing. This is popular in the industry and engineers use the term unit testing or regression testing to refer to it. It's a shot in the dark. Basically taking a couple test samples out of an huge sample space of possible tests and saying if those samples work then likely the whole thing works. IF you want to prove your program correct using this method you would have to run every single possible test that exists on your program. It's untenable so we informally rely on a statistical phenomenon of taking a sample of tests out of a huge sample space.
This is the most common way of creating safety critical software that everyone uses because it's easy. Don't mix tediousness with easy. Using this methodology is very tedious, but I would argue quite easy.
Also redundancy and fail-safes in logic are used throughout the system for safety critical software. This again is easy to implement but tedious.
>Although I would guess that many of those developers are indeed software engineers and not aerospace engineers by training.
Yeah most of the mathematics in this case is modeled by system engineers or other engineers that are more specialized than the math is handed down to the software guys who only need to understand the equations but they don't need to understand how to derive those equations.
During testing the software engineers and hardware engineers would have to work together to make sure the software operates the hardware correctly. If the hardware is simple or well established and accessible often the software engineer can do the testing alone.
Sometimes the engineer of the physical system itself just programs it himself. Alot of non-software engineers are like this because software engineering tends to be easy so they can just learn how to program.
> Also redundancy and fail-safes in logic are used throughout the system for safety critical software. This again is easy to implement but tedious.
I wouldn’t call implementing redundancy and fail safety for a fairly complex system easy though. Tedious, yes. And tedious but easy probably could describe lots of other engineering work as well, not only software.
> Sometimes the engineer of the physical system itself just programs it himself. Alot of non-software engineers are like this because software engineering tends to be easy so they can just learn how to program.
They might believe that it’s easy to write some software that in some way solves the problem but in my experience they don’t always engineer good software, and don’t always realise that their small part of the program has to work together with a huge amount of other software. Not that all software engineers do this either..
What's the cutoff for IQ then to implement a redundancy. Is there really a mediocre software engineer who can't do it. My argument is with a lot of effort any software engineer can do it. And if anyone can do it.. it's easy.
>They might believe that it’s easy to write some software that in some way solves the problem but in my experience they don’t always engineer good software, and don’t always realise that their small part of the program has to work together with a huge amount of other software. Not that all software engineers do this either..
As I've stated before. There's no logical theory behind program organization. How you integrate software together is mostly gut level arbitrary decisions and many times those decisions come out wrong and people make workarounds to fix things.
It all usually ends up working in the end. It may be ugly but it works and then everyone rewrites and the cycle begins anew.
Nobody in this area of software truly knows what they are doing. Hence why it's easy.
Let me be clear about what I mean by easy. Easy means anyone can do it. If a lot of hardwork and problem solving effort is involved... it doesn't matter and it's still easy because anyone can do it.
There is worthwhile software, and I have written some. But worth it is in the eye of the creator, and so I maybe I find worth where you don't.
What is the "easiest" discipline is a nonsensical question to me.
See this is a straight up insult. How do you know software isn't for me? You only say this to be manipulative and insulting. I love software, I'm just not delusional. Software is easy.
Let me tell you the extent in which I love software, I study haskell in my freetime. I study formal methods. I study graphics programming all of which are unrelated to anything practical to my current career trajectory.
>There is worthwhile software, and I have written some. But worth it is in the eye of the creator, and so I maybe I find worth where you don't.
I defined it in a way where it isn't defined by the eye of the beholder. What "worthwhile" software have you written that very few people in the industry can write? I bet you all the stuff you wrote, any mediocre software engineer can write. Which illustrates my point.
>What is the "easiest" discipline is a nonsensical question to me.
Of course it's nonsensical to you. How convenient. Because answering this question would defeat your argument or display how much knowledge you lack for other forms of engineering. The answer is: "software engineering"
It's like refusing to answer the question which is harder: Calculus or algebra? Well they are two different subjects and I am a logical automaton I can't determine which is harder so I am labeling the question as nonsensical even though the entire face of the earth OBVIOUSLY knows calculus is harder.
Well guess what you're not a robot. Don't hide behind that as an excuse. Calculus is harder than algebra just like how software engineering is the easiest engineering discipline out there.
Even "worthwhile" software that you write is easy.
Although, to be fair, some worthwhile software is easy to write, it's just figuring out what to write is really hard ... but that's one of the reasons why the discipline is hard!
lol. You're a genius. I've stated this multiple times. Software engineering is EASIER than other forms of engineering. This is a bit different than just being "easy" and while I've used the word "easy" you know my intent.
I am also absolutely positive all the worthwhile software you have or yet to have written, any mediocre software engineer can do. Just name all the stuff you done. Anyone can do it.
Let's look at your stuff: https://github.com/gilbitron This is you right?
Well when I think of impressive "worthwhile" software I think in terms of kernels, 3D rendering engines, a compiler that kind of thing. Those are things I would argue that actually promote your argument as less software engineers know how to program this stuff.
But looking at that site looks like you mostly do typical generic webdev stuff. Web dev is one of the easiest areas of software engineering. Also you're a vue guy and php. Vuejs is the typical choice for old school web dev guys who do php. I assure you all the stuff you built, anyone can do it. Doesn't even come close to "worthwhile."
Because anyone can do it, that is why it's easy. You can call it hard. But that's fine it just becomes a word game. Let me put it this way, ALL the software you have done may be "hard" but it's easy enough that any mediocre software engineer out of bootcamp can implement everything you wrote from scratch.
>Calculus and algebra were easy.
Nowhere near as easy as programming. The math involved with engineering goes much deeper than highschool algebra and calculus. I know you haven't done anything worthwhile in engineering besides webdev because you called it easy.
> That's why it's easy.
> Software engineering is a shot in the dark and therefore easy.
> Software engineering as it stands is easy.
> Nobody in this area of software truly knows what they are doing. Hence why it's easy.
> Let me be clear about what I mean by easy. Easy means anyone can do it. If a lot of hardwork and problem solving effort is involved... it doesn't matter and it's still easy because anyone can do it.
Seems like you think it is easy.
And no, that's not me that you linked. Although I have done webdev work in my career, and only easy webdev work is easy. There is plenty that is difficult in webdev.
Also I've created a 3D renderer from scratch (a complete 3D engine, in fact, including networking), a flight simulator, an ISAR simulator, software for force feedback, and a genetic samples assembler - and that's just the stuff from before stack overflow existed.
Let me repeat it a bunch of times so you get it: Software Engineering is Easier than other forms of engineering Software Engineering is Easier than other forms of engineering Software Engineering is Easier than other forms of engineering Software Engineering is Easier than other forms of engineering Software Engineering is Easier than other forms of engineering Software Engineering is Easier than other forms of engineering
Look you can either understand my point or play stupid games.
>Also I've created a 3D renderer from scratch (a complete 3D engine, in fact, including networking), a flight simulator, an ISAR simulator, software for force feedback, and a genetic samples assembler - and that's just the stuff from before stack overflow existed.
LOL, A 3D engine from scratch with networking impressive but arguably is doable by anyone. It also depends on whether when you created and what version API you used to interface with the graphics card. Prestack overflow likely means the engine was quite trivial.
But your other stuff only proves my point. Most of your projects are impressive ONLY because they combine other aspects of engineering together. Your stuff intersects with kinematics, aeronautics, biology, embedded hardware sensors, electromagnetic theory. This stuff is hard, the software by itself is easier.
>Although I have done webdev work in my career, and only easy webdev work is easy. There is plenty that is difficult in webdev.
I've been a webdev for a good chunk of my career. I've also done work similar to what you've done in your examples. You skim over general truths shooting for only the technicalities at your convenience.
Webdev work is generally the easiest form of software development and one major reason for it is due to lack of intersection with other aspects of engineering. WebDev also currently happens to be the sector of software with the most jobs and it contributes to the fact that software engineering is one of the easiest disciplines out there.
Obviously, some would consider it a waste of time. 90% of their colleagues would say, "I don't get paid to know unnecessary stuff about the bolts. I get paid to screw this to that according to this diagram." Which is what commercial software work is. Different thing from being a hobbyist.
The point is that the plumber himself wouldn't call himself a craftsman. He doesn't label himself as some sort of artist and prance around like an arrogant prick thinking he's better than those janitorial engineers who are complete hacks.
>Different thing from being a hobbyist.
Yeha nobody does plumbing as a hobby. I'll give you that. I think you're more referring to "Computer science" here which is a bit different.
Traditional engineers are generally doing the same-ish thing over and over, and the number of possible things they can do is severely limited in comparison to software. Safety is also not as big of a deal as cost. Any idiot engineer can create something with an insane factor of safety, it takes a good one to design something that is safe and cheap.
If you want to compare very complex/rigorous engineering projects like airplanes you should compare them to things like Google. Software and traditional engineering are both rigorous at the highest levels, though not in the same way since software is so much more flexible and has a larger problem space.
>I have family and friends who work as engineers, and from what they have told me software has a far larger problem space and the software engineering process is far more rigorous.
Software engineering is and everyone agrees with me, 100 times less rigorous. Only software has this culture of releasing something than issuing patches later.
As for "problem space" this is more defined by a product. The product is the problem space and programming is one solution to solve a problem. Granted programming is more versatile than other forms of engineering in terms of solving certain problems but this only lends to the fact about how much easier software is hence the desire to convert analog stuff to digital.
Flexibility is an indicator of easiness.
>Traditional engineers are generally doing the same-ish thing over and over, and the number of possible things they can do is severely limited in comparison to software. Safety is also not as big of a deal as cost. Any idiot engineer can create something with an insane factor of safety, it takes a good one to design something that is safe and cheap.
>If you want to compare very complex/rigorous engineering projects like airplanes you should compare them to things like Google.
>Traditional engineers are generally doing the same-ish thing over and over, and the number of possible things they can do is severely limited in comparison to software. Safety is also not as big of a deal as cost. Any idiot engineer can create something with an insane factor of safety, it takes a good one to design something that is safe and cheap.
I mean sure, this doesn't change the fact that software is the easiest of all engineering disciplines.
>If you want to compare very complex/rigorous engineering projects like airplanes you should compare them to things like Google. Software and traditional engineering are both rigorous at the highest levels, though not in the same way since software is so much more flexible and has a larger problem space.
Fine let's compare the rocket industry and automobile industry with software. Are either of these industries over loaded with a barrage of random ass startups or is software the only industry with this stuff?
> Only software has this culture of releasing something than issuing patches later
This has nothing to do with the rigour of software engineering. The process for releasing the initial software can be very rigorous, with a conscious decision to follow up with a patch or second release.
The nature of software allows this behaviour, whereas traditional engineering doesn't. The fact you can't release a day 1 patch for a building doesn't mean that the process for designing and creating a building is more rigorous.
> Flexibility is an indicator of easiness
How so? Flexibility means more ways to shoot yourself in the foot. It means you can easily implement something that works for now, and fucks you over later on. It's harder to do that with a physical construction because there are a lot of constraints. Physical construction has physics as guardrails, whereas software has unbounded complexity.
> Are either of these industries over loaded with a barrage of random ass startups or is software the only industry with this stuff?
How is this indicative of rigour? Yes, software has a lower barrier to entry. That doesn't mean that software engineering in general has less rigour.
A lot of software is written haphazardly without process, but I wouldn't classify that as software engineering because there is no engineering process there.
>How so? Flexibility means more ways to shoot yourself in the foot
True but people do so anyway. People in software repeatedly shoot themselves in the foot all the time than shrug it off. Oh it's just a bug. Hence the easiness.
>How is this indicative of rigour? Yes, software has a lower barrier to entry.
Rigour is another argument, though software definitely has less rigour. But my point is software engineering is easier. Doesn't low barrier to entry mean it's easier? It's like literally a synonym.
>A lot of software is written haphazardly without process, but I wouldn't classify that as software engineering because there is no engineering process there.
That's why it's easier. The "software process" is not really required. It's like an optional thing. Plenty of software shops prioritize speed over planning.
Most software shops aren't practising engineering, so to compare them to traditional engineering seems odd.
Let's dispense with the linguistic technicalities. Software, whether you want to attach the word engineering at the end of it or not is easier than other forms of engineering.
There is an enormous difference in the work between shops that hack code together and those that have well defined processes.
The former is nothing close to engineering whereas the latter is very much engineering.
Also on the title thing, I think they're basically meaningless everywhere. Engineering grads will also call themselves engineers regardless of the kind of work they do.
I'm saying these processes are pointless. They're are made up. An arbitrary set of methodologies or plans to execute certain things made up by mostly project managers.
It's like company bylaws or procedures for scheduling an event. Engineering processes are usually designed around some form of mathematical model or statistical phenomenon. This is not the case for software. Software processes aka Software engineering is just a made up set of arbitrary planning procedures.
Shit like kanban or poker planning comes to mind.
Software processes are designed with mathematical/statistical backing when needed. For example, A/B testing, anomaly detection and merge queues.
> arbitrary planning procedures
I don't think this is an accurate description. In traditional engineering the main focus is: does it work and is it cheap? In software, both of these are usually non-issues so things can vary a lot more.
For example, recently there was a blogpost by a company about not doing code reviews by default to allow them to move faster [0]. They are making a conscious effort to optimize their process for speed. Other companies (Or even teams within companies) will make different optimizations. A service that must be highly available may have 100% test coverage as a requirement, etc.
I suspect you will call this arbitrary, but I see these process decisions as conscious choices. The fact these aren't grounded in mathematics or statistics is not a big deal to me because the goals/focus are more complex than does it work and how much does it cost.
In software everything is a tradeoff rather than having an absolute answer.
[0] https://news.ycombinator.com/item?id=29792859
A/B testing is arguable a product based thing. It can be called "engineering" but it's not strictly a software thing. It's associated more with UI.
I've never seen anomaly detection used with software development. Looks more like a data ML thing.
Merge Queues are just a collaborative tool. I mean you can use this on any document outside of software engineering. Say, for example, CAD drawings where a bunch of people work collaboratively.
I don't think your examples are focused enough to be strictly things that are part of "Software Engineering" in the same way agile isn't strictly "Software Engineering."
>Software processes are designed with mathematical/statistical backing when needed.
This is rarely done. Very little statistical methods make it into the dev process or are even influenced by the dev process. When it does make it in there's no common methodology either as it's usually just some data driven behavioral changes based off of some analytics. The reasoning behind why it's like this is clear. At it's core software is deterministic. Code is simply a series axioms and theorems that can be logically proven correct. Statistics is for unknown processes and is usually employed at the intersection of software and real world stuff like the failure rate of ssd drives.
A passing unit test does give more confidence that a program is correct. This is a statistical phenomenon, but hardly anyone tries to actualize it from a statistical quantitative standpoint.
>does it work and is it cheap? In software, both of these are usually non-issues so things can vary a lot more.
I disagree. These are issues and we do use methods to mitigate these things. We want our software to work and we want to build it at a certain cost. Agile and measuring velocity is a way to monitor costs and working software is verified through mostly testing.
But most of this stuff isn't engineering. It's done out of necessity. There's no mathematical modelling going on as it's hard to even quantify the costs of software or even correctness. Hence why it's all arbitrary processes made up by managers.
>I suspect you will call this arbitrary, but I see these process decisions as conscious choices. The fact these aren't grounded in mathematics or statistics is not a big deal to me because the goals/focus are more complex than does it work and how much does it cost.
All decisions made in any field even say plumbing is a conscious choice. The difference is in engineering we use science and mathematics as much as possible to optimize these choices. We don't in software. Mainly because it's hard to model it.
>In software everything is a tradeoff rather than having an absolute answer.
Everything in life is a tradeoff. It's like this in fields OUTSIDE of engineering as well. The thing with engineering is you try to optimize your choice using math and science as much as possible. In software no such optimization procedure exists.
> The thing with engineering is you try to optimize your choice using math and science as much as possible. In software no such optimization procedure exists.
It's comparatively easy to optimize something with an absolute answer. Ex: will this building fall down with x design?
It's practically impossible to optimize something like: will our software development process allow us to deliver new functionality faster and win market share?
There is far more ambiguity in software development than in other fields.
https://en.wikipedia.org/wiki/Software_engineering#Definitio...
https://en.wikipedia.org/wiki/Software_engineering#Criticism
I meant exactly what you're referring to. Source code isn't the only thing that can go under source control. As long as the file isn't fully binary and is in a somewhat readable human format it can be subject to version control and therefore a Merge Queue.
>It's practically impossible to optimize something like: will our software development process allow us to deliver new functionality faster and win market share?
This is my point. It's impossible in the same way optimizing a painting of still life is impossible. Therefore it's not really engineering.
>There is far more ambiguity in software development than in other fields.
Edsger Dijkstra, had it right.
Nobody except you cares about your craft though.
They care if you can accomplish the things they need accomplished.
If your craft is 'building quality decks' - and they want a 'quality deck' - then great.
But if your craft is 'building byzantine window structures with 4 plane glass imported from Italy', well then, it's going to be hard to work on a house if that's all you care about.
Software Development is a skilled trade, it's more like Carpentry than it is academic, it just has some elements that can be very academic.
But it's an extremely narrow slice of this "craft". Right?
I've been delivering commercial products (that's the goal, no?) for over twenty years, regularly get high praise and top ranks in reviews, get promoted often including to "distinguished" and "chief" levels (always as a technical IC, not in management).
Yet.. no way I'd ever pass any of these leetcode style memorization interviews. I guess companies think that proves I can't develop? Funny. But sad. Our industry should not be like this.
Personally I feel lucky that this leetcode interview disease started after I was fairly senior already, so I'm getting hired based on track record and connections who love to hire me to deliver products. Hopefully, fingers crossed, that'll carry me to retirement.
But if I was in my 20s or early 30s, I'd be looking to leave tech entirely and go into something else where experience is actually appreciated and valued. None of my high school friends who went into medicine, law, finance, etc have this type of problem in their industries.
No.
Once a company grows to a sufficient size the goal stops being delivering products and starts being not ^&*£ing up the product that generates a lot of money. The aim is to hire people who won't get things wrong, either by making errors or by introducing new unproven ideas.
Sometimes the best answer is the one that maintains an API that was introduced in a beta that one customer is using. Sometimes the best answer involves breaking a 15 year old API that the entire country's electrical grid requires. But in both cases we're always looking for a single answer, a One Ring to Rule them All. The end-point or approach-point trade off considerations are IMHO, the real issue.
As LC itself demonstrates, there typically are multiple ways to solve a problem. Most engineers will do the brute force approach and stop there because it does in fact solve the problem. And for most companies that will be enough.
The issue here is those types of solutions can be catastrophic for these larger tech companies… some algo that’s part of a tiny feature cab cause a massive performance regression.
When it comes to these algos, computer science dictates there is an optimal time and space complexity solution. There are also more clear and more obtuse ways to achieve what is technically an optimal solution from a performance perspective… often these can be found and discussed in the LC discussion sections. The more obtuse… ie trying to get to a minimal LOC, might be fun from a competitive programming perspective, but terrible for production code that needs to be maintained by coworkers.
So there is a craftsmanship aspect to it that goes above and beyond these algos, but ultimately there are optimal time and space complexity approaches that need to be adhered to.
Now no one is perfect. You’re not always going to come to an optimally performing solution. But if you’re good enough at this stuff, and your coworkers are good enough, it’s going to be rare that a PR enters the system that causes some notable bottleneck. And when it does, you should have the mental toolkit to quickly determine what happened.
Making a call to arms avoid this stuff as it stifles creativity is sorta like the folks who say learning music theory can harm someone’s ability to compose music. If you’re a pop songwriter, perhaps. But what if you need to compose a symphony? You’re just not going to luck into it with a basic understanding of music theory and advanced composition.
It’s just one kind of mental toolkit, and somewhat orthogonal to knowing the apis and design patterns of some framework you’re using to build a thins, the idioms of a language, etc.
Then the software industry isn't for you.
I'm definitely not saying it doesn't require dedication and brainpower and (in the right places) formal methods. But the overall creative process, and most especially the end product (and the aesthetics) of what we produce are about as far from a musical symphony ... as anything you could think of.
There's a good Steve Jobs quote about this, which I couldn't easily find, but which completely nails this distinction. Something along the lines of: "No - we're not here to build something that that people will look at in a museum hundreds of years for now. Very little of what we do will last for more than 10 years or so. It's about meeting people's needs in the here and now."
(Or to that that effect; I am horribly mangling the original).
It's a very different thing to bust out a bunch of features for a consumer product w/ relatively minor concerns relating to load/perf and something that operates at bleeding edge scale and complexity.
This is a funny take on it as pop music is 99.9% just some basic music theory put in the shaker and than pressing the random shuffle button. The rest is mostly just dull and boring work.
That's the reason why after people once figured out how to actually do it are able to produce constantly hits for decades thereafter.
No it's not. No more than writing a successful novel is a matter pressing the random shuffle button on all the distribution of plotlines and clichés you've seen before.
When I was young I also was pretty good at these interviews and loved doing coding contests and such for fun. However when I joined a big company I learned what really is hard about software "engineering".
It's dealing with legacy code, finding and fixing bugs in highly distributed systems, understanding tickets from customers, managing integration of different components, balancing tests to be enough but not to be too much.
In general the hard tasks are very rarely one specific well determined problem such as finding a node in a tree in the most performant way.
Right, if you can't do any of those and can only do leetcode you will get hired as a junior. Do you think that juniors need those things? No, of course not, they need to learn that on the job. So juniors gets leetcode. Now, since all juniors can do leetcode, why shouldn't we require seniors to also know it? Otherwise we would hire seniors who are worse than the seniors we grow ourselves. You can say that seems like an arbitrary requirement, but it makes sense, and there is no lack of senior engineers wanting to get hired at FAANG. And getting X years of experience isn't an accomplishment, even the dumbest software engineer will get there after X years.
Of course you will gain experience anyways over time. But all your leetcode skills will fade into meaningless very fast when you see what the actual problems are.
I have been meaning to go back and grind some of those problems out again. Just to refresh my memory on them. But notice I have to 'refresh my memory'? These problems usually do not come up. You are usually clicking some if conditions together and a few for loops. Nothing fancy. The interesting bits are figuring out someone elses framework using docs written in an afterthought and what 3 other methods do I need to call to fill out param 4 of this method just so I can get this thing to do what I want.
Imagine a math professor would be required to be as fast in answering questions regarding times tables as a child in third class. I bet you wouldn't be able to hire almost any math professors any more because almost all of them would lack this skill!
Nobody would be of course so stupid to judge a math professor by asking them questions about the times table.
Well, but one, and only one, industry is bonkers enough to do exactly this.
Oh look...a googler ;)
And thereby distract us from the very central fact you have articulated.
The problem is that this almost inevitably leads to a decline of the company.
I'd say it's more like a "Yes and no." But it's definitely not a binary. Your "No" characterization is partially valid. But only partially.
And what's a great what to introduce mistakes and fuck up an existing product or team? By being overly confident about one's binary "No" answers.
So… the industry is apparently working fine for you, right?
> But if I was in my 20s or early 30s, I'd be looking to leave tech entirely and go into something else where experience is actually appreciated and valued.
Yeah, sure. Not for everyone. It’s unfortunate.
I'm in my 20s and think about this a lot although I already moved to management (with a lot of software development, still) as well.
There's a great article [1] analyzing this problem (quotes from the article: "Professionals with higher cognitive ability drop out of STEM careers earlier and faster", "High-ability workers are faster learners, in all jobs. However, the relative return to ability is higher in careers that change less, because learning gains accumulate").
Knowledge depreciates a lot faster in software development than many other fields. That's why I really think about going into finance or sales (still fast-paced), but attending expensive top business schools and starting as an analyst with a low salary again is pretty rough after already building my current skillset. Currently feel a bit stuck with my career options right now. Money's still good and the work is fun, but working in a field that is set up to be a grinding mill as an IC is not an entertaining thought. High-tech projects will still be fun, I guess, but still definitely something to consider. Specializing early on may mitigate this.
[1]: https://whoisnnamdi.com/never-enough-developers/
For finance: Managing finance and deals is one of the most important aspects in any business. You can make the same money compared to tech without a ceiling and I’m personally interested in economics and financial topics.
Both have a quantifiable aspect (deal/fund size, new revenue/customers) that makes it easier to measure your impact on the business. This means that it’s easier to get a fair compensation - although bad performance will get noticed easily, too. And the knowledge in these areas compound, especially in sales.
On a personal note, I’m interested in psychology and economics and can build connections with others quickly, so these two fit quite well and I'm convinced that sales and finance are important ingredients for any type of work (philanthropic included).
Best of all worlds would be to build a MVP using software development skills until product-market fit is reached, then being able to grow customers using sales skills and then supporting further growth with external capital and managing an exit using finance skills. - In reality, these are all separate roles, but I'd like to be able to work in these other two areas, too.
Remember those "thinking outside the box" skills we're supposed to have?
This is what we need to start using them on.
Don't forget that software engineering is often up to 100 people team sport. If every repo and every algorithm has a special snowflake unique flair put upon it, then you have to relearn everything each time you open someone else's repo... also you cannot directly hire for the work, instead you have to hire smart people who start nearly at zero to rapidly learn the nuance of each repo they work on. This is a young man's[2] game (before intelligence crystalizes and energy levels wane)
If there is a good amount of run of the mill computerscience/eng then you can hire people who can start fast(er) and they can build off assumption rather than on having a bunch of special code precariously "cached" in their working memory.
[1]: I'm speaking in generalities, yes some young people are tired/fixed mindset, yes some older people are energetic/flexible -- but afaik the psychology/science bears this difference out
a formal 400-level course in algorithms will go a long way, preferably at a good university with a good professor, but if you can't get that right now: https://ocw.mit.edu/courses/electrical-engineering-and-compu...
computer science is a discipline where people seem to think the education doesn't matter that much, but the truth is once you start to get even a little mathy it matters big time
I think when people say that education doesn't matter that much in our field; they are talking about formal education as offered in academia.
This is not to say that university education isn't valuable. But SE is unique among engineering disciplines because a) it is possible to learn everything relevant in self study and b) a lot of formal education in the area still teaches CS, when most people who attend the courses want to be engineers, not scientists.
It's a bubble of a specific type of engineer. Have you tried your hand at project Euler or Advent of code? I feel like those problems are like leet code( or hacker rank) problems but with a different bent, one thats more enjoyable and allows for greater level of creativity when solving for them.
I also want to affirm that yes, part of the reason for these tests is definitely to check that you are able and willing to jump through the hoops that a large organization sets up as it scales; it's no fun at all.
As someone who's done the grind myself, I would push back slightly and say that the skills I use to solve leetcode problems are ones I've used at my BigTech job, and that that can be fun and useful. Gaining that type of insight though, generally doesn't come from just grinding leetcodes over and over again, but also returning to study algorithms textbooks like CLRS. The insights you gain from understanding these techniques deeply can lead to some truly interesting solutions to real problems.
Best of luck.
Sorry you’re going though that.
On the bright side, sounds like you’ve recognized the pattern to be successful at leet code. Add it to your tool belt and move on to things you find fulfilling.
There is a lot of power that comes from creatively applying those algs skills.
1 - just try to think of a solution. Sometimes you'll just see it. 2 - what if you sort something? Sort the data and see if it helps to see a solution 3 - what if you stick all the data into a dictionary? Does that help? 4 - what if you stick all the data into a tree? Does that help?
Etc etc. You can make a nice long list of things to try. For 90% of the problems, doing one of the things on your list will lead you to a solution.
You are not an 3l337 h4x0r who p0wns puzzles for a living. You're a professional software developer who builds useful systems for people and organizations.
It sounds like you know the kind of culture you've enjoyed, and you know what the red flags are. Which makes sense. I think everyone gets pickier as they gain experience.
A classic.
Even if you don't do well at the single LC style question in our interview loop, you can still pass and be hired, there are other things we ask that are specifically NOT LC type questions.
Find a startup to interview at, skip the 4 LeetCode questions in 4 hours interview.
Same as for other professions, you would suffer in law for the first 5 years doing proof-reading (the grass is always greener).
But if you want creativity - why not just build your own stuff? You have a super power that majority of the planet does not have. Alternatively changing jobs to a different kind of company that structures this position differently?
It isn't. There is a bubble where it is prevalent, and there are lots of companies where people actually talk with candidates, eg. about software they have written, why and what they were excited about it, discuss the company product and what they are looking for in terms of contribution, etc.
leetcode is hands on demo of what you can do and how you think.
since big tech pays big $$ they can afford to set the bar higher than just talking
if mediocre companies cannot hire top engineers, they will not develop software in-house and instead will buy the SaaS software from those big tech companies that pay top dollar for leetcoders. Software scales up easily
No, it's not.
Most of my non-SWE friends are from liberal arts circles. Interview process for their jobs had no "LeetCodes", no take-home assignments. Just a few steps of 1-on-1 conversations. The companies are also heavily relying on the trial period to accept/reject fresh hires.
Naturally, it's just my anecdata.
You should check out https://github.com/poteto/hiring-without-whiteboards, which is a list of companies that don’t use LeetCode in their interview process.
An issue I often ran into when using the repo myself was I’d find a company that sounded awesome, and then find that they didn’t have any open positions. I created nowhiteboard.org to act as a way to pull all the jobs from the companies listed on that repo (and other companies that I’ve manually found that don’t use LeetCode).
I think there’s a matter of education and shining a light on the companies that don’t use LeetCode as I feel that the prevailing notion in online communities is that companies only use LeetCode to interview. I’m obviously biased since I’m obsessively researching this, but I’ve read a good few comments online of engineers who’ve stated that they haven’t had to use LeetCode for any of their interviews over their career, and that all of those companies aren’t listed on the repo above.
If companies had a good way to source candidates that are hesitant to jump jobs specifically because of LeetCode, I could see our industry starting to make some semblance of progress towards making LeetCode less prevalent in interviews.
Anyways, rant over, hope your job searching goes well!
Any mention of these gets a hard NO early on during the interview process.
I think if I had the power, I would allow candidates to have multiple ways to interview at a company. Some companies do this already where the tech assessment portion can be administered as a take-home, LeetCode challenge, or re-factoring some sort of code.
There are downsides to LeetCode, and there are downsides to take-home projects. My intention with the website is to offer extra choices to developers when choosing to interview at companies.
And I think as a candidate (and companies as well,) LeetCode is the more scalable of the interviews since there’s defined criteria to study and to test on, so I do see the merits of your POV!
I’m not necessarily about this full-on hatred for LeetCode, BUT I also did buy fuckLeetCode.com just in case
It's really insulting to put so much effort into something and then get treated this way.
Recently: * burned 2 days PTO putting together a comprehensive solution I was proud of. Feedback was they wanted me more proficient in their specific tech stack. I'd already said I was looking to learn their preferred language on the job and would do the test in a language I was more comfortable with, and they had been happy with that line of discussion.
* was given an open ended dataset and told to spend 2 hours on it. Did all the initial analysis I do on any new dataset in my regular day to day job, spending a little more than the allotted time, and found some interesting things. Feedback was that I should have gone deeper in my analysis.
Ugh, gross. You dodged a bullet. Pathetic.
I really despise it when compulsively agreeable people agree to something without actually meaning it, just because they're uncomfortable with saying no, and then backtrack later.
If any of you out there do this, please stop now. It's a huge waste of time for the people who interact with you, and it's hurting your reputation.
> was given an open ended dataset and told to spend 2 hours on it. Did all the initial analysis I do on any new dataset in my regular day to day job, spending a little more than the allotted time, and found some interesting things. Feedback was that I should have gone deeper in my analysis.
Yeah, it's obvious that this "don't spend more than X hours" is just HR babble to make the process look fair. They want you to spend a week and pretend it took 2 hours.
Trust me that I know it feels horrible when you're bad at them. It does not mean you're a bad engineer by any means. It just means you're bad at Leetcode problems! Clearly, you still have strengths that have allowed you to accomplish what you have in your career. Those are strengths that should not be discounted by potential employers and certainly not by you.
But that doesn't discount the value of those problems either. You're right that you have to memorize the basic data structures and there is a certain pattern to these problems once you're good at them. But if there wasn't any art to these problems, then after 400+ problems wouldn't you have figured out the robotic algorithm to solve them? I argue that there is more to those problems than bullshit.
People who are good at these problems exist. I would not dismiss the strengths of these engineers either. These engineers may not even possess the same strengths you do! But just like you, there is a certain skill or talent that allows them to solve those problems. Those skills are valued by companies who want to run smart engineering teams.
It is not the only skill out there, it's just the easiest skill to empirically measure. You cannot run a large organization without a data-driven method. If you trust the human intuition of your hiring team, you will have a lot (more) variance in your hiring quality. Not to mention that your hiring will be biased against women and anyone of a different race than of your hiring team. This is true even if everybody is aware of their own internal biases. This is why large orgs give these problems.
Even if you do not share those skills, you might still be valuable as a good engineer. You just have to look for teams that are looking for asymmetric advantages: that is, those who can't afford to compete directly against the richer teams.
https://www.youtube.com/watch?v=FHwnrYm0mNc
Copilot cannot "solve" these problems, it just knows the answer.
And for that exact reason, using LC as a hiring tool runs into the same problem as using standardized tests in colleges: Once people figure out that the tested metric isn't actually "understanding of the subject matter" but "test knowledge", and learning for the test is easier than understanding the subject, people start learning for the test.
> This is also what Software Engineering has become: you memorize, regurgitate and participate in agile the masquerade. Creativity is shunned. Tried architectures/patterns are what is expected.
No, not really. Maybe some jobs are like that. Many are not. But even the jobs that are not like that will generally be gated by interviews that include Leetcode-style questions.
This happened in the software industry because credentials and experience often mean nothing, resume fraud is rampant, and the cost of hiring a bad engineer is very high.
How about a take-home assignment? Suggest that and many will respond, "I don't work for free" or "I don't have time to work after work, I have a family to take care of." How about just looking at prior experience, or credentials? Resume fraud prevents that, and a lot of companies prefer to hire generalists and find a team for them to work in, rather than hire specialists for a particular team. Outside of research-heavy fields like AI/ML, a university degree is no predictor of success.
So, we need to find a way to evaluate a candidate, in a short period of time, that gives a reasonable estimation of how they will do in the job. If there was a better way, and it was proved to be better, the industry would adopt it very quickly, and it would be a competitive advantage for the companies that realized it first. But that has not happened.
If you put aside the cheap cynicism that permeates threads about programming interviews, you'll realize it hasn't happened because none of the people who are hiring have figured out a more reliable way to hire, even though there are very smart people doing it and they have an enormous financial incentive to figure out how to do it better. A company that could find all the good programmers who can't Leetcode, and weed out the bad programmers who can't Leetcode, would get an enormous amount of talent that others overlooked.
This is just a hoop to jump through, and it's not nearly as difficult as getting a college degree or learning how to code in the first place. I'm not saying it's easy, I'm saying it's doable with time and practice. Most of your colleagues have done it at your current job and also at your future job. I can't do it at the drop of a hat either; I would need to practice like almost everyone else. You can do it too, if you approach it with the right mindset: you aren't supposed to enjoy it or find it intellectually interesting; it's just an obstacle to overcome and it's smaller than many other obstacles you've dealt with before.
There are many reasons why this could be the case, and it being the current best alternative is only one of them. Another that immediately comes to mind is survivorship bias.
If there was a better way to do this at the scale of the software industry, the incredible incentives to find out how to do it better would have resulted in something by now.
or better yet open your own high growth IT startup, raise few mills from VC and start hiring and see if you like leetcode interview or not.
Problem is, it's even easier to game the system by just memorizing LC questions. A metric that is known to be relevant beforehand and can be tackled by "learning for the test" is an almost surefire way of ensuring that a lot of people will do exactly that. There is an entire industry to prepare people for these tests, same as there is for standardized MC tests in eductional systems that rely on them.
It's not easy to detect resume fraud. But it's even harder to determine whether someone actually knows his stuff, or just spend time (and sometimes money) on just memorizing a lot of questions.
> If there was a better way
There is: Talking to people. Actually doing interviews.
https://www.linkedin.com/pulse/why-interview-coding-tests-mo...
However, to get to that point you need to get past the phone screen and that's usually a coding exercise. I'm not mad about that because I have seen firsthand that companies need to filter out all the ridiculously unqualified people who come their way, to ensure that time spent on interviewing (including conversation) is not wasted.
If you list a decent software job right now you will get hundreds, maybe even thousands, of applicants. Many will be outright liars, many will be junior people pretending to be senior, and many will be very good. You can't spend time on all of them. You need to have a way to decide who is worth your time, or you'll never have time to do anything else.
The "first filter" is what we have HR departments for. As you say, decent jobs get thousands of applicants. Whos going to do the phone interview on a thousand people?
The first filter is skimming the applications and checking basic credentials. Filter out resumes that don't check out, and looking for red flags. This already brings down the candidate pool to a manageable size.
I used "credentials" in the above post in a very broad sense of the word, because "something that shows on paper that you know how to program" is a bit of a handful to type.
Work Experience, Involvement in projects, a degree, a github link, code-camp certificate, reference to prior training, all of these can be credentials. The better the position, the better whatever someone puts in needs to be in Order to consider the candidate. If it's a beginners position even a short paragraph about when, how and why someone started self-teaching would be acceptable, if I am looking for a senior database engineer I want to see more.
Writing something tangible in a resume about ones skills is a prerequisite. If a candidate doesn't do that, his application is eliminated before it even gets past the desk of the first HR person. This is not "credentialism", it's normal procedure for basically every single job-that-requires-some-form-of-expertise on the planet.
"credentialism" would be to only consider candidates with, say, a CS degree. That would be bad in our industry, for the exact reason you outlined.
In larger companies, and for well paid positions, where there can be hundreds of applicants for each job, that just isn't feasible, so HR has no choice but to apply some sort of filtering.
If you can implement one of the memorised solutions on the spot, with tweaks, then you're probably good.
If I memorized how certain classes of problems are solved, and can derive an implementation from that, then yes, I am probably a good coder. I am then also someone who used LC et al. to learn about data structures and algorithms, aka. what these puzzles were originally intended to help people with.
If I memorized the question and its solution however, without understanding why and how this solution works then I am merely good at memorizing text and replaying it. This doesn't demonstrate my ability to solve problems or to code.
It's the same with translating a concept into natural language. I have not memorized the word-by-word explanation of how the JW-Telescope deploys. I have an image of the process in my mind, so if someone wants an explanation, I translate that principle into english dynamically.
The criticisms you mention about take-home tests apply equally to practicing Leetcode-style questions. It will filter out a ton of people who don’t have time or aren’t willing to spend it. In that sense it’s not better (and it’s probably why I see a lot more take-home coding tests lately).
But really neither of these is ok. They’re both ageist and sexist and lots of other things (older people and women disproportionately carry the burden of caring for others and many won’t have the time or energy to prep for Leetcode problems). Even if I’m willing to jump through those hoops, I don’t want to work at a place with a strongly ageist and sexist filter.
Lots of other careers don’t ask people to prove their skills before they get hired. They accept that some resume fraud will happen and deal with it. Bad hires are really bad and destructive, it’s true. But let’s not adopt solutions that are worse than the problem. Discrimination is not an ok price to pay. I’ve been working in this industry for almost 25 years now, and we did ok before Leetcode-style interviews. We can do it again.
Many people would kill to have the opportunity to study for 100 hours in order to secure a 2-3x increase in pay. That is only 2 hours a week for a year. If a SWE is making $150k and they can spend 100 hours grinding LC to get a job which pays $400k they are going to make $250k extra in their first year of the new job or $2500/hour spent grinding LC. The present value of an extra $250k/year for the next 20 years of your career at 3% interest is roughly 3.7 million dollars. So over the period of a 20 year career you will net $37k/hour spent grinding LC.
The fact is that so many SWEs — as seen in this thread — outright refuse to grind LC to get into a FAANG which is why not everyone is making boat loads of money at a FAANG. The process to get there is well known but many are not willing to put in the work to get through the process.
I do believe that LC filters don’t reflect a SWEs ability to develop software, but it is a reflection of their commitment to do what it takes over long periods of time to complete an objective, regardless of whether or not that objective has merit.
The grass is always greener on the other side.
> This is also what Software Engineering has become: you memorize, regurgitate and participate in agile the masquerade. Creativity is shunned. Tried architectures/patterns are what is expected.
Compare https://sockpuppet.org/blog/2015/03/06/the-hiring-post/
See https://hn.algolia.com/?q=https%3A%2F%2Fsockpuppet.org%2Fblo...
And yes, LC problems do not deal with the day-to-day work of a software engineer. They are fun puzzles to do sometimes, if that's your thing. As a "hiring tool" I think they are abysmal. Fortunately, many companies don't use them. There is a bubble where it is prevalent, but again, people with experience can chose where they interview.
If you want Programming puzzles that are actually fun and correlate to problems an engineer actually encounters, I can strongly recommend https://www.codeabbey.com/
I interview pretty regularly, move jobs every couple months. Probably receive 2-3 offers a month without doing any leetcode.
I always wondering about doing the latter. I get bored very quickly, but don’t want to risk hopping full time roles too quickly.
I get bored quickly as well. One of main reasons I started working multiple jobs (the money is nice as well).
That is, if you want to be a part of such company.
Because, yes, compensation is awesome, and you get the shares and what not, but there is more to life than that.
Scratch the surface a bit deeper, there are many different companies out there with different core values that will attract totally different group of people - while having all of the benefits of a "well known company"