This is dead on. I am a veteran currently going back to school for an engineering degree on the GI bill. When I got out of the service I didn't even consider going back to school, and just taught myself how to code and started working as a web developer. Once I made it to the point of working with other software engineers with formal educations in a large firm though, I realized the depths of my ignorance. I hit a wall that no amount of javascript bootcamps or rails tutorials could ever get me past. The fundamental knowledge of math and science that separates engineers from 'coders'.
I think the VA is absolutely doing the right thing here by not allowing code schools to take advantage of GI bill money. The industry does not need more coders, it needs more engineers. If these schools were legitimate they would be working in connection with established universities to provide accelerated ABET accredited degrees. You'll notice that the article posted mentioned nothing of the actual long term success rates of these programs, either.
I can't imagine taking a coding boot camp student seriously. And these fly by night schools have a history of fleeing vets.
I once had a boss that had a very similar attitude to what you're talking about here, and I left the position pretty quickly. And not once have I felt constrained by my lack of degree- if anything, the self-learning put me in a place where I more quickly learn new technologies because I'm more active in starting side projects using them.
I understand that one's school is a huge impact on their experience, but don't let it become an implicit endorsement.
I felt more or less the same. Then I worked with a few, all second-career starters from a variety of boot camps. Not all were great or even good at what they did - but some, one in particular, were excellent. The latter group seemed to share a degree of native intelligence, drive, and perseverance which didn't seem to occur all together in any of the former. It was almost as though the fact of having graduated a boot camp, by itself, predicted nothing useful at all...
I'm a small business owner in the UK - IT consultancy. When I'm running through a load of CVs for a technical position I instinctively move the Engineers and Technicians up and the others down the pile. I have other criteria obviously but as a graduate civil engineer myself I appreciate the discipline that an engineering quali brings and the sort of mindset as well (more concrete/steel/timber or bigger plant will fix most problems.)
Good on you for being a self-starter and having the perception that there is no short cut to becoming gainfully employable in civvy street (an old UK forces name for the other side) and being prepared to put in the work. I wish you all the best and suspect you will do fine.
Can you give some examples where you hid road blocks because of your lack of education?
I mean Facebook started out as a cookie cutter app. Heck, it was a basic CRUD app. Look at where it is today.
Outside of such unicorns there are also many examples of reasonably successful products that can be categorized as cookie-cutter. Basecamp. Trello. Snapchat. These apps don't do anything groundbreaking or operate on the bleeding edge of technology. But they are well-known and profitable.
I mean, it's great you're working on the latest computer vision algo to make the billboards in Minority Report a reality. I just spent the day wrestling with Google's client API registration and authentication nonsense so I could get per-page bounce rates.
That's why I own copies of Knuth, and Sedgewick, and Cormen, Leiserson, Rivest, and Stein.
Now, the ability to understand and make intelligent use of those resources is something that requires education (formal or self). But oddly no one (that I've heard of) ever tests for that ability in job interviews.
In that sense, asking a developer about how to balance a binary tree, is a dumb interview question.
He should only know, if he happened to have worked on exactly that type of problem, only yesterday or so.
The question is rather: If the following is the description of the algorithm to balance binary trees, show that you understand it by dealing with the details in the following examples.
The dirty secret is 90% of what happens in the real world (and on HN) is a solved problem that needs to be applied or re-applied. Someone has done it before and they've done it better than you will.
The former is a healthy and pragmatic use of your most valuable resource -- time. The latter is a cop-out. If no one actually understands what is going on at a deep level in the library, the result is likely to be an over-engineered mess. It might be that you're doing the most efficacious and appropriate thing for the task, but it might not. And with many such decisions made over the course of a project, some of them are bound to be wrong unless someone can reason about them and explain their purpose.
I find this is most important when refactoring or updating code. Some junior engineer down the line will encounter some code he doesn't understand, and track down the guy who wrote it, and at this point there is a world of difference between that guy saying, "Yeah, we needed a data structure that does X and Y so we used that library," and "Uhhh, not sure why we used that library, does anything break if you remove it?"
Stuff like "Oh hey, this problem fits a state machine approach" and "I can reduce the complexity of this sprawling if statement by making a truth table and minifying stuff"
And the good old "What you're asking for maps onto so and so problem and is fundamentally unsolvable. Can we tweak the requirements?"
Sure, you're not inverting binary trees every day, but it's useful to be able to see where a binary tree would help you solve the problem.
Just being able to look at a problem and go "hey, this is pretty simple graph traversal, I know the rules for this" has saved my bacon. Or the type theory that I picked up along the way that made type-heavy programming in Scala and Rust make sense. Or the set theory (math, but required for my CS degree, so I count it) that does bounce through my brain when I'm thinking about databases. Or even, like--"hmm, I think I can bang out a quick and dirty parser," and knowing what that parser should look like because I've studied how programming languages work and I get that for free.
I'm not the best programmer ever to walk the earth by a long shot, but I'm pretty good, and I'm pretty good because I can approach problems both bottom-up and top-down. Couldn't do both, flexibly, without a strong academic background.
If you look something up and the interviewer asks you what the O() of your approach is and you don't know, how can they feel assured you grasp these fundamentals?
I understand why these are contentious, but I find people tend to miss the forest for the trees when criticizing the practice.
It isn't irrelevant if you are attempting to implement it correctly.
> If you look something up and the interviewer asks you what the O() of your approach is and you don't know, how can they feel assured you grasp these fundamentals?
That wasn't the original question in the comment I responded to and your attempt to re-phrase it as X when it was a question related to a specific algorithm is disingenuous.
> Why would an iOS developer need to able to balance a binary tree?
---
<removed a bunch of RL-related stuff that is pointless bitching about ppl we've fired>
Exactly my point. Rarely is there one "correct" implementation. Understanding the choice you make and can support is the point of coding interviews. That's why they're so often done in pseudocode and/or on the whiteboard.
If you can look stuff up you're not demonstrating a knowledge of the fundamentals. If you don't understand complexity and optimization, you will make mistakes even if you can look stuff up later.
That's why these companies do these.
For any given problem asked in such interviews there is certainly one correct implementation and if you believe otherwise you are not providing sufficient information to answer such a question.
> Understanding the choice you make and can support is the point of coding interviews. That's why they're so often done in pseudocode and/or on the whiteboard. > If you can look stuff up you're not demonstrating a knowledge of the fundamentals. If you don't understand complexity and optimization, you will make mistakes even if you can look stuff up later. > That's why these companies do these.
Honestly? This is part of the rant I was trying to avoid.
1) I've met developers that claim SHA-1 is a secure choice in 2017 and make other facepalm worthy claims that 5 minutes of research would have told them was a bad idea.
2) We've fired quite a few people who believe as you do precisely because they are so convinced they understand the fundamentals they don't look things up and make costly mistakes.
3) I've met accountants who can't correctly handle a 4-4-5 calendar that is integral to their jobs without looking things up. Similarly, I've met ones like you that genuinely believe they've memorized the "fundamentals" and repeatedly failed waste thousands of dollars.
4) I honestly believe anyone who refuses to look things up to double check is fundamentally incompetent. We all make mistakes and the only way to appropriately minimize them is to double check (i.e look things up) before hand and have someone else review it afterward.
5) I genuinely do not want to work with anyone who does not do #4. Ever. The sheer number of times they've attempted to shift blame onto other people before they were fired is simply not worth the hassle.
As to your assertion that there is one "true algorithm," the merits of that stand for itself, but regardless being able to explain WHY is what an interviewer should look for.
"Go Google and implement some algorithm" does not provide a useful metric other than "can use a computer."
All of this also ignores a more pressing issue: that looking something up often means getting bad results. Can the applicant draw on knowledge of complexity to distill their Google search? Without that types of test your answer is "hopefully."
That's why Google, FB, etc start with whiteboard tests. Anyone can search and implement.
It isn't difficult to structure a complex question that requires research and have the answer you claim is impossible to find.
> That's why Google, FB, etc start with whiteboard tests. Anyone can search and implement.
I'm sure that is what you believe but that doesn't make it true.
> 2) and 4) and 5) are strawmen. It is -in fact- possible to understand the fundamentals and look things up.
I've never met an engineer (or any professional implementing complex processes) who simultaneously grasped the fundamentals of all areas where they needed to possess competence from memory. (Yes, that includes myself in case you are wondering.)
An answer? Sure. THE answer? No. Too much subjective reasoning in that; something that performs well with clock time may be far worse in some other metric. It always depends. You need to be able to explain it, and that's what complexity is about. Fundamental comprehension of the tradeoffs of approaches.
> I'm sure that is what you believe but that doesn't make it true.
Great. Same with you. Unfortunately, those companies agree with me and do fairly well filtering candidates.
> I've never met an engineer (or any professional implementing complex processes) who simultaneously grasped the fundamentals of all areas where they needed to possess competence from memory.
Me neither. But then again that's not what we're talking about.
I wouldn't say that you don't need it, but I would say that most companies ask about the wrong bits.
[1]: http://www.seattletimes.com/business/boeing-aerospace/dramat...
Somebody needs to know how to implement sorting algorithms too. It's just highly unlikely to be you.
If you want to have an engine with 60s power, weight and fuel economy, then sure you don't need to know the science behind it. Just throw some parts together, and you'll get something that works.
If you want to sort a list, balance a tree, multiply a matrix or find the shortest/cheapest path in a graph, you should use a library that already does that and is reasonably tested and optimized, certainly more than whatever you'd write today. Most likely you shouldn't even get to choose which algorithm to use for that, and if you need to then the choice should be based not on the O() measures you might remember but on benchmarking, since the constant factor often dominates.
I have seen quite a few very large systems in which the most complicated algorithm actually implemented in the system is a set of branching if-then conditionals for some business logic. There's no custom data structure traversal - yes, it needs some data processed, but all the algorithms for that are in the DB implementation and "do X for all selected items" is literally the deepest level of iteration anywhere in the system. There's cryptography, but that's in a separate library made by someone else. There's network algorithms with state in them, but that's managed by a separate layer.
In such data processing systems all the development does is glue code that specifies what exactly should be done, but all the how part (e.g. the algorithms) is already implemented by someone else and is reused.
There are fields and apps (parts of them) that are algorithm-heavy; for example, even simple games tend to pack a lot of interesting algorithms (but even there much of that is now handled by standard libraries/frameworks). But most developers don't work on that, the majority of software dev work is cookie-cutter data processing apps where all the algorithms are out of your scope.
Those interview questions aren't about "algorithms", they are about details of specific ones chosen by their complexity and that are rarely used in practice.
Not a veteran, but I've noticed something very odd about entry level jobs - they're not challenging. And that is no accident someone hiring you is actually doing that with a clear expectation that the complexity you're about to encounter will fit into their schedules.
Higher education is very different - the professors are intentionally trying to push you, hopefully bit-by-bit out of the existing skill range into unknowns. At least mine weren't trying to teach me, they were trying to get me to learn, mostly by making my own stupid mistakes without a huge penalty attached to it.
When I moved out of my CS course (and my open-source work building compilers) into my first job, the skill required to do my job satisfactorily was trivial.
No more hard problems, just hard timelines.
Took a couple of years and changing jobs before again landing up with a problem I didn't know how to solve ("Uh, make PHP5 fast ... Go!"), which helped me grow and learn.
That was a lucky break, but I succeeded because my professors had pushed me into the deep end against my wishes (i.e more sleep) before.
At a certain point I was working on an iOS app attempting to do some really advanced animations with Core Animation/Core Graphics and my total lack of geometry and basic algebra knowledge started to show. One of my colleagues started talking about the movement of an animation in terms of radians and pi and I felt completely lost. He was speaking a totally different language to me. Up to that point I had felt somehow "proud" of being a self taught developer with no formal schooling. But when that happened I just felt completely embarrassed at my lack of fundamental knowledge and context. Now I'm struggling through undergrad mathematics classes and hoping to get to that point some day. The greatest overall takeaway I had from that experience is that math and science open a completely different world to you that most people don't even know exists. It changed my life.
Only math. Furthermore, someone with years of coding instinctively develops such mathematical understanding, while the very same understanding will be lost on someone who just graduated, but has never coded.
FWIW, this isn't my experience. I have a CS/math background, spent the first few yrs of my career at Google, and then moved to a startup as the first employee. We had a lot of difficulty sourcing good candidates, and our first two hires were 1) a guy with no engineering experience and domain knowledge that had programmed during his Master's (and had some useful domain knowledge) and 2) an engineer with ten years of experience. I supported the first guy's hire and the second guy was hired against my recommendation.
The first guy hasn't yet had occasion to put his actual specialty to use, and yet after a month of some pretty hands-on guidance to teach him basic engineering habits, he is pretty much crushing it. He's dependable, he's creative, he's hardworking, he can implement stuff quickly but also think about the big picture: he's certainly exceeded even the fairly high expectations that I had of him despite having no eng experience and relatively limited programming experience. I had the exact same experience with a math PhD who worked under me at Google: he was hopelessly unproductive for the first month or two (Google is really, really, REALLY shitty at ensuring that new hires with potential get the guidance they need). I noticed this and took him under my wing to teach him the basics of engineering (which are truly not very difficult to learn) and in a month or two he was one of the best engineers on our team.
Our other hire is.....the opposite of all of that. He's basically been reduced to the only thing he's shown himself able to handle: he spends two days working on okay-to-have changes on the margin that no one really needs but that I could've taken care of in half an hour. 90% of the time he ends up breaking stuff that I have to spend 20 minutes fixing anyway.
TL;DR: my experience has been that there are certain skills and ways of thinking (and perhaps innate talent? I dunno) that are incredibly useful for engineering that some people go years and years and years in industry without ever acquiring or strengthening. On the flipside, someone with these capabilities can become a solid engineer in very little time. Good CS and math depts tend to instill or select for pretty much exactly this set of skills, in my experience. The main gap they have is a set of best practices for being a little more meticulous about their code, and this is shockingly easy to teach.
But the 1st engineer is starting out so he's extra motivated. Motivation brings out creativity, energy, and result.
IME, a lot of them boil down to the principle of least surprise and not keeping silent dependencies on things in unexpected ways. These sound trivial and obvious, but they manifest in a thousand different ways, and the habit of constantly and subconsciously checking for these things in the back of your mind while designing/coding/reading code is something that comes with practice. As I said, I don't think it's very difficult for intelligent people to learn this give a little bit of time, which is why I hire for creativity and problem-solving skills instead of direct experience with certain tools. Particularly at our current size, dead weight is infinitely costlier than it would be to a behemoth like Google. Our latest hire has never worked in anything but C and he's already more productive on our Python codebase than hire #2, who has the advantage of years of Python experience and months more tenure at this company.
> why was engineer #2 not able to adopt them?
It's not so much that engineer #2 couldn't adopt these habits: it's that he's apparently not capable of doing any actual functional implementation, which is a prerequisite for a functional implementation that's well-engineered. The point I was making was that an intelligent, creative hire missing engineering experience can easily and quickly be taught. But an experienced engineer without creativity and intelligence is not very useful.
As far as why he can't do any functional work: Every time I mention this to someone[1], people seem pretty put off, but I honestly just think he's just not a very smart guy. For some reason, the very idea of differing levels of intelligence seems to offend people, but I'm racking my brains here and I can't think of another reason why he would be so abysmally unable to do anything. In conversation with him, your response never gets addressed and he just rephrases his last point ad nauseum with no hint of comprehension. My (semi-technical) founder has pretty much been working directly with him and he hasn't had any luck in finding things for him to do either. I guess the silver lining here is that I'm batting 1000 on hiring recommendations so I hope in the future I won't be overruled on tech hiring.
[1] Not at work: that would be entirely inappropriate. I mean to friends/confidantes when they ask me how the new job is going etc.
In my experience, intellectual curiosity, intellectual openness, raw intelligence, initiative, and attitude are much better indicators of success as a programmer than having a degree.
That's a very good point and I have actually been very careful to consider that. There's still a tiny chance that it's possible, but I'm pretty sure that's not the case. The fact that we ended up hiring this other guy against my wishes gives me a nice little counter to confirmation bias. He's pretty horrible even on the stuff where he has a huge (theoretical) advantage over me and the other engineer, due to having much more real-world experience with it. You just can't work around a lack of creativity, conscientiousness, and problem-solving skills.
For example, I set up most of our non-core-logic systems stuff by the seat of my pants (servers, DBs, caches, etc etc etc). I got roughly zero experience with this stuff at Google because the tooling was so excellent and taken care of by large, expert teams. It's been a great learning experience both in terms of familiarity with the tools and the trade-offs that come with small size/too much to do. Learning these skills is part of why I wanted to try a small company. Since this guy has proven himself utterly useless at anything even remotely involving engineering, he's been reduced to marginal changes to this kind of systems stuff, setting up things that are very low-priority so far. He still manages to mess up most of these! Every time he pushes a config change, or sets up a new service, or does _anything_, something is broken and I need to fix it. Most recently, he burned through a few thousand dollars in a couple weeks by making an entirely unnecessary switch away from our key-value store without noticing that his new set up used a dozen beefy reserved instances.
I don't have 100% confidence in my view here since my sample is so small, but the original point I was arguing against was that "years of coding will teach you mathematical understanding" and that this obviates a math degree. Everything I've seen from different vantage points has pointed to this not being true. It's entirely possible for someone with a decade of engineering experience to be almost utterly useless (cf Jeff Atwood's old post about "senior engineers" being unable to FizzBuzz).
Right. You cannot solve engineering problems with programming skills unless you also know engineering, just like you cannot write accounting software unless you know accounting, etc.
For another example, if you were coding the Shazam app, a good understanding of undergraduate math is needed to code of the fast fourier transform part. Even more so, one would need that knowledge to even realize that an FFT was the path to a solution.
What most of society doesn't seem to understand is that returning veterans are quite anxious about getting out and this makes them very vulnerable. They are like the Trump voters willing to throw their lot in with whomever tells them "it will be okay", regardless of how unscrupulous and incompetent those promise-makers are.
I wrote this in favor of them: https://academia.stackexchange.com/q/14833/9518
> Students overwhelmingly report retaining and applying less from online courses versus face-to-face courses. > However, this may be due to a difference in factors other than distance learning.
However, I find your insult to Trump voters gratuitous and unnecessary.
I originally upvoted the OP's comment as I somehow missed this aside at the end and unvoted. HN is really not the place for that stuff...
> They are like [the] Trump voters willing to throw their lot in with whomever tells them "it will be okay", regardless of how unscrupulous and incompetent those promise-makers are.
www.npr.org/sections/thetwo-way/2017/03/31/522199535/judge-approves-25-million-settlement-of-trump-university-lawsuit
I read it without placing the emphasis on the colon and I'm sure it's less barbed and strengthens the point:
They are like [the] Trump voters willing to throw their lot in with whomever tells them "it will be okay", regardless of how unscrupulous and incompetent those promise-makers are.
That there were some, not all, trump voters who were actually quite vulnerable and were manipulated. Just as there were some Clinton, Johnson and abstaining voters who were vulnerable and manipulated.
The key difference was that Trump dropped a shockingly honest hint about the desire to exploit the manipulable: "we love the poorly educated," arguably has a hint of suckering about it. I suspect this is something some Trump supporters are uneasy about by appealing to symmetry (i.e. if the other side had done this).
I found the analogy I misread quite useful as it linked two phenomena that I had previously believed to be disparate. It would be a shame for that to be lost for the sake of a missing word and a superfluous colon.
Shocking indeed. But not on substance - no one familiar with modern US politics would seriously doubt that most politicians are absolutely for sale, although probably not thinking of it in those terms, or that the two meaningful parties do absolutely sucker rubes into voting for cynically promised outcomes which often aren't even plausible and are the rest of the time rarely pursued. Obama was the best I've seen in my lifetime, in terms of trying hard to live up to his campaign promises and also being competent to pursue them, and even he only passes if we grade on a real generous curve.
No, what's shocking is that anyone would say it, at least where the rubes might hear. And, again, that is shocking! One does not expect to hear the inchoate doubts shared among much of the electorate confirmed outright by a major-party candidate. And I suppose if one confidently expects to get screwed either way, it might make some sense to vote for the guy who's at least honest about it.
Because to me, he's applied an analogy describing a certain behaviour to both groups: but you find one "a political insult" and presumably one "an accurate description, or at least an acceptable anecdote".
It appears to me, as a non-american, the analogy is not only apt but accurate, but i understand how one may find it insulting.
But then, I also understand how a returning veteran might find this entire thread/idea insulting when applied to them.
But in both cases...that doesn't make the point deviate or approach the truth any more or less.
Personally, I believe there is a "rational voter paradox" at play in both of our societies political cultures (I'm australian for what its worth).
We find certain ideas insulting and degrading when applied to the notion of "voter", because we carry a political ideology of sanctity (the rational voter) around the voters decision. Because we are partisan, any attempt to analyse voter activity that draws away from the rational automatically puts you in the camp of "the other", which makes you an enemy, which makes everything an insult.
Hint that voters voted for trump because they were anxious and threw their lot in with someone giving out soothing epithets and its an insult.
That same idea however, returned service men being anxious about the future and being duped into throwing their lot into schools that make grand promises...and its an observation. Even a completely legitimate thread.
I've had the same thing happen to me a few times: express what I think is a fact, and been told that this is not the place for such hostile speak, insults, or comments.
I will leave HN today with this thought from my professional experience: If you're an analyst, and you actually have to predict these things, don't give anything but politeness to the people who find such observations to be insults, even though you know they're wrong, and use them if they're predictive :P
> They are like [the] Trump voters willing to throw their lot in with whomever tells them "it will be okay", regardless of how unscrupulous and incompetent those promise-makers are.
You know this. We all know this. So why bring it up in an unrelated thread?
All it does is damage the quality of conversation.
To me, it was like being in a thread about trees and saying "Trees are green, you know, like money." The "like money" part, was just a comparison.
This all sounds like pretty much every starting undergraduate student I've ever encountered.
Similar for other technical tracks like aircraft maintenance. The bar to entry for these kind of jobs are minimum ASVAB test scores that aren't easy to make.
You may have encountered a lot of ex infantry or similar. They get intensive training as well, just not as cerebral.
PSA: While IRAC is generally associated with law school and lawyers, anyone can learn and use it. It really does works.
I mentioned the asvabs not as a comparison to writing a paper, but to note there is a bar to get into the highly technical jobs. Similar to the bar created by things like minimum SAT scores for some schools.
Talk to an ex military person that had a highly technical job that required 6+ months of military tech school. They have the skills you are talking about.
Talking about ex military like they are one homogeneous group just doesn't make sense. Skills vary, just as with recent high school grads.
It might not require the kind of very technical training that say Navy nuke school does, but assuming sandworm was talking about proper "special forces", as in Army SF, most of those guys tend to be older, more mature soldiers and I believe all Army SF candidates have to take the DLAB and then attend language school for 6+ months. I would have assumed that sort of environment would actually translate fairly well to undergrad.
Also, FWIW, I don't buy the premise anyway. Some percentage of fresh HS grads do well at college, some don't. Same is true for military vets. I was trying to pinpoint a specific group that I knew would mostly do well to dispel the notion that vets are somehow not great candidates for it.
https://www.propublica.org/article/rare-agreement-obama-romn...
The idea is to align incentives -- the employers get to try vets, and if they succeed, everyone gets more money.
Also many many veterans, during their service, avail themselves of old school MOOCs before they exited. They're called correspondance courses or sattelite courses and most of them are from traditional colleges and even allow you to finish up your degree at said college. What does a MOOC offer over this? If enough vets aren't using these why is a MOOC going to be the magic bullet?
> Some code schools do accept GI Bill benefits — longer-standing ones that have made it through State Approving Agencies, which work on behalf of the Department of Veterans Affairs to decide which programs can use GI Bill money.
So it can be done, and responsibly. I guess the only thing that's left is to increase the number of seats at VA approved schools.
Very shitty situation. The reason post WWII GI bill worked that well was that there were veterans everywhere from WWI and the draft that they could relate to and get help.
Also according to wikipedia there has been a form of the GI bill running basically continuously since WWII, so this isn't a new change.
What I think is hard about college for a lot of people is that much of the learning, even more than highschool, has no immediate relevance. Heck I remember hating a lot of intro CS classes because I was solving problems I didn't care about. Or think about asking a kid what they'd want to program a computer for. For most it's such an abstract problem to problems they haven't even encountered yet that they can't even think of anything. Same goes for a lot of people which can be a bug turn off for a more traditional college education. That said I still think you need a foundation in the theoretical as well as the practical.
Would you be able to point out more precisely what you were referring to? I did not find such an assertion anywhere on the Wiki page[1].
Then the GI Bill can pick up the tab for such programs.
I learned how to write my own linked list however..
In that way, bootcamps do a better job. If we are doing a 2 year turbo degree, they could learn a lot from boot camps.
How long would it have taken you if you had not done that degree first?
Plus, established universities don't teach the trade, they teach you how to think about learning the trade. You actually learn the trade in co-ops and internships and by doing it.
A university wouldn't run a program like a code school. They're a better fit for a tech school or community college (which can be public, regionally accredited, and part of a larger state higher education system).
https://www.deanza.edu/counseling/degreecert.html
https://www.ucsc-extension.edu/programs/software-engineering...