Hacker Newsnew | past | comments | ask | show | jobs | submit | more yoshicoder's commentslogin

I got nerd sniped by this question, and I think I have a closed form formula. Obviously it needs a summation since the order/placement of the numbers matters.

The formula is 2^(# of questions - # terminating questions) + SUM[2^(terminiating question number - idx in terminating question list] where the SUM is over all the terms in the list given as input to the question_paths function

for example: we take the example of question_paths(10,[1,5]), where the answer is 274. From the formula, we take 2^(10-2) + 2^(1-0) + 2^(5-1) which equals 274.

similarly for question_paths(10,[6,8]), where the answer is 448. From the formula, we take 2^(10-2) + 2^(6-0) + 2^(8-1) which equals 448.


I wrote some python code which should give the right answer

  def formula(total_qs, terminating):
    total = 1 << (total_qs - len(terminating))
    for i, num in enumerate(terminating):
        total += 1 << (num - i)
    return total

  print(formula(10, [1, 5]))```


honestly, I see this as a sign of Google bureaucracy/cost-cutting taking over the company's culture. Considering how much innovation in tech is happening right now, blowing cash on a dividend rather than internal projects that could make big returns seems like its completed its journey to becoming the next IBM


Having talked to many friends at Dell (interns and full time), I have a few observations about this:

1. I know many people on HN hate the idea of RTO, and for good reasons, but one downside I saw of remote was that junior engineers struggled to get mentorship and guidance as well as an in person setting. A lot of the learning junior engineers get is through water cooler talk, informal suggestions, and off the cuff comments, rather than stuff brought up in stand-ups or asynchronous slack messaging

2. Dell already seems to have a culture of trying to avoid promoting junior engineers quickly/for multiple years, through avenues such as the rotation program which ensure you don't get promoted for at least 2 years.


I have zero trouble mentoring juniors remotely. These are kids who grew up playing videogames online and it's extremely easy to mentor them via regular teams call. Being unable to do so is a skill issue the part of senior devs to properly leverage modern collaboration tools.


> via regular teams call

I actually find that mentorship happens best in irregular interactions, as the help is needed.

Secondarily, I find that personal connection/rapport is invaluable in delivering feedback, and is possible but more difficult to do via screens.


Then they or you can slack call irregularly...


>irregular interactions

You mean like, randomly messaging me on Teams?


Yep that's one way


Is that on your resume? "Highly skilled in properly leveraging modern collaboration tools."

Wow, sounds impressive, haven’t seen that before, tell me more.

I'm really awesome at Zoom.


RTO it's such an emotional affair that most people just can't think rationally. Exemplar motivated reasoning.

I work in a hybrid mode and it's so obvious to everyone how in person communication is more effective. People will often say "let's discuss this once I get to the office" all the time.


If working in an office actually meant in-person communication, people might be more okay with it

I'm not coming back to an office just to talk to the rest of my team on the computer anyways because they are distributed in different provinces and countries

That's dumb


>I know many people on HN hate the idea of RTO

The six months we were WFH were the worst six months of my career. Nothing got done.

Granted, I am in a specialized field and most of my work requires calibrated equipment in purpose-built labs but so many people just wanted to sit at home and click around on Digikey and complain about SolidWorks being slow on their laptops.

I could never do the kind of engineering that doesn't result in a physical object that exists in the real world. The group photo at the end, standing next to a new thing that nobody else on Earth has ever seen, makes dealing with all of the PMPs worth it.

edit: and software guys need to put on some god damned clothes and come into the office, too. I'm not paid enough to troubleshoot over email or slack the hacked-together nightmare of a virtual environment that "works on my machine" but throws ten thousand errors when set up on a test stand.


I can't relate to the sentiment here. I also do the kind of work that results in physical objects in the real world. Conservatively, 95% of that work can be done with an SSH connection or the postal system. Most of the rest are fine with a webcam to a bench somewhere. The remaining day every 3 months or so I'm fine meeting in-person, but I don't want to organize my life around it.

My experience is that the infrastructure you need to do effective remote work is also the same infrastructure you need to debug issues in the field, so you may as well build it upfront.


How do you measure temperatures on each board revision after it comes back from SMT fully populated to make sure there are no shorts as you do initial system bringup over SSH and a webcam?

I am unaware of any remotely-controlled temperature probes.

Just last month we had a board come in to I&T with a short on the N1V5 rail and due to me, the designer, actually being there I knew it could only be in a handful of locations so I took the thermal camera and swept the board, found a hot component, and then found a solder ball beneath the pins of the IC and sent it back for rework.

I only found it by realizing that specific component almost never fails and never fails short anyways, then knowing that it has a bottom thermal dissipation pad where any excess solder application can squeeze out, and then rotating the microscope to its maximum deflection and peeking underneath the component at an angle of 55-60 degrees. https://imgur.com/a/1hFBNEL

30 minutes. Compared to days of back and forth and waiting online.

Techs don't know the board and the components, that's not their job. Engineers do-- that's their job.

Or is doing that basic and simple engineering work "for the schmucks to dumb to wfh?"

I can see it now. Me sitting at home squinting at a webcam feed shouting "ok move it over to the left, a little more, a little more" debating in slack like a moron with all of the other prima donnas too important to drive in to work as my techs cuss me out for being such a loser.

My techs don't do anything unless I do it first, document it, do it again to check the documentation, and then observe them doing it to make sure my documentation covers everything. And I mean everything, from short tests to the final cleanup of the workstation.


You mail it or come in for those few days you need to verify things. Are you spinning new revs every day or something?

Honestly, I don't mind if you want to work in the office. Maybe it makes your job easier, but what I've found is that for the tasks I do it just adds a commute for no reason.


I agree with your first point.

In my experience, it takes a special kind of junior engineer and a commitment from the company to have them mentored successfully in a remote environment. Whereas an in-person environment has tons of opportunities to learn not just the explicit skills (how to write a for loop on Python, how do deploy our software) but the implicit skills (how to move around the terminal, how to architect a solution in a consistent way). That's to say nothing of the knowledge osmosis that happens when you can overhear conversations about adjacent parts of the application. (Yes, you can make this all explicit and available online, but that is a culture shift.)

There are other ways to deal with these lacks (on-sites, focused on onboarding docs, regular office hours) but they take more effort. Whether they are worth the trade-off (you certainly have access to a wider pool of labor when you hire remote) depends on the company, industry, and job market.


With regard to your second point, that seems to be entirely the fault of Dell - no? If they wanted to encourage junior engineers with promotions, maybe they should, you know, promote them? Rather than inventing silly games and trapping them in loops.

I understand your first point however. Can’t imagine how interns and early engineers are supposed to learn without having a highly available set of mentors to learn from.


I totally agree with what you are saying, My point was that this policy just seems to be another one of those policies to get them to not be promoted. More hoops you may call it


Ah indeed, seems we are in agreement.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: