151–160 of 181 posts
This may not be an option for startups but, then, maybe startups should focus on hiring more experienced professionals who can, with time, bring freshly graduated engineers up to speed, as well as helping design systems and processes tailored for the company and product.
I think that at an even more basic level than hard skills, some graduates lack knowledge in things like basic problem solving, abstract thinking or the ability to switch between languages quickly. It's interesting to see how straight-A students who study well and test well don't make the transition from the academic environment to a job.
I have a pet theory about this. Your whole life has goal posts laid out for you. You go to elementary school, get good grades so you can get into honors classes in middle/high school. And you do this again for college. Everything is quantitatively measured. How many questions did you get right? How many days did you attend school? How many extracurricular activities did you participate in? How many hours did you volu…
I'd love to see a curriculum where there is a class each semester that is 100% project based, where the end result isn't as important as the process.
Earlier quoted context omitted.
... Or if they start looking for a new job within a few weeks of starting (the idea of getting 3-4 jobs in the first 2-3 years with increased compensation each step). After getting a few hires that only stay for 6-12 months, its a question of "is it worth it to put in the time to mentor them if they're going to be gone shortly afterwards?"
> ... Or if they start looking for a new job within a few weeks of starting (the idea of getting 3-4 jobs in the first 2-3 years with increased compensation each step). This is half tragedy of the commons of so few companies offering training and half companies being so god awful at offering raises as employees gain experience.
Earlier quoted context omitted.
The questions FAANG ask should not be the questions a startup asks... FAANG have to deal with measuring candidates at huge scale, and have literally too much talent coming through the door. A hiring decision in a startup can be a series of life or death decisions. I think algorithms questions are an OK litmus test for being able to program, but it shouldn't be everything or even 1/4 of an interview at a small company…
maybe startups should focus on filtering for any reasonably competent person who will actually stick around until the company succeeds or dies
Earlier quoted context omitted.
Candidly, I would say that college does not even provide the base skill-set. In the Real World(tm) of building software, you will work on systems built over years by other people, many of which have long since left the project or company. The level of integration tests, unit tests, documentation, and automation will depend entirely on the culture of the organization. Databases, low-level I/O, sorting operations, and…
Maybe make them work on open source projects? Or even the college's own toy systems?
The key difference between university and work is that in the former you are supposed to receive a pretty fine-grained assessment of your own skill, which is isolated and repeatable. In work, it's understood that promotion and slotting is a much more arbitrary affair and the marking criteria may not even be documented, let alone applied consistently. Also if your project fails because of bad work done by others, well, tough luck, that's what your salary is for. In university you're paying to be there, not the other way around, so the amount of random failure tolerable is much lower.
/edit
What I'm wondering is: doesn't university prove that one is capable of learning programming/computer-related topics?
The hardest things I've learned about were:
- rowhammer/cache sidechannel attacks via the GPU with C and then porting that to Javascript and do it over the web
- creating a computer graphics engine from scratch (I did this in Java which made it easier)
- reproducing a simplified version of Kevin Mitnick's attack on the Boston super computer (? not sure, memory is vague) with C, libpcap, tcpdump and other tools/libs
- being passable at reading x86/x64 assembly and understanding how a computer is built from the architectural level to a modern programming language, playing around with creating an MUL instruction for a toy ISA
- compilers and reading a toy ISA to then be able to read the toy machine code made for it
Is this practical? No.
Is this a lot harder than creating a new web app for a startup just starting out? Yes, if you know a programming language or two, then it's easy to hack things with JS together and also fairly easy to get up to snuff with ReactJS and ES since it's mostly syntax features.
I don't have experience working with legacy systems or 1 million users large scale systems, so I can't comment on whether that's more difficult. However, since this article is about startups. I've worked for startups that existed 2+ years, and becoming productive on the job didn't take me long and I'm not an amazing programmer by any means.
My bachelor though, yea, that was a lot worse. My master in CS saved me by following security courses where the professors expected you to learn almost anything on your own.
Earlier quoted context omitted.
Not if you have to pay them a 150k starting salary!
... Or if they start looking for a new job within a few weeks of starting (the idea of getting 3-4 jobs in the first 2-3 years with increased compensation each step). After getting a few hires that only stay for 6-12 months, its a question of "is it worth it to put in the time to mentor them if they're going to be gone shortly afterwards?"
Earlier quoted context omitted.
Conversely, too much practical experience can lead to a lack of fundamental understanding, innovation, and helplessness. I can’t stand it when an engineer wastes hours looking for a library, instead of even considering actually writing code themselves. Many just can’t because they’re so accustomed to glueing together other people’s code. Of course, I’ve worked with academic types that can never stop theorizing and ac…
I often see the opposite: people wasting hours writing code when they could have found the appropriate library with a few minutes of searching. Often the library is actually already installed with the project or even part of the standard library.
Earlier quoted context omitted.
Conversely, too much practical experience can lead to a lack of fundamental understanding, innovation, and helplessness. I can’t stand it when an engineer wastes hours looking for a library, instead of even considering actually writing code themselves. Many just can’t because they’re so accustomed to glueing together other people’s code. Of course, I’ve worked with academic types that can never stop theorizing and ac…
> too much practical experience can lead to a lack of fundamental understanding That's too little theoretical background, not too much practical experience. If you take someone with a good grasp of the basics, you will never remove that grasp by giving them more practical experience.
1. "They [start-ups and next-gen tech companies] want grads who can build scalable systems and program for large-scale, distributed, data-intensive systems that leverage cloud computing." - For start-ups, this is only true if your startup is in that space. Most "start-ups" are trying to find product market fit, and the systems are generally not large scale as a result.
2. "Engineers at established companies mostly work within their specialty areas." - While there's some truth to this, I think it's overstated. In the start-ups I worked with, "engineers" did not do market research. I worked with plenty of specialists at start-ups that worked with language X, but if you asked them to debug an issue in language Y, they'd refuse. In some cases, it can be the opposite of what this article states - engineers at a start-up can often focus on hands-on engineering tasks, whereas in a large company I find a larger portion of my time is around writing documents to align more people around an idea.
3. "The timing of the product release is crucial because it has a direct impact on acquiring customers and affects the bottom line. Significant delays can put a company out of business." - In a large company, you won't go out of business if your release is late, but it could mean that your product gets de-funded. While the change to the company might not be so much, a project getting de-funded certainly affects the daily lives of those involved. So I think this difference is overstated.
4. "Engineers for startups are more likely to play a significant role in defining the system architecture" - My experience is that this depends a lot on the start-up and the seniority of the engineer in question.