Earlier quoted context omitted.
This is not something to "remember". If you don't know this, you don't understand it.
I don't think so, I think this is one of the easiest things to forget. Even in school, Big-O is used almost exclusively, very rarely do you see Big-Omega, Big-Theta, Little-O, etc. Even though in algorithmic analysis these are all used to give a more accurate characterization of the algorithms behavior. Its funny, too, because the professionals (that are admittedly very smart) that like to talk down about Big-O as if…
Show HN: I made a jobs board for developers without degrees
331–336 of 336 posts
Re: Show HN: I made a jobs board for developers without degrees
#332Earlier quoted context omitted.
I've been in my current position for almost six years. Also, I do have a degree. It's just not in CS. And yes many jobs were contracting at the beginning or hopping for better pay. Everyone in the valley does it if they can.
If you do have a degree, how can you know that it has never mattered?
Re: Show HN: I made a jobs board for developers without degrees
#333Earlier quoted context omitted.
> but try not to disparage the people who decided not to stick around and are working in the same jobs as you Theory matters, classic example here[1], and if pointing out that people are making well understood mistakes because they haven't studied it is disparaging, so be it. [1]: https://github.com/promises-aplus/promises-spec/issues/94
That's certainly impressive, though 99% of developers aren't in the business of making high level language design decisions like that. I agree though I think it would be very rare to find a self-taught developer that's studied category theory and other high level mathematical concepts on their own. I think Brian Mckenna made some very convincing points with that article. I don't think college is bad, I think debt is…
Theory tends to bite when something breaks, though.
Performance problems are often explained through computational complexity, or concurrency theory. Strange values can be due to numerical error. If you see something weird in Javascript transformed by Babel, or really any compiler, you might be dealing with graph theory. If there are problems in a databsae, you're dealing with relational theory.
And yes, you can often Google the problem, but you're definitely doing better if you're the person whose answer everyone is searching for.
> That's certainly impressive, though 99% of developers aren't in the business of making high level language design decisions like that.
I think they do, though, because they get an incomplete spec and have to fill in the blanks.
"Agile languages" can be characterized as having concrete types: strings, ints, floats, lists, maps, sets. And the 99% of developers are using these languages and creating data structures using those types, and sharing those data structures, often via JSON.
This results in what I call "data pasta" being shipped back and forth between systems. And those ad hoc structures are effectively codified when they become APIs or are saved in NoSQL systems.
Does a CS degree help with this? I'm mostly aware of the problem because I've done it and then tried to clean it up in systems I work on. So the theory helps, but you need some practical guidance.
What the dichotomy of CS degree or self-taught misses is that the CS degree is aimed at learning the math, and while the math can guide best practices, you don't actually study best practices.
> I don't think college is bad, I think debt is bad
Yeah, I graudated in '03, so debt hadn't blown up. Even if we stop shoveling money into universities, not working for four years is still a massive opportunity cost, and a partially completed degree is worthless, exposing students to a tremendous risk.
And so it makes a lot of sense for people to do bootcamps to get their start in the industry, and regardless of whether you're self-taught or not, it seems like you could benefit from some formal training before you take on a senior role.
My degree had some courses on software engineering, but they were focused on requirements documents and UML diagrams and other high level stuff, which I wasn't going to see for year to come.
So maybe a software engineering course for people with industry experience could go over best practices and justify them through the math.
Re: Show HN: I made a jobs board for developers without degrees
#334Earlier quoted context omitted.
technical interviews are the worst thing ever. They prove nothing except that a candidate crammed for you exam and/or work well while being watched. I can't imagine either of those are useful. I did an interview with one of the FAANG.Co once and ended up arguing with the technical interviewer because he was a douche. When I found out he would have been on my team I told the recruiter I wasn't interested anymore. They…
That's a myopic and emotionally charged way of looking at it. When I interview people, I ask straight forward, probing questions looking for how the candidate approaches the problem and the path they take to the solution. I don't ask trick questions, I don't mislead the candidate, and I help them as much as I can to get to a solution on their own. However, I look for and probe for information throughout the process.…
sure is emotionally charged, but I don't know that it is myopic. I have thought many many years about the contents of a technical interview. Taking a step back from the argument I recall decades ago noticing that, I believe it was the bureau of labor statics, software programmers are considered "unskilled technical labor." I was initially offended by this. I have now come to the realization that this is generally true. Skill is not required to make software, nearly anyone can do it. Leading back to the argument though, what makes someone good at being a software developer is not technical skills. It is general competency, critical thinking, and being a good communicator.
> Had someone asked me to implement a JSON parser in brainfuck - I would have got up and left. More generally - if someone asks me to use a _specific_ language in an interview; it's not someplace aware enough to know that 99% of the time the language is unimportant and not somewhere I want to work.
to be fair that wasn't the exact request. It was more along the lines of "using whatever (approved) language you'd like, implement x with that assumption that your base language can only loop and increment." x in this case was something like do division. Which I know is possible, but also something I would never need to do and as such the solution wasn't immediately available to my brain.
> With all that being said - technical interviews are not "the worst thing ever". They serve a vitally important task of ensuring I work with competent and personable people.
was definitely hyperbole, but my point is that a technical interview doesn't serve the purpose that you lay out for them being vitally important. A non-technical interview is far better and easier to evaluate a persons competency, problem solving, communication, and "personable people".
Point being an entry level person with competency and problem solving skills can be taught technical skills very quickly and/or learn as they go. Non-entry level, well, their resume should tell you they have the technical skills assuming their references check out. So I really think we should stop wasting time and talent on "technical interviews"
Re: Show HN: I made a jobs board for developers without degrees
#335Earlier quoted context omitted.
And you can't read a book in teaching yourself?
Many self taught developers will focus on less theoretical skills related to programming and focus on what's practical. They may read a textbook to teach themselves but it'll be different than the textbooks they make you read for a CS degree. This typically is a benefit, many fresh CS grades I've seen are not as comfortable developing in their first job as a lot of self taught developers.
Re: Show HN: I made a jobs board for developers without degrees
#336Earlier quoted context omitted.
That's a myopic and emotionally charged way of looking at it. When I interview people, I ask straight forward, probing questions looking for how the candidate approaches the problem and the path they take to the solution. I don't ask trick questions, I don't mislead the candidate, and I help them as much as I can to get to a solution on their own. However, I look for and probe for information throughout the process.…
> That's a myopic and emotionally charged way of looking at it. sure is emotionally charged, but I don't know that it is myopic. I have thought many many years about the contents of a technical interview. Taking a step back from the argument I recall decades ago noticing that, I believe it was the bureau of labor statics, software programmers are considered "unskilled technical labor." I was initially offended by thi…
This sounds like a great interview question. It calls on the candidate to show they understand what a turning complete system is and then put that knowledge into practice to create the fundamental building blocks that are normally given to you.
You used hyperbole to make it out to be something it definitely wasn't.
> Which I know is possible, but also something I would never need to do and as such the solution wasn't immediately available to my brain.
In fact, you do need to do it, you needed to do it for an interview. The fact that you see it that way might underscore a personality trait that the interviewers might not have liked. Thus giving credence to the interview process immediately.
> A non-technical interview is far better and easier to evaluate a persons competency, problem solving, communication, and "personable people".
No it's not. It's far better at providing a "comfortable" place for someone to chat without actually proving anything. A good technical interview is problem solving _with_ time to chat and prove understanding of concepts.
> Point being an entry level person with competency and problem solving skills can be taught technical skills very quickly and/or learn as they go.
This is clearly false otherwise we wouldn't be starved for competent technical candidates. There're thousands of companies looking for qualified candidates and they can't find them.
> their resume should tell you they have the technical skills assuming their references check out. So I really think we should stop wasting time and talent on "technical interviews"
Resumes are worthless - doubly so now that politicians have made lying OK. The majority of people I've interviewed lied on their resumes, either as small white lies, or as large ones. And personal references are also garbage - there was a recent radio host that called random numbers and asked for a "reference" for a candidate they were interviewing. People went out of their way to talk up the fictional candidate.
> Leading back to the argument though, what makes someone good at being a software developer is not technical skills. It is general competency, critical thinking, and being a good communicator.
Yes to critical thinking and communication. You just aren't going to get a good read on a candidate without asking thought-invoking questions. You've either never had a good interview or you don't interview well and disparage the process to feel better.