Think of it this way: application development, software engineering, and computer science (and data science and ... etc) sometimes use the same tools but are all different disciplines.
Universities traditionally focused on Computer Science and their graduates would often need a lot of grooming before they could really be independently and reliably productive in the commercial words of application development or software engineering. Importantly, it was less grooming than someone who studied something like English or Sociology or History, but it was still a different discipline than what the job market demanded.
You jumped into the job market directly. You learned to develop applications, research API's, study trends, and participate as a team member in development workflows under commercial pressure. You don't know how to compose and compare sort functions for abstract sets of N elements because you never needed to. You just use sort().
And that's okay! Inventing new algorithms with theoretical significance is not your job! You have other skills and they're of much more immediate value!
>And that's okay! Inventing new algorithms with theoretical significance is not your job! You have other skills and they're of much more immediate value!
Except when it comes to getting a job. Forget any of the rest of your skills, because we all know the only thing that matters when interviewing is an ability to recite CS algorithms out of memory and solve obtuse puzzles while pretending you've never seen them.
Except when it comes to getting a job. Forget any of the rest of your skills, because we all know the only thing that matters when interviewing is an ability to recite CS algorithms out of memory and solve obtuse puzzles while pretending you've never seen them.
I’ve been a professional developer for 20 years and have never had to recite CS algorithms or solve obtuse problems.
My last three jobs I had to whiteboard an architectural diagram of a system, come up with a 90 day plan to create a software development team (I didn’t know I was applying for a lead position), and describe how I would introduce Devops, redundancy, traceability, etc into a system
The closest I came to a CS style interview was my second job out of college when I had to explain high level different data structures. That was actually important since we were writing cross platform, C that had to be highly optimized.
I’ve gone on lots of interviews with only two rejections - the rest I took my name out of the running once I got the job.
I came up as a traditional computer geek - learned how to program in Basic and assembly on an Apple //e in middle school, fell in love with C, spent way too much time on comp.lang.* groups etc.
One of my best friends who I worked with across three jobs graduated from one of those infamous for profit schools, for years wouldn’t know an algorithm if it hit him in the face, but spent a lot of time on side projects, reading best practices from books, etc. and is one of the best architects I know.
Since we're sharing anecdata, I'm a professional developer and still use recursion, building/traversing various types of tree data structures, and a few other CS degree requirements.
That said, for algorithms (e.g. sorts, etc), understanding what the options are and trade-offs is certainly more useful than knowing how to implement them, since there's a good chance someone has implemented it already in your language of choice.
"Hard problems" are risky business ventures. In my career, we've done a couple of things that would be considered "hard", but in each case we've leaned heavily on papers published in academia. The best example might be when the team I was on did shape recognition from hand drawn shapes to shape objects in a drawing application. I've occasionally been asked to solve some hairy caching/concurrency problems, but again I've gone straight to the literature.
My brother worked in a company that was doing circuit board design (simulating crosstalk, etc). Their work was highly theoretical, but they had electrical engineers doing the research (and were actively collaborating with a university). His job was 99% implementing code.
I feel that programming is more about handling complexity than it is about solving other problems. You sometimes dip your toes into solving problems in other domains, but the biggest value you can give as a programmer is in creating a code base that is both simple and sustainable (and keeping it that way). This is the hardest problem I've ever worked on by far. It dwarfs any of the other problems I've tried to solve. I sometimes get a bit depressed that others don't consider it a "hard" (and therefore interesting) problem.
In my experience, less than 5% are actually writing algorithms and solving harder problems. I work at a consulting firm with 100 or so developers, and most seem to do "simple" stuff most of the time.
The most complex thing I have heard of is someone who wrote a kalman filter thing for some part of a nuclear reactor. To me it seemed hard since I don't understand the math, and apparently people around him was happy with his solution.
Also here in Sweden I don't think the CS algorithms are very important at all when getting a job. I have just not seen it that much, which is sane since nobody seems to really need it anyway...
And obviously the standard CS books tell you little about numerical and stability issues you get to solve to have an actually really working and accurate Kalman filters.
It might be touched upon in doctoral or post-doc courses...
Whereas electrical engineer gets drilled about noise, stability and uncertainty all the time. Rarely even about mathematical chaos and chaotic systems.
The big secret is that everything is a CRUD app. It doesn't mean that the C, R, or U steps can't involve hard problems.
I had to implement a quadtree from the ground up, because existing solutions didn't work, when working as an SAP consultant on some dashboarding tool (I also had to know what a quadtree was!)
I now work in a generic unsexy role doing release engineering. About half my job is generic software engineering, but the other half is comparatively academic. I was reading academic papers on Aho-Corasick derivatives last week and writing statistical tests in jupyter notebooks this week.
And my interview questions are generally inspired by problems I've had in my work, just normally somewhat simplified since the way I phrase them justifies the need for a specific class of solution much more clearly than whatever nonsense I encountered in the first place.
I would risk to say 95-5%
Mostly researchers are creating those solutions for hard problems, and, in the industry, only a few have to bash them. The rest of us are concerned with keeping APIs responsive and getting that damn button the correct shade of blue.
Sometimes boring CRUD apps turn into interesting CS problems due to the data model and ways that the customers expect to visualize the data, while keeping the application responsive.
No idea, but based on other comments here it seems that a significant number of HN users who commented here are in the CRUD apps and/or yet another SAAS app category.
Literally just pushed this up yesterday https://github.com/pmarreck/mega_xml This is the first time I've been able to convert one tree data structure encoded as a binary string into another form native to the language at hand, in a functional language. One of the hardest things I've ever done as a developer lately, having no CS degree (I did take some electives, though) and just learning-by-doing.
> I’ve been a professional developer for 20 years and have never had to recite CS algorithms or solve obtuse problems.
I'll see your twenty and raise to 38 on the same basis. In fact no one I know has ever had to solve the algorithm problems that seem so common now (in the US at least). The nearest I came to it was in a previous career as an electronics engineer where the interviewer gave me the circuit for a simple common emitter amplifier and asked me to describe it's characteristics. He was very apologetic afterwards and said that experience had taught him that recently qualified electronics graduates often had so little practical experience that he could not afford to employ them as it took them too long to get up to speed; so he used this simple test, and it was very simple, to sort out those who could be gently shown the door immediately to avoid wasting his and their time.
Wasn’t trying to imply that’s the case. I’d love to move out of the Bay Area, just to get away from the whole “leetcode or GTFO” interview style, but the fact that there are so many opportunities around here keeps me here for the moment. Well, that and I can actually make enough money to pay my student loans while living somewhat comfortably and saving a little money. If I knew anyplace that had decent weather where I could do those things, I’d be looking at the next flight out.
That is just Plano. There are arguably more opportunities around each of North Dallas and Addison. The cost of living here is a third of the bay area and that isn't including the size of house. This is why California is bleeding 60k people a year to north Texas.
Yep, quite the burgeoning tech scene in Phoenix as well. Compared to California it's quite affordable if one can put up with four months of pretty extreme heat per year.
This is something I'm struggling with right now. It seems like there are endless opportunities but are they really opportunities if you can't get past the "leetcode or GTFO" barrier? And even if you do get past it that only gets you in for a full day of being grilled on other arbitrary measures with zero feedback as to why you didn't get the offer. I feel like spending time trying to be able to solve these coding "challenges" only detracts from time I could be spending learning more useful ways to code or actually, you know, building applications.
I've had two successful exits since the early 2000's, most recently one that of a company that I built, wrote the product for and sold to a company in 2014 (all modern web based stacks, technologies etc). The last one, I ran engineering which had 25 developers and we shipped a brand new product to market and I helped sell that company (the company that bought me out) to a larger company. All the while, still writing code, building product, etc.
I had a three year earn out, finished that and decided to get back into the workforce and get a job at a senior or above level (thinking Director, Manager, etc). Guess what, not only did my age hinder me (I'm 53), but my lack of CS math background seemed too in an interview process. Various interviews had me solving what I consider not only impractical, but almost silly puzzles / math problems that not only didn't apply to the company I was interviewing with, but didn't apply to anything real-world -- it felt like it was a way to:
- Weed me out because of my age
- Make the company seem like their vetting process was "Google like" and "trendy"
- Make the interviewer feel entitled or the company be "elite" in their process
Part of me realizes that some of this is to see how well someone problem solves. I get that.
However, I had one interviewee actually bungle up the questions, in fact, I had to point out at one point that it appeared that they described the problem wrong. When I got my answer wrong, and then asked for the answer, the interviewee clearly realized he setup the whole problem incorrectly.
Oddly enough, this is the part that bothers me the most. I've been asked many times for my GitHub. I have lots of solid examples to see my work. I've also been asked to do a programming challenge, which almost always I nail 100%. But it's always these "trap" CS challenges that I feel are used to eliminate someone based on either HOW they solve it or a way to justify them out and not hire them based on other factors (age, fit, etc.)
I actually had one that was a whiteboard session where the CTO asked me to solve the problem on the board "using code of your choice", so I stated, "Look, since I know multiple languages, I'll use pseudo code to walk through the problem and explain the answer"
When he described what he wanted me to solve (badly I might add), I wrote the pseudo-code on the board and described the problem as being solved by using regression. Which was 100% the right answer but because I chose to use pseudo-code not say, Python or JavaScript -- he told the recruiter, "he couldn't solve the problem I was looking for him to solve." When pressed by the recruiter about the solution, he gave a link to the problem in his Github, which of course was verbatim of what I described but in Python -- using regression.
What I've learned from this is that I should contract and consult. Most of these smaller companies want what they want in the way of an employee and are seeking the 10X developer, culture fit and someone in their own age group...
As has been said here many times, these puzzles test for corporate compliance, not for problem-solving ability. You're being assessed on your willingness to spend x months studying to a certain industry-wide norm, and to then pliantly follow interview instructions to reproduce one of the stock answers on demand in the format requested.
If you deviate from the rather arbitrary requirements you will be considered a no-hire.
Other industries have a formal study, exam, and professional certification process. Developers don't. [1]
In the absence of that, these interview play-throughs are treated as an ad hoc substitute. They're a passable fit for generic ass-in-chair juniors, but a very poor fit for anyone looking for good seniors or a CTO.
[1] In the UK you can become a Chartered Engineer via the British Computer Society. I don't think there's anything equivalent in the US, and I'm not sure how many shops in SV even recognise Chartered Engineer as a professional qualification.
Brilliant comment. Shouldn’t you be building startups yourself instead of trying to fit into these teams? I think your skill set speaks for itself.
Recently I joked with the interviewers over Skype screen sharing that I probably wouldn’t be fast enough to get a pair programming exercise done with 3 of them watching me. And that often these things you either see right away or struggle with. They all laughed and agreed.
I wanted to test a particular function after setting everything up, installing jest etc. But was told not to because deconstructing xpath was an implementation detail. No one could see what was wrong with my working and all three of them said it’s the way of working and not if you happen to get the answer on the day.
Of course they failed me saying I was too weak at programming. I won’t be doing coding over Skype screen sharing again and with more than one person in the room, it’s just too stressful and random.
I've done many startups and I have to say I love it, but the struggle to fund it properly (to it right) is what turns me off. I'd rather bootstrap myself (these days) and go the "indie hacker" route and not have to deal with fundraising -- build a product myself, sell it and roll it all on my own. That wasn't possible 20 years ago, it is now.
So yeah, I've focused on the executive level, CTO, VP, etc, But with that, you have to either give up coding and just manage or go to a tiny company to be the "key player", but then you're typically at a smallish company with little to no funding. I've been doing that lately, I'm at a small start up running engineering, but I'm an "employee", not a founder.
There seems to be a clear bias with VC companies against someone my age and background. Not to say I don't have a network I could probably work and get funding, I could. But I also wanted to get back to square one and work with people again and NOT have to deal with things like Healthcare, stock options and "hey, that person needs a week off because their cats sick." -- I'd rather just CODE and learn more, enjoy the art of buildings things without the pressure of an investor looming over you.
I've made enough money to be comfortable, but I still need to earn a living -- I haven't made that "FU" money and my wife laughs and jokes that for as much success we've had, even if I did get the "FU" money, I'd still want to work 70 hours a week and write code... ;-)
About your Skype coding comment. Yeah, new trend is to "pair" with someone online in an interview process and go through programming challenges. I'm OK with that, but I don't work well that way. I work better in a situation where I can think and spend the time myself on the problem. My brain isn't wired for "fast and rapid", it's more of a "trial and error" until I get it working, then later on optimize and make it better. I do terrible at that first pass, always been more of an interactive developer who starts with something that works and then over time perfects it. That style SUCKS on a pair programming exercise.
you most definitely seem to be. i’ve both had and seen interviews requiring solving by hand various encryption algs using only a whiteboard. maybe you don’t require it but there are plenty of places that do
As a self-taught programmer who doesn't have a CS degree, my experience has been that this is not a significant hurdle to any workplace that I would seriously consider applying.
Where do you find jobs to apply to? I am also a self-taught programmer without a CS degree, and it seems that a surprisingly large portion of companies use obtuse algo/whiteboarding interview questions. My objection is less that I don’t know or can’t learn them and more that it seems like a waste of time to prep for stuff that isn’t useful.
Those companies aren't hiring, they are just sifting market for rock starts. I have seen this in numerous places already — when a company has enough product leaders, but still enough money/time to hire a couple more, they begin whiteboarding people. Several years later those product owners will leave, and suddenly the interviews are reduced to "you worked with <insert technology name>? Know what <insert technical term> is? Accepte^W erm, I mean we will contact you tomorrow!"
Several weeks after passing the interview you start asking colleagues about their own interviews. And everyone has wastly different experience. Some were hired after being harrassed for hours. Others got job thanks to friendly tip...
this is false, you can’t blanket companies like this. the job i’m currently at required me to find all palindromes in a set of strings. the company makes media management software.
As a self-taught programmer who doesn't have a CS degree, my experience is substantially different. There are many places where I would seriously consider applying (FAANG) that this would be a significant hurdle.
I've taken to competitive programming as a way to prepare myself, but I'm a long way away from being at a level where I'm comfortable applying to the companies I'd like to work for.
I think a lot of people like you and I pretend to make the choice of, "I'd never work there" when the reality is, "They'd never hire me", and it does everyone a disservice to continue to perpetuate that lie. It's not a problem or a negative thing that FAANG would never hire me/you, it's just the truth.
FAANG would never consider hiring you or me as-is, but if we worked really hard for awhile, they would. This has nothing to do with our ability to do the job they'd hire us for, but that's the game, they want their candidates to be good at the game, and I'm at least willing to play. You aren't willing to play, and that's fine, but don't pretend like you're being the discerning one here.
As a person without the degree that works at one of these companies, I can honestly say that it's incredibly difficult to get in. What I haven't seen anyone talk about is how it haunts you constantly. Not necessarily coming from other people, but knowing that if someone wanted to call you incompetent, it'd be on you to prove otherwise since you dont have the degree to back up your knowledge. I wish I could go back and get a CS degree just to tame the thought that it could all fall apart so easily.
Exactly, you took the words right out of my mouth. I'm 6 years in as a web dev and still feel the downsides of not having that paper. There is that constant, need to prove feeling that lingers in my mind. I'd love to work for a big company but I am stuck in my country. Visa approval requires that paper to prove you're skilled. Stuck with opportunities that pay really less, compared to Europe/USA. Don't know about you but, I recently decided to bite the bullet and join a CS degree on the side. Going to be tough 3 years, but it'll be worth having that paper once in for all.
> Visa approval requires that paper to prove you're skilled.
There are ways to go around that - in some countries, US among them, you can count some years of specialized work experience in the field in lieu of formal education ("degree equivalence" - I believe). I got a work visa in Canada on that basis, and later L1, H1B, and finally a green card in US, without any degree.
With respect to US specifically, google for "USCIS three-for-one" for more on this.
I don't really know - in my case, it was all handled by my employer and their lawyers; all I did was gather the documents they told me they'd need (basically whatever is necessary to prove said work experience).
I am self-taught and work at Apple and the interview process is team by team. My team doesn't care whether or not someone has a CS degree and we don't ask algorithms questions. We care a lot about software engineering as a craft, though, and ask architecture questions.
Of FAANG, I only know of Google having a standard interview for all software engineers across the company (and one that is algorithms-heavy).
I am self-taught, no degree whatsoever. I didn't have a problem landing a job at Microsoft regardless, with a few years of mostly C++ experience under my belt. Wouldn't even say it was hard. And no-one at work had asked me if I have a degree, ever since that first interview.
Now, that's not FAANG, technically speaking (although FAANG was always about stocks, not job culture). But for what it's worth, I've had recruiters from Google, Facebook and Amazon try to lure me over. None of them indicated that my lack of degree is an issue for them.
Maybe that's team-specific, I don't know. But it's certainly not true that they'd never hire someone without a degree.
I think people are over-emphasising the importance of a degree when it comes to CS (obviously some workplaces filter by "do you have a degree" but I wouldn't want to work in such a place -- clearly they don't care about you as an engineer).
Sorry to be a bit old-fashioned, but a degree isn't the most important part of going to university -- it's the education you get. I would argue that it is very difficult for someone to learn about data structures and algorithmic complexity (+ algorithm design) without taking a university course or doing some pretty intense self-study. It's not something you can pick up on the job. And this is knowledge that I think more folks in our industry should have.
So you might be doing totally fine without a degree, and that's great, but I imagine that you also have some CS knowledge that OP doesn't have -- and maybe you picked it up from somewhere or did some study on your own to gain it. If I was a hiring manager I wouldn't filter on degree, I would filter on some sort of working knowledge of CS (and, for reference, inverting binary trees on a whiteboard is not an example of "working knowledge").
Oh, absolutely. When I say "self-learned", that includes bits and pieces of CS. E.g. I wrote a BASIC-to-C++ transpiler back when I was 14; and to do that, I had to learn things like recursive-descent parsing, for example, or how hashtables work (because I wanted my dialect of BASIC to have them) etc. None of it was from CS courses or books - just looking stuff up on the Internet as needed, often reading others' code. This kind of learning from experience is not a well-organized process, and the results were often a lot messier than they really needed to be - and would likely be with more formal education like SICP! - but it works.
I think you may be selling yourself a little short.
Many, though perhaps not all, FAANG interviews do not involve needing to know THAT much CS trivia. The common topics (for many interviews, it depends on the company, and at non-homogenized companies, on the team) are:
- What’s a graph? What are some interesting strategies for walking a graph? Any gotchas to look out for?
- What is algorithmic complexity? How do you measure it? Why does it matter?
- Are you conversant with middle-school level arithmetic and geometry?
- Can you describe the strengths and weaknesses of the 4-5 most common simple data structures?
- Can you listen to problems as they’re described, and ask good clarifying questions (the most common problem is here, people didn’t bother to take the time to ask clarifying questions)?
- Once you’ve nailed down the problem, can you structure a few nested for-loops with relevant tests and perhaps a few simple auxiliary data structures?
- Once you have a potential solution, do you test your work? Do you skip over your mistakes pretending they don’t exist? Do you take hints when your mistakes are pointed out to you?
- Do you admit when you don’t know, then try exploring anyway?
Seriously, this is the entirety of what I see most FAANG interviews covering. If you’re a competent self taught programmer, you need to study a tiny bit about data structures and algorithms, stay calm, ask lots of questions, and just execute.
I get that there are lots of horror stories out there, and I genuinely feel for people who get super anxious when asked to work with an audience.
But if anxiety isn’t your problem, I encourage people to try different teams/companies if they’ve mastered what I’ve listed. FAANG really don’t want to put the bar absurdly high, they want a relatively easy level of CS knowledge.
Hey, just wanted to say I think you have a very fair perspective here, and I'm not sure why you got downvoted (perhaps your comment was perceived as rude.)
I'm actually not interested in working at FAANG. I don't want to live in California, I don't want the long hours, I don't want the stress, and the products and culture are not very interesting to me. The salary is pretty much the only selling point IMO.
However, you make a fair point: If I _did_ want to get into one of those companies, I would need to study CS (academically or non-academically).
I have to point out something that I haven't seen anybody say here -- there is a huge amount of variety in the difficulty of these sorts of interviews.
I assume that all FAANG interviews for entry-level software devs are akin to the standard Google interview, for which you are expected to study your ass off. I have not interviewed for one of those companies, but of course I know how much people study for them, and it disgusts me. However, I have had plenty of interviews which did have an algorithm-type section (the majority of interviews I've had have had something like that), and I no longer hate on companies for doing _that_. Plenty of the problems are relatively easy, once you figure out how to talk about them -- and being able to talk through your work is a legitimately valuable skill.
But, companies that expect applicants to put in the kind of work Google expects in order to stand a chance truly are not companies I want to work for. To some extent, it's just shitty; this "game" is mostly a test of how much time you have to spend. That cost is a lot higher for people who are less well off, which irks me, but that's true of most things in life.
The thing is, you talk about being "willing to play" the game. I don't want to work in a company of people who played that game.
First -- Playing the game means sacrificing important things; you can't spend all your free time studying which data structures to use for esoteric string manipulation problems, etc. AND spend all your free time learning the fine point weaknesses of different databases, good programming patterns, etc. By the time I started interviewing for my second job, I'd nearly burned myself out making certain I was learning how to do things right, learning how to be a good programmer. My free time was spent polishing the things I was working on and endlessly reading about how to do it even better. And then I was able to go into interviews for the jobs I was interested in and do what you're suppose to be able to do in most other interviews (programming or otherwise); actually talk about the company, their pain points, possible solutions they hadn't thought of but I had experience with, etc. At that time, I could not identify anything but the simplest algorithmic complexities... but to learn more than that would have been to choose studying useless information over useful information.
Second -- What makes a person willing to play the game, when there are plenty of other companies with interesting problems to solve and good salaries (maybe not AS good)? I can't help but feel there is a cult-like love of these big companies (or maybe it's the desire to prove oneself, since only RealProgrammers work for Amazon). And I don't want to work with a bunch of people who are extra excited about something I just don't value.
Maybe I haven't been reading the right stuff, but I just don't see the appeal. I don't particularly care for any of them as companies. Sure, if Amazon decided to pursue a pilot project aimed at providing its customers with low-carbon-footprint foods, I might want on board that project -- but not just to Amazon as a whole. Yes, these companies are large and well-known, but I don't particularly care if it's one million or one billion people who download an app I worked on. I know that getting a job in one of those companies doesn't mean you're going to do something interesting or big. I've had classmates get jobs at Google and I've worked with Google employees on certain projects, giving feedback etc. There's nothing I've seen about their jobs or projects that were particularly amazing or wonderful, except for the part where you then get to say you work(ed) for Google.
To play devil's advocate, "which data structures to use for esoteric string manipulation problems, etc" is the kind of thing that interests me (and presumably some others) a lot. If I wanted to go for a FAANG interview I'd love to brush up on the algorithms and data structures stuff that fascinated me in college and I haven't had much cause to think about since. There are certainly other things I'd rather be doing, but it wouldn't at all be a miserable chore like you're describing. So maybe they're looking for people who think about these problems more like I do (and I'm not by any means saying I'd pass the Google interview) and less like you do. They have the pick of the litter after all.
On the other hand, there's the well-known story of the Harvard MBA answering Orkut support tickets so Google probably doesn't need that level of talent. But if they can get it, why not?
> Forget any of the rest of your skills, because we all know the only thing that matters when interviewing is an ability to recite CS algorithms out of memory and solve obtuse puzzles while pretending you've never seen them
This attitude only seems to exist in companies that are seen as 'top n'. Want to stop interview in this manner? Stop applying to these companies.
Unfortunately if you want to get the paycheck that comes from these types of companies, you have to play their games. You can't complain the interview system is broken and then only apply to jobs that offer 150k total comp and have brand name recognition.
For every FAANG with a broken interview system, there are 5 other decent companies with intelligent people that don't do this crap.
I think "mirror" is a more intuitive description of the problem, but essentially you reverse all of the left and right subtrees. This Quora question [1] has a few different approaches listed.
That doesn't sound like "inverting". If that is what it means then it is indeed a bad name.
I always thought it means making one of the leaf nodes a root of the tree. Physically, it would look like taking one of the leaf nodes with your fingers and "hanging" the tree off of it.
Inverting means inverting the sort order. The easy answer is to encapsulate the tree in a new structure and add a Boolean flag called “inverted,” since you’re just reinterpreting the meaning of left and right children.
What you describe is called “rotation,” and is used to rebalance.
I'm confused. Doesn't the operation described in those answers just rename each node's properties, but leave the topology of the data structure unchanged?
Meaning one could just have the code accessing the tree swap which names it accesses, and the tree would behave as "inverted" with no actual need to invert anything?
I read it, tried it out and it didn't took me long to understand and solve that issue.
If you hack around for a long time and you never ever felt the need or motivation to understand very simple tree algorithms, okay. But don't rant when a company like google expects that from you.
He also answered, after a few years on a website about it:
You can apply software engineering to develop an application, but you can also do application development without any proper software engineering.
Software Engineering is a design discipline, management discipline, and engineering discipline. Application development is (principally) the act of building an application by writing code. It doesn't require design, management, or engineering discipline to accomplish. But it's better if you've done those things (minimally, the engineering and design portions).
At the same time, a junior software engineer may not be responsible for anything but the writing of code, where others have determined the design and engineering aspects and are conducting project management for them. Or with only limited responsibility (such as developing tests for the aspects they're responsible for developing, which is a part of the engineering discipline: V&V).
In practice, the main difference is the pay / relative "rank" within a company. Employer's perspective: Want to hire a software engineer but don't have the budget? Create a new role, call it something else, now the pay difference is justified.
Context - I'm a software engineer by title but my job is application development. Which is hard, mind you! It looks like simple coding but it involves prioritizing, making smart decisions, and making all stakeholders happy.
I've worked in both of those environments, where my titles were literally "application developer" and "software engineer". In the former, we did a lot of things without process and worked on a wide variety of applications and in the latter I worked in an Agile environment focusing on a core product.
As with most HR departments, it could be a classification required for salary, which also highly depends on work experience and not necessarily school background.
- Someone who's job title is much fancier than otherwise necessary
What are the differences you consider when making a distinction between application development and software engineering? It seems to me that application development is a subset of SE.
I agree with you to some extent, but I do think sometimes this point of view is taken too far. Some basis in theory is useful, not so much because you'll directly apply something you learned in a CS class, but because it helps you learn how to think about difficult problems. Most real world work is indeed just putting pieces together to get the result you need, but there are occasionally things that really are difficult, especially to do efficiently. I think it could legitimately be a concern if an experienced programmer couldn't pass an introductory CS course.
To the OP, presumably your fiancé has study materials as well as just questions—why not audit the course, and learn how to solve the problems you're having difficulty with? (Then write a Tell HN and update us on whether you feel you learned anything useful!)
I think I have my geek bona fides, but, studying subjects like Domain Driven Design, Clean Architecture, Patterns of Enterprise Application Architecture etc.
The hard problems that I think most people end up solving are more often business, people and process problems than computer science problems.
Universities traditionally focused on Computer Science and their graduates would often need a lot of grooming before they could really be independently and reliably productive in the commercial words of application development or software engineering. Importantly, it was less grooming than someone who studied something like English or Sociology or History, but it was still a different discipline than what the job market demanded.
You jumped into the job market directly. You learned to develop applications, research API's, study trends, and participate as a team member in development workflows under commercial pressure. You don't know how to compose and compare sort functions for abstract sets of N elements because you never needed to. You just use sort().
And that's okay! Inventing new algorithms with theoretical significance is not your job! You have other skills and they're of much more immediate value!