7 ms·

> They also always had humorous holes in their knowledge (which they were always quick to rectify). Can you elaborate on some of these areas? Were there common

by keyanp 6y ago

> They also always had humorous holes in their knowledge (which they were always quick to rectify). Can you elaborate on some of these areas? Were there common patterns you have seen? Asking as a mostly self-taught engineer always looking to uncover unknown unknowns in my knowledge.

jedberg 6y ago
There was never a pattern but it was usually something that you would learn in an upper division algorithms course that doesn't come up often in practical applications, like Big O notation or Bloom Filters or Depth First Search. Oftentimes they would know the topic intrinsically (like a search algorithm) but not know it's name or the typical use cases. But like I said, usually by the next day they would be an expert.
- tenaciousDaniel 6y ago
  ^ as a self-taught dev, this is accurate. I still don't really know Big-O notation or Bloom Filters. But it's never come up as an issue.
  - jedberg 6y ago
    I've found that Big-O comes up any time you're wracking your brain trying to figure out why something is taking so long, and then you realize you've created something n squared with some nested loops. And bloom filters are super cool, you should read up on them. You'll find an interesting set of problems that can be solved with them. The key to remember is that if you ask a bloom filter if something is in the set, and it says no, you are guaranteed that the answer is correct, and if it says yes, it may be there, but it's super fast at giving a no answer. So if you expect that the answer will be no most of the time, a bloom filter may be a good data structure. Here is one place it comes up: on reddit (or HN) when you load a page it shows you all the stuff you've already voted on. There are usually many things you could have voted on, and chances are you haven't voted on a lot of them. So when you ask "did user X vote on item Y", the answer is usually no. Storing the votes in Cassandra, which uses a bloom filter, makes answering that query super fast.
    - saagarjha 6y ago
      Of course, it's important to note that bloom filters by themselves can give false positives.
      - jedberg 6y ago
        Right, I said that. I said that it may return yes when it isn't in the set. But it never gives a false negative, which is key.
- realtalk_sp 6y ago
  You think not knowing about Bloom Filters is a 'humorous gap in knowledge'? Are you saying you worked some place that expected people to know about them and also hired self-taught engineers? I've worked at some companies people here think of as 'elite' and I can't even begin to imagine how this might occur. In fact, it smells to me a lot like the mentality of certain people at said companies who liked hazing interviewees by testing esoteric knowledge (e.g. twisted DP problems, reservoir sampling) instead of talent and potential. A part of me would have loved to see those companies implement a policy of using those interview questions on other employees, like a kind of 'random drug testing'. I imagine many would have been humbled rather quickly by such a process.
  - jedberg 6y ago
    The bloom filter one wasn't really one of the humorous ones. More like not knowing the name "Big O notation" despite understanding the concept. It was humorous that in all that time they never heard the term "Big O" even when using the concepts.
- deleted 6y ago
  [deleted]
soneca 6y ago
Some of mine humorous holes that I learned after getting a job: - I didn't know any Git command - I was very uncomfortable working on a terminal actually (I remembering googling what a "terminal" was at the beginning of my studies, by the time I got my first job, I was only capable of following step-by-step tutorials for anything CLI related) - I had no idea what "cURL" meant, a senior dev told me to send him the "cURL", saying that just had to "copy as cURL in the devtools" and I had no idea what to do it. When he got to my desk I was googling it. He was nice enough to have a discreet smile and teach what I had to do. - Btw, I was completely unaware what I could do with Chrome devtools too. About as uncomfortable as with CLI These are just the ones that I actually noticed and remember now, for sure there are others that I never noticed or forgot.
- jerf 6y ago
  I wouldn't expect a fresh CS grad to know any of those things. I personally wouldn't have immediately gotten "send me the cURL" if that was said to me personally, though I know the menu option in question. (It would help if it was a more distinctive word.) Don't overestimate the average fresh CS grad.
- joefourier 6y ago
  Funnily enough those sound exactly like the holes in knowledge in some formally educated software engineers I know. Unis generally teach you computer science concepts and algorithms, and not tools like Git, cURL, and especially not Chrome devtools. While using they may introduce students to command-line interfaces you're much more likely to become comfortable with it through personal projects than academic lessons.
- searchableguy 6y ago
  Hm unless you weren't doing web dev before. Those seem like pretty normal things you would encounter daily for any moderately complex project. I was expecting more HN like answer like the big O notation, data structures and design, algorithms related stuff since those are the holes you should find in someone without academic background as most web tutorials never go into that and neither the bootcamp courses though I have seen a few that do. Something like, the guy didn't even know his code was O(n^2) or couldn't even implement dijkstra. Your experience speaks more of academic settings than bootcamps. Just an observation.
hoorayimhelping 6y ago
For junior engineers, it's mostly contextual. How to act on a team. How to communicate with engineers and non engineers alike. What your personal coding style is. What you value as an engineer. How to take and give criticism. How to use common tools like git, a debugger, browser dev tools, etc. A big one: that it's usually a really good idea to say, "I don't know what that means." Being honest when you don't know what someone is talking about is probably the single biggest 'hack' a junior engineer can do to level up faster (provided they have a supportive team). A lot of junior engineers don't know what someone is telling them and end up burning a lot of time googling what could be taught in a few seconds. Any decent senior engineer will understand that you don't know very much and you're going to need to be taught. Exceptional engineers will be able to read you and see that you're confused and help you, but you can't count on having one of those on your team, so you'll have to let them know when you don't understand things. For more experienced engineers without formal training, by and large the biggest way I've seen they can level up is learning about data structures and algorithms and how the two concepts play with one another. We mostly deal with arrays and hashes in our day to day, but understanding graphs, stacks, queues, linked lists and being aware of more exotic but usable data structures like tries and bloom filters (for example) is a great way to round out your coding skills. Understanding the read and write time of certain data structures and the algorithms that go with them and how you can sometimes trade space for runtime efficiency (e.g. copy your array into a hash/dict/object that is keyed on what you're checking on for fast look ups in a loop) or vice versa will help you write better, more performant code with intent. Another big sleeper skill you can fill in is learning programming language design. It was a really tedious subject in school that I hated, but studying programming languages and how you take a C expression and turn it into an instruction the computer could understand introduced me to a ton of concepts. I don't necessarily directly use them regularly, but they inform my development style - tokenizing, grammars, context, tail recursion, scoping, etc. I'm really glad I spent the time to learn that subject, even though it was really hard at the time. The other thing I had the benefit of was a formal math education. I don't necessarily use calculus every day, but understanding the idea of a derivative or an integral is very useful in software engineering. A graph of metrics for instance - taking the derivative of a graph that changes frequently will tell you the rate of change - understanding how this works and why it's important helps you make smart decisions, and also gives you a seat at the table when you get into the upper levels of engineering.

by keyanp 6y ago

jedberg 6y ago

There was never a pattern but it was usually something that you would learn in an upper division algorithms course that doesn't come up often in practical applications, like Big O notation or Bloom Filters or Depth First Search. Oftentimes they would know the topic intrinsically (like a search algorithm) but not know it's name or the typical use cases. But like I said, usually by the next day they would be an expert.

tenaciousDaniel 6y ago
^ as a self-taught dev, this is accurate. I still don't really know Big-O notation or Bloom Filters. But it's never come up as an issue.
- jedberg 6y ago
  I've found that Big-O comes up any time you're wracking your brain trying to figure out why something is taking so long, and then you realize you've created something n squared with some nested loops. And bloom filters are super cool, you should read up on them. You'll find an interesting set of problems that can be solved with them. The key to remember is that if you ask a bloom filter if something is in the set, and it says no, you are guaranteed that the answer is correct, and if it says yes, it may be there, but it's super fast at giving a no answer. So if you expect that the answer will be no most of the time, a bloom filter may be a good data structure. Here is one place it comes up: on reddit (or HN) when you load a page it shows you all the stuff you've already voted on. There are usually many things you could have voted on, and chances are you haven't voted on a lot of them. So when you ask "did user X vote on item Y", the answer is usually no. Storing the votes in Cassandra, which uses a bloom filter, makes answering that query super fast.
  - saagarjha 6y ago
    Of course, it's important to note that bloom filters by themselves can give false positives.
    - jedberg 6y ago
      Right, I said that. I said that it may return yes when it isn't in the set. But it never gives a false negative, which is key.
realtalk_sp 6y ago
You think not knowing about Bloom Filters is a 'humorous gap in knowledge'? Are you saying you worked some place that expected people to know about them and also hired self-taught engineers? I've worked at some companies people here think of as 'elite' and I can't even begin to imagine how this might occur. In fact, it smells to me a lot like the mentality of certain people at said companies who liked hazing interviewees by testing esoteric knowledge (e.g. twisted DP problems, reservoir sampling) instead of talent and potential. A part of me would have loved to see those companies implement a policy of using those interview questions on other employees, like a kind of 'random drug testing'. I imagine many would have been humbled rather quickly by such a process.
- jedberg 6y ago
  The bloom filter one wasn't really one of the humorous ones. More like not knowing the name "Big O notation" despite understanding the concept. It was humorous that in all that time they never heard the term "Big O" even when using the concepts.
deleted 6y ago
[deleted]

soneca 6y ago

Some of mine humorous holes that I learned after getting a job: - I didn't know any Git command - I was very uncomfortable working on a terminal actually (I remembering googling what a "terminal" was at the beginning of my studies, by the time I got my first job, I was only capable of following step-by-step tutorials for anything CLI related) - I had no idea what "cURL" meant, a senior dev told me to send him the "cURL", saying that just had to "copy as cURL in the devtools" and I had no idea what to do it. When he got to my desk I was googling it. He was nice enough to have a discreet smile and teach what I had to do. - Btw, I was completely unaware what I could do with Chrome devtools too. About as uncomfortable as with CLI These are just the ones that I actually noticed and remember now, for sure there are others that I never noticed or forgot.

jerf 6y ago
I wouldn't expect a fresh CS grad to know any of those things. I personally wouldn't have immediately gotten "send me the cURL" if that was said to me personally, though I know the menu option in question. (It would help if it was a more distinctive word.) Don't overestimate the average fresh CS grad.
joefourier 6y ago
Funnily enough those sound exactly like the holes in knowledge in some formally educated software engineers I know. Unis generally teach you computer science concepts and algorithms, and not tools like Git, cURL, and especially not Chrome devtools. While using they may introduce students to command-line interfaces you're much more likely to become comfortable with it through personal projects than academic lessons.
searchableguy 6y ago
Hm unless you weren't doing web dev before. Those seem like pretty normal things you would encounter daily for any moderately complex project. I was expecting more HN like answer like the big O notation, data structures and design, algorithms related stuff since those are the holes you should find in someone without academic background as most web tutorials never go into that and neither the bootcamp courses though I have seen a few that do. Something like, the guy didn't even know his code was O(n^2) or couldn't even implement dijkstra. Your experience speaks more of academic settings than bootcamps. Just an observation.

hoorayimhelping 6y ago

For junior engineers, it's mostly contextual. How to act on a team. How to communicate with engineers and non engineers alike. What your personal coding style is. What you value as an engineer. How to take and give criticism. How to use common tools like git, a debugger, browser dev tools, etc. A big one: that it's usually a really good idea to say, "I don't know what that means." Being honest when you don't know what someone is talking about is probably the single biggest 'hack' a junior engineer can do to level up faster (provided they have a supportive team). A lot of junior engineers don't know what someone is telling them and end up burning a lot of time googling what could be taught in a few seconds. Any decent senior engineer will understand that you don't know very much and you're going to need to be taught. Exceptional engineers will be able to read you and see that you're confused and help you, but you can't count on having one of those on your team, so you'll have to let them know when you don't understand things. For more experienced engineers without formal training, by and large the biggest way I've seen they can level up is learning about data structures and algorithms and how the two concepts play with one another. We mostly deal with arrays and hashes in our day to day, but understanding graphs, stacks, queues, linked lists and being aware of more exotic but usable data structures like tries and bloom filters (for example) is a great way to round out your coding skills. Understanding the read and write time of certain data structures and the algorithms that go with them and how you can sometimes trade space for runtime efficiency (e.g. copy your array into a hash/dict/object that is keyed on what you're checking on for fast look ups in a loop) or vice versa will help you write better, more performant code with intent. Another big sleeper skill you can fill in is learning programming language design. It was a really tedious subject in school that I hated, but studying programming languages and how you take a C expression and turn it into an instruction the computer could understand introduced me to a ton of concepts. I don't necessarily directly use them regularly, but they inform my development style - tokenizing, grammars, context, tail recursion, scoping, etc. I'm really glad I spent the time to learn that subject, even though it was really hard at the time. The other thing I had the benefit of was a formal math education. I don't necessarily use calculus every day, but understanding the idea of a derivative or an integral is very useful in software engineering. A graph of metrics for instance - taking the derivative of a graph that changes frequently will tell you the rate of change - understanding how this works and why it's important helps you make smart decisions, and also gives you a seat at the table when you get into the upper levels of engineering.