Live data from Hacker News

A computer science study plan to become a software engineer

github.com

91–100 of 220 posts

Re: A computer science study plan to become a software engineer

#91

"When a measure becomes a target, it ceases to be a good measure."[1] These coding challenges used to be a very good measure of ability, but now applicants are just memorizing the most common problems for each company. We're not at the point where these tests are useless but we will get there in the near future. The problem is that I haven't seen any good alternatives. [1] https://en.wikipedia.org/wiki/Goodhart%27s_l…

The best coding challenge I had to do was when the company basically gave me a set of requirements, said build this. Took about an hour. Then during the interview, I was asked about my decisions, and blockers. Afterwards I was given another feature to add. This took another half an hour.

I wish more companies would do this. The hardest part for me at least is staring at a blank document.

Re: A computer science study plan to become a software engineer

#92
post #9

This isn't a bad list of topics about data structures, algorithms, and software fundamentals, but let's not pretend that computer science has anything to do with most software engineering roles. I studied computer science, and in 30 years, I've hardly used any of it. There were a few jobs where some of the statistics and math were helpful, but in my long career, I've seen very little overlap between computer science…

> and in 30 years, I've hardly used any of it. Isn't that similar to people saying "I've never used trig in 30 years"? Isn't the point to train your brain to think in a certain way, more so than actually needing sines and cosines? For computer science specifically, the goal is to teach you to think in terms of loops, conditionals, recursion and so on. It's to train the muscle more so than memorize specific algorithms…

The screening is not optimized to find the best candidates, its just an arbitrary filter that will in the long term let some people that would be fundamental to the survival of the company out of it.

Sometimes its good to accept that the uncertain things are uncertain.

If i were them, i would find and train good "screeners", people with talent to spot talent and just let them do the job. Sometimes they will only have a hunch, giving their observations of things that escape most people of a particular candidate, and even without much to show of, they might be right.

Later the top screener's would help the new ones to be better at their job, teaching their tricks.

This is very subjective and personalized, and even if there might be some objective ways to train the screener's better, i think its just nuts trying to use objective tests to define a good hire.

I bet with you that there are a lot of "human gold" out there that would only be detectable only when its too late for the company.

Re: A computer science study plan to become a software engineer

#93
post #75
post #67

Earlier quoted context omitted.

It sounds like you work in an industry that doesn't strictly require frequently delving into foundational theory in CS. I do believe it would be a mistake to conclude its useless, however, as there are many other industries that do need it, and people who are not in touch with the theory probably would not be competitive in those industries.

From your prespective how common are those types of roles in all industries as a whole? There are interesting compiler roles but the vast majority who learn how to build a compiler never use it day to day work. Would you recommend spending more time building compilers to better compete for those few roles or would you recommend a different approach?

I use most of my CS skills almost daily.

I may not be writing compilers professionally, but on the surface, understanding parsing has gotten me out of more than a few tight corners. More abstractly, there are lessens to be learned in designing large applications; and appreciating the difference between a finite state machine and a deterministic turing machine, including the types of problems they can solve and how much of a pain in the ass one is to write compared to the other.

Re: A computer science study plan to become a software engineer

#94

This isn't a bad list of topics about data structures, algorithms, and software fundamentals, but let's not pretend that computer science has anything to do with most software engineering roles. I studied computer science, and in 30 years, I've hardly used any of it. There were a few jobs where some of the statistics and math were helpful, but in my long career, I've seen very little overlap between computer science…

> Google and other big tech companies use these criteria to filter people out at the hiring stage, but the vast majority of work has nothing to do with any of this stuff. Yes, because at Google & Co. you actually NEED this stuff. I am not sure there is a day going by where being strong in math and computer science isn't immensely helpful for my job. The problem is: All other companies immitate Google, not only throug…

At Google & Co. you might need this stuff, but 99.9% of the other engineers at Google & Co. don't. Source: me, as I work at "& Co.", who employs numerous ex-Google staff, and have friends in other "& Co."s, etc.

What Google & Co.'s engineers do is gatekeep. Sometimes it's out of ignorance, sometimes out of inappropriate generalization of their roles to others, and sometimes out of a deep angst caused by working in roles that effectively make almost all their CS-specific trivia next to useless in practice.

Re: A computer science study plan to become a software engineer

#95
post #35

Earlier quoted context omitted.

Your comment reflects a common meme that can often be summarized as: "Real World" work doesn't involve the academic nonsense you learn in school. Many of the people who say this kind of stuff never really mastered the theory, and because they never mastered it they can't really use it, and because they can't really use it they find work that doesn't strictly require it, and then conclude it's useless... It's like whe…

CompSci theory hasn't helped me with the complexity of the industry i work in. It hasn't helped me when i've misunderstood something in our domain. It hasn't helped me release / distribute a product easier or faster or cheaper. It hasn't helped me navigate team dynamics or how to work effectively with others. It hasn't helped me write better technical texts. So for some very specific cases, in my career (and i suspec…

Maybe it's easy to overlook these things when you have a really deep computer science background, but coming to software engineering from a non-CS background (math degree) I found lots of valuable knowledge in CS. The most important parts for me would be:

- State machines. I run into a lot of state machines, especially incompletely specified ones. Not that everybody gets these wrong if they haven't studied state machines in a textbook and worked the exercises at the end of the chapter, but recognizing "oh, this is a state machine" gives me a mental framework, a notation, a vocabulary that other developers understand, and a better ability to understand when a problem is underspecified or inconsistent.

- Queueing theory and algorithmic complexity. These two usually come in handy from the perspective of spotting and avoiding stupid mistakes. It's true that people can do a pretty decent job from a handful of rules of thumb, but not everybody has that minimum knowledge, and sometimes a problem has a twist that an imprecise rule of thumb doesn't account for.

- Distributed systems. Just understanding the solution of a few problems in depth, and knowing from that how hard simple things really are, is incredibly valuable. Without that background, people can naively tackle extremely complex problems, bash their heads against them for years, and still underestimate the difficulty of the problems they've created for themselves by orders of magnitude.

In general, the rigor of doing theoretical problems, the discipline of actually proving things, creates habits that uncover lots of non-happy path possibilities.

Re: A computer science study plan to become a software engineer

#96
post #57

The most important thing on your path to becoming a software engineer is building stuff, improving it, releasing it, and thinking how you can do it better. Having been through the lifecycle of a piece of software from design to maintenance will also provide a wealth of experience. I understand that it's popular to let people solve toy problems during interviews, and think that's ok for people coming out of university…

I strongly agree with this point. Most of day-to-day problems in software engineering / craftsmanship (i.e. the work most people are paid for in this industry) are not computer science problems, they are about the process of understanding your user requirements, iteratively improving your product, achieving and maintaining the appropriate level of quality, and the meta-cognitive skills around identifying when you just need need to fix a bug vs. step back and look for a way to improve your tools.

You will get some transitive learning of some of these things if you do lots of coding challenges, but I personally found a huge benefit in my formative years from building a single full-stack application over many months, much more than solving simpler day- or week-long standalone tasks.

Re: A computer science study plan to become a software engineer

#97
post #41
post #35

Earlier quoted context omitted.

Your comment reflects a common meme that can often be summarized as: "Real World" work doesn't involve the academic nonsense you learn in school. Many of the people who say this kind of stuff never really mastered the theory, and because they never mastered it they can't really use it, and because they can't really use it they find work that doesn't strictly require it, and then conclude it's useless... It's like whe…

Can you give some examples of where computer science academic theory helped in software engineering?

- For parsing, the difference between context free languages and regular languages. This has helped in a number of projects (usually at the clean up end).

- Boolean algebra has helped me greatly simplify hard to understand nested conditionals.

- Understanding data structures lets me pick the right ones for the problem.

- Algorithm analysis has let me take program runtimes from minutes or hours on modest data sets down to seconds or minutes.

- Discrete math topics helped me prove a problem that a coworker had spent a few weeks on was technically impossible.

- Again for parsing, understanding the ideas of parsing let me make a number of parsers over the years using a variety of mechanisms. The critical part, though, was understanding what was being parsed and how to parse so the code was clear. I replaced convoluted code with hardcoded values and assumptions about what would be in each part (line, or binary blob) with something more flexible and less hacky.

- Knowing how C stores data (stack versus heap) let me fix a lot of code from some engineer colleagues that would work, sometimes, but not reliably because they didn't understand how memory works.

Re: A computer science study plan to become a software engineer

#98
post #35

This isn't a bad list of topics about data structures, algorithms, and software fundamentals, but let's not pretend that computer science has anything to do with most software engineering roles. I studied computer science, and in 30 years, I've hardly used any of it. There were a few jobs where some of the statistics and math were helpful, but in my long career, I've seen very little overlap between computer science…

Your comment reflects a common meme that can often be summarized as: "Real World" work doesn't involve the academic nonsense you learn in school. Many of the people who say this kind of stuff never really mastered the theory, and because they never mastered it they can't really use it, and because they can't really use it they find work that doesn't strictly require it, and then conclude it's useless... It's like whe…

"Many of the people who say this kind of stuff never really mastered the theory, and because they never mastered it they can't really use it, and because they can't really use it they find work that doesn't strictly require it, and then conclude it's useless..."

this is quite the assertion. do you have any evidence supporting this statement?

Re: A computer science study plan to become a software engineer

#99
This sort of stuff is meant to leave the anarchists and the rule benders out of the company.

Its requires certain psychological threats to by guided to memorize and do all this stuff.

I bet a lot of people with the actual right skills would not pass into those exams.

It reminds me if a great lesson from the prince from Maquiavel, where he speaks about what sort of soldiers should be used and say that the mercenary soldiers should be the last resort, because giving they do not really believe into what they are doing, in the battle field they wont make the best soldiers.

Well, the filtering here will optimize for people willing to force themselves into this for a good salary, of course they can by chance get the passionate type, but they are not optimizing for it, and that's the point.

I rather work with people that are passionate about it, they are the ones that do the "impossible" things because they dont just do what they are told.

And this kind of people will at a certain point in their lives have nothing to show. But the curious, the creative, the people that learn fast, that are always hungry how can a company get them through this?

Re: A computer science study plan to become a software engineer

#100
post #90

Earlier quoted context omitted.

All this is true, but when I look at undergrad curricula for other engineering disciplines I don't see this stuff either. And the software engineering courses I did have in undergrad were terrible .

Software engineering needs to be learned on the job. I see lots of new grads that take classes in "Agile" and I cringe just knowing how instead they could be taking difficult courses in graph theory, theory of computation, abstract algebra, advanced algorithms, distributed systems, or any other number of advanced topics. As we get older it's easier to pick up tricks of the trade (various Git workflows, "agile", etc).…

> but it gets harder to sit down to do 3 hours of homework 4 days a week doing your pushdown automata or linear algebra exercises.

38 year old studying astrodynamics for work. Can attest to the difficulty of this. No kids yet, that helps, but the wife and I are planning on starting a family soon so it'll get even harder with increased demands on my time.

Post reply on HN