Thanks. I think the problem is that the setting for drives is either on or off, whereas we’d like a way to limit the user to their own drive and not allow them to create shared drives, or at least very much limit the number and capacity of shared drives they can create. Now that we’ve let users create their own drives and the cat is out of the bag, I don’t know if we can just turn the feature off. I’ll find out in the security meeting.
Apparently there is no way to limit the # of shared drives a user can create, and no way to limit the storage capacity of shared drives. Shared drives are limited to 400,000 items, but not size-constrained. One of the compromised drives had 1.2 petabytes of video files, mostly blu-ray rips of movies.
def setup(... #specify some parameters here
...):
# do some manipulation of arguments here
args = [('p', p_path, p_folders),
('x', x_path, x_folders),
('c', c_path, c_folders)]
for drive, path, folders in args:
# do some stuff with the unpacked args here
I’m writing a python function to automatically setup directory structures for projects. p_path, p_folders, etc., are arguments passed to the function (or in some cases are variables constructed from other arguments. Some of these would typically use default values and others would typically be specified by the user.
I have a questions about lines 4-6, which add some structure to the arguments so they can be used in a loop. Since I’m essentially typing the same line 3 times with one character changed, it makes me think maybe I should be doing this another way. But in this simple case, the alternatives don’t really seem better to me. E.g., you could rewrite those lines as a list comprehension, but I think that would get a little ugly because it would have to handle converting strings to code.
Just want to check if there’s some simple idiom I’m missing here or if maybe this is an indication that the code should be structured differently.
This seems fine to me. Sometimes you just have to do a bunch of things and there’s no especially elegant way to do it. You could inline args if it doesn’t mess with the formatting too much, but that’s just aesthetics. If you do leave the args variable in, though, you could give it a better name (it’s not really just a generic bag of args any more, you just painstakingly crafted all this internal structure!). Some people frown on single-use variables, so I always feel an obligation to give them very good names to justify their existence.
You could also extract the body of the loop as a function and just call it three times, rather than looping. (Basically make lines 4–6 three invocations of do_some_stuff.). That would be useful if you wanted to more easily test the stuff in the loop body.
If I’m understanding correctly, you have variables for each drive letter. That is a mistake. You don’t want to have to edit code to add a new drive. Instead, have a dictionary with the key being the drive letter.
C can do what you say with macros and the stringify operator
#define MAKE_PATH(x) x##_path
I think python can do it, something like
globals()[‘p_path’]
but again I think it’s a sign of an earlier mistake.
Whats with the weirdo obsession with linked lists? Who the fuck uses these outside of uh blockchains? Its like “ok tell me you know the basics of recursion” I guess? I don’t get it all, in 10 years I’ve never used this pattern and I’ve probably used while loops in total on one hand. Strange stuff.
I think I ran into a use for a linked list a year ago or so. I can’t remember what it was and I don’t think I ever implemented it. But I remember because it was the first time I’ve thought, “Hey a linked list might be good for this”.
I’ve used FIFO stacks a few times. Those are fun.
And I’ve used a tree structure that was kind of like a linked list I guess, in that in creating the structure from a sorted list of items from the database, every member was either a child or a sibling of the member before it.
Railing this discussion is very interesting because I remember when I was learning about all of that stuff when I was learning programming and wondering exactly why I would need it to know for real world applications.
Am I doing leetcode wrong? I just do some array method usually reduce and come to an accepted answer, and then I go to look at other people’s submissions, and they’re all iterative and for loops and temp variables and shit? IDK this is just weird. Like this one:
In Python I would definitely do this as a for loop rather than a reduce, but that’s mostly because Python reduce is bad: JavaScript for loops are bad, so seems sound to favor reduce.
def wateringPlants(self, plants: List[int], capacity: int) -> int:
steps = len(plants)
current_water = capacity
for i, plant_need in enumerate(plants):
if current_water < plant_need:
steps += 2 * i
current_water = capacity
current_water -= plant_need
return steps
This is an easy problem, so it doesn’t really matter, but it’s still good practice to decompose the problem rather than just simulate it. The answer is really the sum of two quantities: the steps to go from the river to the last plant, which is just one step per plant, plus the length of all your refill trips. For example, as a follow-up, imagine that you have n plants, which are either bushes or trees. All bushes require 1 water, and the plant at an index is a bush unless the index is a key in trees, which maps the index to the water needed by a specific tree. Also, n is 109. I’m pretty sure this is solvable in O(# of trees).
I heard google is making big changes to their interview process.
Before Process:
Apply for a software engineer job (not specific)
phone screen
During the on site do coding interviews with random engineers, maybe a design interview, and a leadership interview
Hiring committee meets, debates, approves
Go into a pool of almost-hired. Hiring managers reach out to discuss team fit. Mutual pick.
Negotiate terms.
VP approval.
Offer extended.
New Process:
Apply for software engineer job. (specific?)
Team match and do the leadership interview with the hiring manager.
On site coding interviews with team members plus maybe a system design interview.
Maybe avoid the hiring committee debate if positive reports.
Negotiate terms.
Offer extended.
They are trying to reduce their time to offer to compete better. I liked the “interview with randoms” better because I think people will have less bias about people they won’t work with. Also the new way has the risk of locally different standards, hire buddies, etc.
Hire buddies can be a good thing imo. If l’m a manager and one of my best devs tells me an ex-coworker looking for work is a rock star, I’m probably going to hire that person, unless they take a dump on the interview table or something.
In FAANG world (and all the stupid startups who copy their interview process), that level of recommendation only gets you in the door. If you don’t ace the leetcode stuff you’re not getting hired. And then later they wonder why the dev who seemed like a rock star on the whiteboard actually kinda sucks, and the real rock star has landed somewhere else that is clinging on to them for dear life.
Whiteboards are ok when you have no idea about the dev. But recs, open source projects, ability to talk intelligently about past accomplishments, (IE - how every other job hiring process works) should not be trumped by leetcode imo.
Yes you have to make sure a dev who recommends someone isn’t just looking out for their friend. But if I’m buddies with a shitty dev I’m not going to recommend them at a place I work. If someone who you know is a great dev has first-hand knowledge that another dev is super solid, that should trump everything else imo.
These companies are so arrogant they think they can quantify what makes a great dev and test for it in a couple hours. All they’re really doing is sorting by 40-yard-dash time to draft a football team, while they and ignore years of college tape.
Obviously a FAANG doesn’t care of some good devs fall through the cracks. It’s all the other companies who should be mining that pool for diamonds in the rough that are screwing up.
If anyone ever had a killer startup idea, I could put together a Dirty Dozen of rock star devs I’ve worked with that I’d put up against any team.
Hiring for this profession is impossible. There’s no good solutions, for the “best” (highest paying) companies to the average companies.
But to be honest after going through some prep as I’m now looking for the past few weeks, the leetcode stuff isn’t terrible. Leetcode easies are easy. If you ask 3 of them you’ll filter out 95% of the terrible applicants. Loop through some shit, return something, the end.
The problem is when you ask leetcode mediums or for gods sake hards. Not only is it super dependent on people’s skillsets/luck, but its completely worthless for 99% of tech jobs, no one does intricate matrix-esque array of array solves or problems, we fucking make a call to a database and put some JSON on the page. Fuck off.
I liked the old process as well (despite not getting an offer before ). Team match before hand makes you miss out on a lot of candidates IMO, since you’re going to be worried about fit post interview. I’ve seen that problem come up before at our company (we generally refer them to the other team, but it doesn’t always work out). They do take way too long to report back, that part was awful.
I’m still debating on going through interviewing again, my boss right now is very good despite the (relatively) weaker salary. I’m just such a rest and vest kind of guy in the sense I don’t really care what my salary is or my career ambitions are as long as I get top work life balance.
You’d be shocked how little people are competent at coding, especially non-SWE types. I’ve interviewed a few FAANG style people lately, and it does not inspire confidence for the general performance if that’s the supposed high end (but maybe there is a bias, because I imagine people don’t leave these companies very often for non-specific situations if they were actually good). Just coding up very popular DS algorithms can be like pulling teeth.
). Team match before hand makes you miss out on a lot of candidates IMO, since you’re going to be worried about fit post interview. I’ve seen that problem come up before at our company (we generally refer them to the other team, but it doesn’t always work out). They do take way too long to report back, that part was awful.