I recommend every software engineer download/purchase Dash ( https://kapeli.com/dash ). It’s worth more than whatever that I paid for it (probably like $50, I think). That app is a lifesaver; especially when I’m offline for a bit and trying to work
Everything I googled in a week as a professional software engineer
171–180 of 399 posts
Re: Everything I googled in a week as a professional software engineer
#172Earlier 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)
Not necessarily. The purpose is to show how you reason your way through a problem where you can't simply google "how do I solve x problem." It's intended to see how you communicate, how you handle mistakes, how thorough you are in double-checking yourself, your work style (do you jump right in or ask lots of questions first), etc. In any case, there's a lot of strategies to show that you understand a concept without…
I totally understand your philosophy and you make some great suggestions, but overall there's one big flaw with whiteboard interviews: Artificial Pressure and its impact on people's ability to think clearly on the spot. I am a very methodical thinker which is why I tend to prefer work in large scale ore high-performance systems where you consider the implications of thread contention and so forth. I've designed and built multiple large scale production systems and i've also simultaneously forgotten whether it should be += or =+ during a whiteboard interview because of a phenomenon I can't quite describe. Obviously I was laughed at for someone who's actually had 10 years experience with c++ to forget something so basic but it happens when you are on the spot.
The biggest problem with whiteboards is that they reward exactly what they say they try to weed out, rote memorization. It's no secret you could spend weeks practicing on leetcode for an interview but those skills simply don't translate to real-world programming. Algorithm design is maybe 2% of software engineering. The vast majority is knowing what pieces of technology are out there in order to avoid reinventing the wheel all the time. Whiteboards don't test that skill. It tests a marathon runner on their 100 meter dash time.
Re: Everything I googled in a week as a professional software engineer
#173This 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…
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)
I let candidates use their phone to Google or ask me to Google on their behalf. What they're Googling for never matters in the context of the interview and it's mostly to make them feel more comfortable.
It's a whiteboard, I'm looking out for far more important things than whether the method is named `size` or `length`.
Re: Everything I googled in a week as a professional software engineer
#174On the list of things I always Google, is how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first; the source or the destination. The man pages add to the confusion by calling the "source" the target. So, the rule of thumb I now follow is cp or mv semantics.
ln -s actual link
Read it somewhere long time ago, never had to look for it again :)
Re: Everything I googled in a week as a professional software engineer
#175Earlier 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?
They are hiring a bunch of people who have a serious disdain for the way they are interviewed. A better question might be, "who are these companies putting in charge of their interview process?". I think the answer there is largely, "people who have a serious disdain for this kind of interview, but still need to interview people and don't have any better ideas for how to do it".
Re: Everything I googled in a week as a professional software engineer
#176This 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…
> 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?
Ha, yeah, I might say something similar, except that I would say, "mostly just arrays and maps".
Re: Everything I googled in a week as a professional software engineer
#177Earlier quoted context omitted.
Not necessarily. The purpose is to show how you reason your way through a problem where you can't simply google "how do I solve x problem." It's intended to see how you communicate, how you handle mistakes, how thorough you are in double-checking yourself, your work style (do you jump right in or ask lots of questions first), etc. In any case, there's a lot of strategies to show that you understand a concept without…
I totally understand your philosophy and you make some great suggestions, but overall there's one big flaw with whiteboard interviews: Artificial Pressure and its impact on people's ability to think clearly on the spot. I am a very methodical thinker which is why I tend to prefer work in large scale ore high-performance systems where you consider the implications of thread contention and so forth. I've designed and b…
> Obviously I was laughed at for someone who's actually had 10 years experience with c++ to forget something so basic but it happens when you are on the spot.
This 100% happened to me (apart from being laughed at) only it was even more of a meltdown. Also 10 years experience and a problem I could do in my sleep. It was my first interview after a long time and it triggered performance anxiety and nervousness.
The solution is you need to practice live interviews, not just leetcode solo.
Re: Everything I googled in a week as a professional software engineer
#178Earlier quoted context omitted.
Fred Brooks said this back in 1975. He called it a surgical team. Of course, no manager reads The Mythical Man Month, and those that do don’t follow it.
Correct me if I am wrong but isn't the central premise of the book that if you take a late project and add more people to the team it takes the project longer??? I've literally never met a manager that practiced this. Is the book still relevant? Not disagreeing, just curious.
> I've literally never met a manager that practiced this.
Yeah it's a pretty universal idea.
> Is the book still relevant?
Yes, precisely because that idea is so universal. Its advice has been relevant, insightful, and mostly ignored ever since it was written.
Re: Everything I googled in a week as a professional software engineer
#179Earlier quoted context omitted.
Not necessarily. The purpose is to show how you reason your way through a problem where you can't simply google "how do I solve x problem." It's intended to see how you communicate, how you handle mistakes, how thorough you are in double-checking yourself, your work style (do you jump right in or ask lots of questions first), etc. In any case, there's a lot of strategies to show that you understand a concept without…
I totally understand your philosophy and you make some great suggestions, but overall there's one big flaw with whiteboard interviews: Artificial Pressure and its impact on people's ability to think clearly on the spot. I am a very methodical thinker which is why I tend to prefer work in large scale ore high-performance systems where you consider the implications of thread contention and so forth. I've designed and b…
Whiteboard interviews exist because without them companies wouldn't have a metric to artificially restrict hiring. Passing a whiteboard interview makes both the company and interviewee feel special and maintains the bubble of software engineering salaries.
Re: Everything I googled in a week as a professional software engineer
#180This is probably a 10-50x fewer searches than I do in a week. I am assuming there are many searches left out. I'd be interested in seeing how the OP tweaks their searches as the results don't return exactly what they want. Here is an actual single search progression for me (In reverse order because copy/pasta :shrug: react context optimize rerender "props.children" react context optimize rerender react usereducer dis…
could you give an example of a complex search? I've never bothered using advanced Google search patterns
`site:stackoverflow.com ruby hash dig` would be an example
Edit: also `site:stackoverflow.com ruby "Hash#dig"` if you wanted an exact match, etc..