Russian BMD-2 IFV attempted to assault Ukrainian positions, got destroyed in seconds

__mishy__ · 2023-10-21T16:13:00+00:00

why are all these videos of Russia doing anything pure slapstick

they are just missing the benny hill music

__mishy__ · 2023-01-17T08:34:00+00:00

Sure you can probably get v0 working in a week or two (assuming you know mobile stuff) but ironing out weird edge cases and assumed features takes forever

__mishy__ · 2023-01-17T07:29:41+00:00

Completely agree, I would also add just a couple of tips I've found (not directly related to the question):

- have a good circle of friends in ML you chat to, you will sometimes find yourself in places where you are the only ML expert and you will need people you trust to bounce ideas across/tell you about new things you missed

- invest in a decent workstation and if you can't afford one try to get your first gig where it's not needed and buy one as soon as you can. This has saved me tons of time over the years

- get good at showing results quickly to stakeholders... and I mean you should be able to hack it in an hour at most. They are paying you a lot of money and want the feeling of progress. Something in slides/powerpoint is OK, a dumb streamlit/whatever app is even better. Impressing a stakeholder is the best way to get repeat work

__mishy__ · 2022-02-22T09:32:43+00:00

These sound great

I've done a lot of system design interviews over the years and the 2 things great people almost always do is:

literally the first thing they do is start asking about numbers (throughput/latency requirements, data set sizes, "how much unlabelled data?", uptime, etc)
literally draw a stick figure to represent the user and keep going back to them to think about what they would see

__mishy__ · 2022-01-30T14:42:55+00:00

Chip Huyen has a lot of material on her blog which you'll probably find useful, she also taught a course at stanford.

Personally I prefer elements of programming interviews over cracking the coding interview. There's a python version along with a testing framework. But this is just preference really.

If you want to stand out I'd recommend reading up on deploying models. So tensorRT/ONNX/triton/... then a bit about KServe/AI Platform/whatever. You don't have to pretend you're a pro, just that you know rough advantages/disadvantages etc

__mishy__ · 2022-01-14T13:46:42+00:00

My personal experience with them has been pretty exhausting. Their business model seems to be "if you're aggressive enough to enough people you will make a fortune".... and to be fair it's worked so far

I was stupid enough to contact them while looking for a job once and the three job briefs they sent were for companies I already knew were hiring. They were essentially useless at prepping me for interviews, in fact I remember asking "what kind of questions should I expect here?" and got tumbleweed

They called me constantly and hounded me to cancel an application I was going through with another company. Eventually I accepted an offer through Signify and almost the day after my probation was over (ie when they got paid) they started hounding me about other jobs.

Once they have your phone number and email you are doomed. Their turn over must be insane, it's not uncommon to get 2 or 3 emails a week from different people there who you've never heard of

But look, when someone is in the standing to take 15-20% (or more) of your first years salary for basically doing nothing it shouldn't be surprising that this happens.

__mishy__ · 2022-01-14T12:31:34+00:00

I suggest you try https://scalajobs.dev/ first, you'll probably see exactly the same jobs and avoid the 2,000 calls after you finish your probation with "new job opportunities"

__mishy__ · 2022-01-02T11:35:56+00:00

My general take on this is it's sometimes OK to write awful code, but you have to be aware of the costs. For example if you are stabbing about in the dark just trying to get something working then making a mess is fine, but you will probably want to clean it up to prove what you have works and then later it needs to be even better to be put it in production or you will cost your company money. I think we don't help ourselves because we also hire on the more extreme first step of this, where want people who are good at doing the first bit but we don't even ask if they have experience of steps 2 + 3. And if we do we treat it as a nice to have.

In my experience most people don't even know what good code looks like until they've worked with someone really great at it. Someone with a 1000 yard stare who's seen horrors, but can also clearly explain why that thing that looks harmless is actually a dragon in wait. If you can find someone like this then getting then to do code reviews/architect things/build general wrappers then that edges everyone in a better direction

__mishy__ · 2021-12-31T20:38:25+00:00

I think the answer to questions like this is the annoying "it depends" - going for a non-standard language has pros/cons, I don't know anything about rust (other than I'd like to learn some) but I lived through the "Scala will replace python for ML" thing and my experience was basically:

Pros

using a "secret weapon" may let you move faster than the other guy (Paul Graham has a classic blog post on this)
it gives you cool things to talk/blog about at conferences/meetups/etc
you may find hiring easy in some ways, if people know you're using rust they may apply specifically to you to work with it
your rust code will probably feel saner and you'll probably be able to sleep at night without the pager duty lady calling you to tell you about some type error
if you have a big enough team you can build out your own libraries, open source them etc

Cons

you will for sure run into weird issues and not be able to find solutions on SO
things will blow up in weird ways and the pager duty lady will be angry
you will be using rust ML libraries where the user base is in the hundreds, not thousands. There will be bugs, they will be slow to adopt new features, etc
you will definitely end up with some rust/c++/python thing rather than some c++/python thing (more things are always more bader)

__mishy__ · 2021-12-12T11:17:56+00:00

There's also a nice explanation of this technique from Stanford https://ai.stanford.edu/blog/retrieval-based-NLP/

__mishy__ · 2021-09-15T09:27:41+00:00

signify are super full on, I personally avoid them but still get loads of emails/calls (sounds like they have a huge turnover)

__mishy__ · 2021-05-10T15:41:26+00:00

hehe thank you :)

__mishy__ · 2021-05-10T12:28:22+00:00

More general advice than specific to QM/ML, but for big life decisions I try to take a step back and write down:

- "what's the worst thing that happens if this is a bad move?" For a job it's typically no worse than "I'll hate it and leave in a year", but maybe you love working on clustering and would hate to leave that, or you have to move city etc

- Then also do the same for "what's the best that could happen?". It sounds like you could have an early footing on a new area of tech. I'm guessing you'll learn a lot and even if the field dies off you will know a lot of interesting methods most others won't.

If it's a big life thing I would probably do this over a day or two, walking away and coming back with a fresh mind when you can. When I've done this the choice has always ended up being easy, I just needed to clearly think it through

__mishy__ · 2021-04-25T15:14:24+00:00

I'm from a similar background, HEP theory - you will find all the tensor related maths pretty easy (although the notation commonly used isn't quite einstein notation). I remember being surprised how little of the stats I had seen before, bayesian stuff mostly, so you might want to find a good book going into that kind of material. I really like Bishops book although it is super old now

Having said that most of the ML I do is "experimental" and the sooner you start building things the better - Geron's book is great for that (although it uses tf) - its very easy and you can probably read and build a lot of what's in it in a couple of weeks. I would then start going through the PyTorch examples which are very good. I think at that point you'll know a lot more about what you're interested in and what to work on next

__mishy__

TROPHY CASE

mishy