|
frontend's always really funny for interviewing because there's a few types of interviews: 1. oh god please we need someone who can say the Magic React Words so that we know that they can unfuck our codebase 2. guess what fucker it's time to rewrite _.curry() 3. this is just a tree traversal problem, but we slapped the word "DOM" on it to pretend it has something to do with your day to day work i'm really good at (1), have collected enough javascript trivia to be ok at (2), and i'm miserable at (3). i've kind of always assumed backend roles tend to have the equivalent types of interviews? like, there's one where you say "well obviously in Spring I'd deal with this using the Spring FizzBlorp Package that everyone uses" and they nod and go yes good, and then there's one where you have to do some weird bullshit specific to your language, and then one where you've got to implement pathfinding or some poo poo for no reason feels like people only ever talk about the leetcode problems, though. is it because it's what companies use for early-screening, when they're too lazy to put a human on the other end of an interview? i'll admit i've kind of lost touch with that stuff, have worked with recruiters who sold me well enough i could skip some of that bullshit when i was last doing a lot of interviewing, and also no one ever knows what the gently caress to give frontend coders for that so what i did was a lot of "uh i dunno reverse a string i guess" which, lol
|
#
¿
Aug 16, 2023 03:38
|
|
|
|
| # ¿ May 17, 2024 13:31 |
|
|
Hadlock posted:We had "Zulip" at one company and there were at least three different mutinies trying to switch over to slack. Including a formal vote where slack won "but not by enough". Eventually the product team got slack and over time engineering all managed to get slack licenses and we all migrated over leaving the VP of engineering and his group of cronies (which he never hesitated to mention, were all in his wedding) over there Hadlock posted:It's like 11 years old at this point. Some people use it i loving loved zulip when i was going to recurse center lol, it's the perfect application for piling a ton of people talking about wildly different things into it. RC still uses it and i pop in there to talk with the other alumni from time to time. but yeah the search is a nightmare it was also the first company i ever applied for a job at, back before they got acquihired and the product was open sourced. they brought me up to boston to interview and i was like "yep i just do javascript and frontend things, you have a web app, i'd love to make a cool web app that's cutting edge" and then failed the interview because they asked me questions about sql and shell scripting, because the whole team was a bunch of MIT people who's previous startup was live kernel patching, so that's all they knew how to interview about. i'm not saying that i would have managed to make a UI that was competitive with slack, because it's hard to get people to wrap their heads around threads, but also in retrospect i think the thread system was way better than what slack/discord have now. at least there's no loving sidebars in zulip, and you can have a single screen that shows you all of your messages without being overwhelming. take boat posted:say what you will about Zulip the service (I never used it), but the team managed to sell it to Dropbox before launch, got Dropbox to open source it, then spun up a new company to operate and monetize the open source project. gotta respect the hustle absolutely, for as bad as they were at interviewing and building a successful company they were all genuinely really nice people. i'm glad they managed to exit and open source and continue supporting the app so the handful of long term users could stick with. honestly the best end for a startup imaginable
|
|
#
¿
Jan 10, 2024 02:17
|
|
|
we have a billion open positions... and of course are only hiring in latin america because it costs 1/3 as much. that and they've taken our manual QA org and are trying to retrain them as engineers, because they're still cheaper than SE1s and have product context? this is going about as well as you'd expect on a ~60 engineer team with no existing "software engineer in test" type role we just lost the EM and PM for our ML squad to google though so yknow some people in the org can still make lateral moves even if most of us are just stuck waiting until we get replaced with cheaper people
|
|
#
¿
Apr 4, 2024 02:55
|
|
|
it's pretty hard to integrate swagger into a system that doesn't have typed response objects, and can be hard to get swagger to fully document things like different error responses. this probably won't matter that much unless you are trying to use client generation we've got a really weird system at work... basically like 30+ java/kotlin services that use swagger but kind of poorly, and they have a confusing mix of internal and external endpoints. the external endpoints get mapped arbitrarily through an nginx proxy so we can't really generate external-facing clients. we're moving to grpc for internal stuff, which seems fine. the weird thing now is that we're experimenting with using protobufs to define external-facing http resources as well, which i'd be into if protobuf wasn't an incredibly loving wack serialization format that was made to express distributed function arguments and not, like, an external-facing API contract. you also still need to manually define an http client for your endpoints in this situation, you just get the advantage of generated code for request/response bodies. i've been mulling over this situation and i've been thinking about trying to back us out of using protobufs for defining http resources and going in on using swagger, but we'd need to centralize our external-facing endpoints into a single routing table that swagger understands to really get full advantage of that. we already use a backend-for-frontend service for some stuff so we might just start generating a client purely for that service, and then start trying to move everything external there? however our BFF service was never really intended to scale up that large (architecturally, that is: from a performance perspective it is very easy to scale a node http service that does nothing but calls to other services) so that's it's own can of worms
|
|
#
¿
Apr 20, 2024 18:33
|
|