Seems totally reasonable.
“cors - today is going to be bleak” as the first search of the day resonates with me on a deep level. Our field is incredibly complex, and some parts of it we just like to not think about too much.
Everything I googled in a week as a professional software engineer
231–240 of 399 posts
Re: Everything I googled in a week as a professional software engineer
#232My first three of the day:
"caniuse position sticky"
"ERR_SSL_PROTOCOL_ERROR angular ng serve"
"hash bitbucket reference jira"
And I've been at this for decades! I remember the bad old days of reference manuals. This is a walk in the park!
Re: Everything I googled in a week as a professional software engineer
#233This is great but the premise seems kind of straw man. I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” Perhaps this is a reference to the interviewing process. Tests are a different thing, though. I’ve been on practical technical screens where you can google, because the test was about building a larger system, and they don’t care if you don’t remember this or that API…
Googling too much is an indicator that your environment or process isn't working well. It's not a point of pride if half your job requires looking up how to use tools you don't understand. The problem is that people naturally blame themselves for not knowing everything rather than accepting that we have built monuments of trash code that nobody should be expected to understand and that therefore we should stop doing…
Ideally, I would sit down and be so familiar to the problems I'm solving, the tools I'm solving them with, and the tools so suited to solving those tasks that I can just type in my solution without having to stop to consult something on the internet.
Ideally, I'd be able to have tasks that are highly specified in advance and with priorities that are stable enough that I do not have to have multiple social interruptions per day in order to be on the correct task.
Basically, I wish I could achieve productive software development from an isolated cabin without an internet connection to provide distractions, with lots of subtle natural ambiance and my own thoughts instead of interruptive social interactions, and synchronize my work product with society on the same cadence with which I would travel to town to get groceries.
Obviously, this is not the situation.
Re: Everything I googled in a week as a professional software engineer
#234Earlier quoted context omitted.
Ok.. Find all the words that match a search string prefix. I.e. you have a search field and want to show the possible matches as you type. With each new char you’re calling this search and getting back a list of words. The dictionary is in memory in whatever data structure you choose. You only have to return matches if the search is 3 or more chars long. Now, how does your implementation scale when the dictionary has…
FWIW, even highly accomplished software developers / hackers like Jonathan Blow[1] have said that in almost every case, you should just use an array as your data structure (or some variation of an array), unless you actually have a good reason not to (that will get you a lot of value) Of course that doesn't mean you shouldn't know how advanced data structures work and be able to work with them, it just means you shou…
> Of course that doesn't mean you shouldn't know how advanced data structures work and be able to work with them..
We don't disagree. Understanding data structures is about reaching for the right tool, and very often the hammer of an array/map is the right tool. But the problem I gave isn't that exotic. It's a case where "reaching for an array" is a brute force solution that won't scale.
So how do you separate candidates who understand those limitations from those that don't? By asking about those cases. They're not that common, but that doesn't mean they never come up or you won't get a nasty bug if you don't understand these foundations.
Re: Everything I googled in a week as a professional software engineer
#235I don't like the Cors solution
Re: Everything I googled in a week as a professional software engineer
#236Earlier quoted context omitted.
FWIW, even highly accomplished software developers / hackers like Jonathan Blow[1] have said that in almost every case, you should just use an array as your data structure (or some variation of an array), unless you actually have a good reason not to (that will get you a lot of value) Of course that doesn't mean you shouldn't know how advanced data structures work and be able to work with them, it just means you shou…
> Of course that doesn't mean you shouldn't know how advanced data structures work and be able to work with them.. We don't disagree. Understanding data structures is about reaching for the right tool, and very often the hammer of an array/map is the right tool. But the problem I gave isn't that exotic. It's a case where "reaching for an array" is a brute force solution that won't scale. So how do you separate candid…
I would start by asking the question without mentioning scaling at all, and see how they respond.
If they immediately jump to using a fancy data structure like a suffix array, but they don't ask any questions about how critical performance and scaling are, then it shows they know a lot of stuff about CS, but they may be lacking in more practical experience.
If they tell you they would just use an array or a map (which would be extremely inefficient with large amounts of data), then you ask a follow-up question about scaling, and see how they respond. If they can't answer that question, then they lack practical experience and fundamental knowledge of advanced data structures.
Do you agree with that approach?
Re: Everything I googled in a week as a professional software engineer
#237Earlier quoted context omitted.
Isn't that what a whiteboard interview is? Proving you can do things without google or else you aren't a proper engineer? (For the record I disdain whiteboard interviews as the accepted metric for testing one's ability)
Every engineer on HN (several threads that I've browsed) seems to have a serious disdain for coder-pad interviews/whiteboard sessions. And I think HN has a good representation of software engineers. So, who are these companies hiring?
A couple personal observations here.
I think there's a serious disdain for interviewing in general. The whole process sucks from end to end. Often it's because the interviewers just aren't good at it. But when it comes down to whiteboard interviewing, I think it's about your value system.
More specifically, I think every interviewer has an opinion on the practical theoretical spectrum, and the problem is when the candidate disagrees with the interviewer's opinion on where on the spectrum the interview should be.
The upside of a practical interview is that you are testing whether they can do the work. The downside of a practical interview is that it indexes heavily on experience and lightly on the ability to cross disciplines. Theoretical interviews are the reverse.
So the important question is: what does your team care about? Google will care much more about the ability for their engineers to move around than your startup will. In general large companies will care much more about portability. They have deeper pockets and are therefore more willing to train you on the job, so generally speaking if they think you can ramp up (even for senior hires), they're happy. As much as startups will say they see things this way, it's not really true. Startups in general care that their senior hires come with substantial domain expertise.
Re: Everything I googled in a week as a professional software engineer
#238Earlier quoted context omitted.
> But having a deep understanding of data structures (not just arrays and maps) and algorithms really gives you a mastery of your craft, especially around performance and scalability. Can you give an example?
Ok.. Find all the words that match a search string prefix. I.e. you have a search field and want to show the possible matches as you type. With each new char you’re calling this search and getting back a list of words. The dictionary is in memory in whatever data structure you choose. You only have to return matches if the search is 3 or more chars long. Now, how does your implementation scale when the dictionary has…
Outside of special cases you would be doing lookup in some data store so this has fairly minimal chance of mattering in a real world project.
Re: Everything I googled in a week as a professional software engineer
#239Earlier quoted context omitted.
Googling too much is an indicator that your environment or process isn't working well. It's not a point of pride if half your job requires looking up how to use tools you don't understand. The problem is that people naturally blame themselves for not knowing everything rather than accepting that we have built monuments of trash code that nobody should be expected to understand and that therefore we should stop doing…
I think compounding the issue is a lot of devs jump complex technologies pretty quickly so we're constantly trying to overcome a deficit in knowledge but never stopping long enough to do so.
Agreed. When we recognize this, we often jump to a new shiny tech rather than stop, remove complexity from the environment, and regroup, as we should.
Re: Everything I googled in a week as a professional software engineer
#240Earlier quoted context omitted.
I'm of the opinion that not googling stuff means you're not a proper engineer. And from what I've seen, those who don't google consistently also fail to understand the answers they find when they do google things. It is, in fact, an essential skill.
I’ve asked pre-internet programmers and they said they used to keep reference books at their desk or even a small library/book room at their employers. I’ve heard some government contractors can’t google because they work on non-internet connected computers. They probably keep a lot of books.
I worked for a few months without an internet connection, I'd go to public wifi spots and load up on all the documentation and packages I needed. I wouldn't recommend it but it definitely teaches you to be resourceful.