|
Well you’re not in a post-interview stage as long as you haven’t signed an offer or been told “no” so you should probably still ask.
|
#
?
Feb 14, 2024 22:08
|
|
|
|
| # ? May 23, 2024 12:15 |
|
|
Don't forget about non-technical questions, especially ones that can make interviewers uncomfortable. That YOSPOS thread has some great ones. There's a ton you can pick up off asking a no-win question that they probably haven't prepped for; one of my personal favorites is "If I get an offer, why should I say no to it?"
|
|
#
?
Feb 15, 2024 06:52
|
|
|
My favorite is "this is kind of an obvious question, but it's always important to do a sanity check: do you like working here?" Ideally they'll spill the beans about any structural problems. I have when asked this question. If the guy hesitates more than 10 seconds, it's time to pull the ripcord and look elsewhere
|
|
#
?
Feb 15, 2024 07:34
|
|
|
As an interviewer I actually really like the "Do you like working here?" question. It's a good one because I think people who would honestly answer "yes" will like to hear it.
|
|
#
?
Feb 15, 2024 16:30
|
|
|
Lockback posted:As an interviewer I actually really like the "Do you like working here?" question. It's a good one because I think people who would honestly answer "yes" will like to hear it. Same. I work at a huge fortune 50 company with a pretty bad reputation on the customer side and whenever I tell someone where I work they groan a little. However I love my job, I love the stuff I get to work on, and I love my co workers, team, boss, etc. I really like getting the chance to “sell” all of that stuff to candidates.
|
|
#
?
Feb 15, 2024 16:43
|
|
|
I'm still hoping to run into an interviewer out there that answers the question "how many people work here?" with "I don't know... maybe half?"
|
|
#
?
Feb 15, 2024 18:33
|
|
|
Hadlock posted:My favorite is "this is kind of an obvious question, but it's always important to do a sanity check: do you like working here?"
|
|
#
?
Feb 15, 2024 21:24
|
|
|
Yeah at the bare minimum it's a great ice breaker
|
|
#
?
Feb 15, 2024 21:38
|
|
|
hendersa posted:I'm still hoping to run into an interviewer out there that answers the question "how many people work here?" with "I don't know... maybe half?" I'm in interview panels at my place and during my session (generally system design) I always leave time at the end and tell the candidate "you can ask me any question you'd like, I'll answer it as honestly as I can, and I won't repeat any of your question to the rest of the panel". I okay it with my interview partner first and we've had some good convos with candidates who are trying to avoid specific problems they had with previous places but there's no polite way to ask "y'all a bunch of assholes or what's the deal". It'll probably get me in trouble eventually but people we've hired have told me they appreciated the opportunity to be blunt.
|
|
#
?
Feb 15, 2024 22:35
|
|
|
Welp, they actually answered my questions. Guess the bar for an Ada programmer is not too extreme. For the "what should I be able to accomplish in X months", as an example, they answered this: This question is somewhat difficult, as expectations depend on both the chosen person and the agreed-upon work, but generally: 1 month: Produce functioning code under guidance so that it works at least on one's own workstation. 3 months: Independently produce components that also work in the target environment. 6 months: Independently implemented, tested, and documented component. Quite reasonable, and of course expectations can always be uhh.. surpassed? They use a 2-week sprint etc, based on all the answers it felt like a reasonable workplace with good practices. Now I just have to wait and see what the result will be... The company has like 4B yearly revenue with 15B+ € order backlog, so they are not going to run out of work anytime soon. Ihmemies fucked around with this message at 16:13 on Feb 16, 2024 |
|
#
?
Feb 16, 2024 16:09
|
|
|
Ihmemies posted:Welp, they actually answered my questions. Guess the bar for an Ada programmer is not too extreme. For the "what should I be able to accomplish in X months", as an example, they answered this: yeah if the thing you care about is regularly cashing checks, government contracting is incredibly stable the checks wont be the biggest you could get, but they'll always clear. team sizes are calibrated directly to the signed [frequently long term] contracts
|
|
#
?
Feb 16, 2024 16:44
|
|
|
I'm interested to learn about online resources for benchmarking distributed systems. For example, I'm told that if you have a system with TPS < 30k and latency > 100ms you should use Lambdas... however, where is the research or blog post which demonstrates how much better or worse that kind of system performs, as opposed to some other alternative? Under what load or system design would Rabbit be better suited than, say, Kafka? Things like this seem to be closely held expertise things that only the Principal-levels can throw around and speak authoritatively on... but it seems like their only source of knowledge for this kind of thing is just experience. It doesn't seem to be documented anywhere. If no such resource exists, then I think this sounds like a great premise for a series of blog posts!
|
|
#
?
Feb 18, 2024 19:55
|
|
|
That's probably based on 10k/s per VM, so minimum 3 VMs for a quorum. Thus less than 3 VMs worth of traffic could be called inefficient, and thus lambdas would offer a better ROI, allegedly? Seems a bit random on numbers, server performance is all over the place due to varieties in stacks.
|
|
#
?
Feb 18, 2024 20:26
|
|
|
It isn't the whole thing but there is open messaging benchmarks . But for the bigger question it isn't just about qps and latency it is also about consistency of volume, is the work CPU bound or IO bound. Paying $$$ for a lambda to just sit there and wait for a network call to finish isn't worth it.
|
|
#
?
Feb 18, 2024 23:52
|
|
|
Love Stole the Day posted:I'm interested to learn about online resources for benchmarking distributed systems. Everything depends on the specifics: what kind of workload? what kind of failures do you need to handle? what can you allow? what are your SLI/O/As? what is your team experienced with? Getting good at this career means gaining experience which you can then apply to making tradeoff decisions the next time you encounter a similar or related situation. There's nothing closely held about this knowledge, there just isn't An Answer™. The best you'll get is 'probably your best option in this specific scenario'. Anyone that's telling you there are general rules like '30k TPS and latency > 100ms == lambdas' is lying to you, or taking the everything-is-a-nail approach.
|
|
#
?
Feb 19, 2024 00:09
|
|
|
Mao Zedong Thot posted:Anyone that's telling you there are general rules like '30k TPS and latency > 100ms == lambdas' is a "thought leader" and should probably be ignored
|
|
#
?
Feb 19, 2024 00:33
|
|
|
Tangentially related, I've recently had to deal with the subtleties of how different messaging and queueing systems work. My company is really bought in on "use kafka for everything because we have the infra setup and it's there and we want to build an enterprise message bus on it". And so for a current project I fell into that trap because I didn't think hard enough about it and just went with the generalized guidance. Problem is that some of the fundamental things that make kafka good at certain things make it really bad at anything resembling a task queue where latency is at all important, especially if your tasks take more than milliseconds to execute. Kafka topics are partitioned based on a key you provide (think a hashmap backed by linked lists), and then each topic has guaranteed order of delivery but that means each partition's messages get processed serially by maximum one consumer thread at a time. So you could have 100 partitions with 100 parallel consumer workers/threads but if your message gets assigned based on the hash of its key to a "busy" partition you could theoretically have 99 idle consumers and one backlogged consumer just on essentially bad luck. You can tinker with what key you partition on to try to get more random round-robin assignment all you want but that fundamental mechanism is unavoidable and at that point you're just fighting against kafka. This problem rears its head at even very low throughput when consumers take even a couple of seconds to execute a task, as the additive lag becomes a real problem. I even knew this going in but didn't stop to actually think it through because guidance told me to just use kafka. So all that fancy heavy machinery and complexity and fanciness of kafka was actually the absolute wrong choice compared to a vanilla SQS, Redis, or even a postgres skip locked queue. Fortunately I didn't waste much time since the infra was already there and it was easy to swap out the messaging service but my point is over generalized advice is bad to follow blindly. Every situation and its requirements needs to be thought about individually. Guinness fucked around with this message at 00:58 on Feb 19, 2024 |
|
#
?
Feb 19, 2024 00:51
|
|
|
 There's been some fun sniping around the idea of Kafka in the awful programming thread if you are into that sort of thing.
|
|
#
?
Feb 19, 2024 11:37
|
|
|
Guinness posted:Tangentially related, I've recently had to deal with the subtleties of how different messaging and queueing systems work. My company is really bought in on "use kafka for everything because we have the infra setup and it's there and we want to build an enterprise message bus on it". And so for a current project I fell into that trap because I didn't think hard enough about it and just went with the generalized guidance. I 100% agree with your overall point here, and that there's too much over-generalization of advice in our work. But for the sake of clarity and understanding, I think you are mischaracterizing the limitations of Kafka and how it works (or perhaps it was mischaracterized to you). It's not really true that messages are processed serially by a single thread per partition: Kafka itself doesn't really dictate anything about how the processing is done, it provides the data in the topic partitions and allows the consumer to commit offsets within each partition as completed; the real constraint is that messages can't be committed out of order since it's an offset being tracked rather than individual message completion as in e.g. SQS. So you can achieve quite a bit of parallelism within a partition if you want, you just have to decide how far ahead in the partition you're willing to process past the last committed offset (i.e. how much work are you willing to redo if your consumer crashes and in flight work past the last commit is lost). So for example if you have messages that normally take 10ms to process, and you have 6 threads working on a partition, if a single outlier message comes in that takes 3 seconds to process it won't block any other work being done if you allow at least 1500 messages to be processed past your latest committed offset. Of course, throughput will be lessened for that time, but that's also true of any setup with fixed resources consuming from SQS etc as well. If you really are limited to one-at-a-time in-order processing per partition, that's more about the consumer tooling being used than it is fundamentally about Kafka. As an example, some relevant bits of the consumer library we've wrapped for our Kafka tooling (and we also use SQS for different use cases): https://nightlies.apache.org/pekko/docs/pekko/1.0.2/docs/stream/operators/Source-or-Flow/mapAsync.html we pass a pretty high value here that determines how many messages we're willing to process past the earliest not-yet completed one, and the function we pass to it uses a thread pool of a size we configure https://pekko.apache.org/docs/pekko-connectors-kafka/1.0.0/consumer.html#committer-sink This has some of the relevant kafka consumer settings related to commit intervals.
|
|
#
?
Feb 19, 2024 19:45
|
|
|
Steve French posted:But for the sake of clarity and understanding, I think you are mischaracterizing the limitations of Kafka and how it works (or perhaps it was mischaracterized to you). Yeah I realize most of this, and maybe I've over simplified for the sake of ranting. You can indeed come up with a multithreaded consumer but now, as you said, you've pushed responsibility of managing the offset onto the consumer and all the footguns that entails especially if your concurrency loses ordering by doing so. And it's a lot of extra configuration and coding concerns compared to just using a better/simpler tool for the job. There might be some legitimate cases for it, but when all I'm looking for is what boils down to a threadpooled work queue those all become overcomplicated and unnecessary hacks compared to just using a much simpler actual queueing system instead of a message log. My chief complaint was being told by other supposedly smart people to "we already use kafka so just use kafka" despite it being a bad fit. Kafka has its strengths no doubt, but just because its massive scale and throughput in some ways doesn't make it the best choice in all ways, which we agree on 
|
|
#
?
Feb 19, 2024 20:08
|
|
|
Guinness posted:Yeah I realize most of this, and maybe I've over simplified for the sake of ranting. You can indeed come up with a multithreaded consumer but now, as you said, you've pushed responsibility of managing the offset onto the consumer and all the footguns that entails especially if your concurrency loses ordering by doing so. And it's a lot of extra configuration and coding concerns compared to just using a better/simpler tool for the job. There might be some legitimate cases for it, but when all I'm looking for is what boils down to a threadpooled work queue those all become overcomplicated and unnecessary hacks compared to just using a much simpler actual queueing system instead of a message log. My chief complaint was being told by other supposedly smart people to "we already use kafka so just use kafka" despite it being a bad fit. Yeah, it's typically our first choice because so often we've architected systems as event publishers rather than things explicitly writing to a task queue, and so the flexibility of multiple consumer groups tracked separately is really nice. That, and we have it set up to be highly concurrent as I described because often we do want ordering guarantees, but only at a very fine-grained level (e.g. we just need to make sure that multiple messages corresponding to the same one of millions of users are processed in order), and Kafka achieves that. I think there's also something to be said for "in a vacuum, this is not the best tool, but it's one we already have and maintain, and it's plenty good enough"; always choosing the best thing for a specific job is a good way to end up with too many tools and maintenance / context overhead. But if the folks in charge of such infrastructure haven't set up tooling for it so that it _is_ good enough, welp. And for what it's worth, I think a bigger problem with it than outlier latency causing performance issues is just management of failures; having dead letter queues and such configurable for SQS is much nicer than the story for Kafka if you end up with messages that for whatever reason reliably fail.
|
|
#
?
Feb 20, 2024 00:56
|
|
|
The most fun use case for Kafka I ever worked with involved using it as a buffer for terabytes per second of streaming video that needed to be transcoded to other formats and bitrates. The encoding systems were constantly crashing, as they do, and this mechanism kept us from ever losing WIP. At the time I thought this use case was so novel as to be completely insane, but Amazon markets Kinesis this way to cops and other mass surveillance data clearinghouses, so maybe it wasn't. I wouldn't try to use it as a drop-in replacement for SQS or something built for small messages. Vulture Culture fucked around with this message at 13:57 on Feb 20, 2024 |
|
#
?
Feb 20, 2024 13:55
|
|
|
Welp, the company I interviewed for said they are not interested. They planned some extra position for me, where I'd do their Ada stuff. On the phone today said they don't have the resources to create a position for me after all, whatever that means. Surely they are not out of money with 15B+ order backlog. I interpreted it as "you're not worth our time, not good enough".
|
|
#
?
Feb 22, 2024 11:01
|
|
|
It could also be a problem of the right hand doesn't know what the left is doing. I've been in situations where my boss told me something and I passed that information on to a candidate but oops! the boss changed his mind or his boss did and the candidate was left high and dry. Sucks but not necessarily malicious, just incompetent.
|
|
#
?
Feb 22, 2024 11:14
|
|
|
Ihmemies posted:Welp, the company I interviewed for said they are not interested. They planned some extra position for me, where I'd do their Ada stuff. On the phone today said they don't have the resources to create a position for me after all, whatever that means. Surely they are not out of money with 15B+ order backlog. I interpreted it as "you're not worth our time, not good enough". the team can easily be out of budget
|
|
#
?
Feb 22, 2024 13:30
|
|
|
Never take hiring decisions personally. Definitely try to find better answers for questions, look into skills they were interested in that you don't have, think about why they may have been interested in A but clammed up after hearing you talk about B, but there's enough going on out of sight that being perfect for the role only ever gets you a 75% chance of getting it. I'm probably overreacting but I've known folks who got into a deep hole because, essentially, they confused "We don't need another ADA developer" with "You're not good enough as a person"
|
|
#
?
Feb 22, 2024 13:47
|
|
|
interviewing is sales, sales for whatever salary you're trying to get per year. a vast part of sales is letting rejection run down your back like water off a duck's back. one way is to understand that a straight-backed no is better than a bad-faith greasy-smiled maybe. an even vaster part of sales is always having 5-250 things in the pipeline at a time, so go prospecting. that's an hours-long activity, not a minutes-long activity it's a funny little thing, but typical yields per inbound contact for high-dollar b2b saas of the kind that charges 100k, 200k, 300k usd p/a end up being like 3-5% (in america in sf or seattle, lower basically everywhere else), and typical yield rate per inbound contact (meaning first-party recruiter inbound) for that sorta software job end up that way, too. with radical order-of-magnitude differences up and down depending on situations. outbound sucks one to two orders of magnitude more per contact, about. the basically-infinite variance is also an absolutely typical sales thing 4 pillars of the buying decision: budget, authority, need, timing. you can get hosed as jobhunter on all of these, and if they're saying one of them they don't necessarily mean it, but it's almost certainly one of the four. they don't care about you enough to decide that you're not a good enough human being or whatever bob dobbs is dead fucked around with this message at 14:14 on Feb 22, 2024 |
|
#
?
Feb 22, 2024 13:52
|
|
|
StumblyWumbly posted:Never take hiring decisions personally. Definitely this. I interviewed a guy for a PM role recently who ticked all the boxes and was very pleasant to deal with. Unfortunately for him there was an internal candidate and the hiring manager was heavily in favour of someone who was already familiar with the subject matter. If not for the internal candidate, he would have been a shoe in.
|
|
#
?
Feb 22, 2024 14:59
|
|
|
StumblyWumbly posted:Never take hiring decisions personally. I have been in situations where I was told by upper management to interview people because the project was behind schedule (and they rationalized the project lateness by not having enough resources), but I didn't actually want to hire anyone because the project was hosed regardless of how much manpower we had and I didn't want to have to deal with bringing people up on a project that was already doomed. Companies aren't always hiring for healthy reasons and it really can be "it's not you, it's us" sometimes.
|
|
#
?
Feb 22, 2024 15:50
|
|
|
Thanks. I do not take it personally, it’s just easier to vent a bit instead of just keeping everything always inside. As long as venting does not happen towards the potential employer. Forums seem to be a working solution so far. I simply was too hopeful, usually I get rejected a lot earlier in the process. I have many other applications to other companies, maybe one of them works. I was interviewed to an another position where they do some PHP stuff with Moodle yesterday. They said they’ll invite me perhaps for a technical interview “later”. At least I got a free lunch out of that if nothing else 
|
|
#
?
Feb 22, 2024 16:10
|
|
|
Was updating my budget for the month, and part of that involves setting aside emergency fund money. That got me wondering how long it would likely take me to go from unemployed to employed again, i.e. how quickly I could find a new job. I have enough set aside in my emegrency fund for something like 6 months of likely expenses, so that would give me maybe 4~5 months to find a new job if I lost mine. But I have no idea if it will take me that long, or if it somehow ends up being like 6+ months or something. How does everyone else feel about their own runway? If you lost your job today, how many months would it take from today for you to get hired and start making income again?
|
|
#
?
Feb 22, 2024 17:41
|
|
|
Back in 2019 when the market was hot, I took two months to find the right company. As a senior person I'd count on at least 3 months now, budget for 4-6
|
|
#
?
Feb 22, 2024 18:02
|
|
|
I keep about a year's worth of cash in our emergency fund. It's probably overkill considering my wife works for herself and something really catastrophic would have to happen for both of us to lose our incomes entirely. Also we keep our expenses low relative to what we make so finding a job which covers the bills wouldn't take longer than 2-3 months, even in this market I suspect. I keep a fat emergency fund because I like to have "gently caress off" money, where if something happened at my job and I decided to abruptly quit I wouldn't feel impending doom or pressure. I used to keep 6 months expenses but after setting aside extra when we were having a baby and renovating the house, I decided to hold on to it.
|
|
#
?
Feb 22, 2024 18:04
|
|
|
Hunting for a new job cos you don't like your current one usually takes longer than hunting for job because your unemployed. I doubt it would take me more than 3 months to find a new one if I was looking hard and willing to compromise. The golden rule of 6 months is probably more than most need but its nice to have the cover incase you lose your job and your boiler or car packs in at the same time etc
|
|
#
?
Feb 22, 2024 18:05
|
|
|
Mega Comrade posted:Hunting for a new job cos you don't like your current one usually takes longer than hunting for job because your unemployed. I doubt it would take me more than 3 months to find a new one if I was looking hard and willing to compromise. Yeah, this. I've got at least two standing job offers from old colleagues at places I don't especially want to work at but if I really had to... But to get on a little personal finance soap box, if you're an experienced well paid dev I really hope your financial runway isn't measured in just a few months. I'm not saying everyone needs to be a miserly FIRE dork, but planning and working toward financial independence is so incredibly important and we're lucky to be in the 5-10% of Americans with the type of career and incomes that easily allows it. It's an enormous stress and anxiety reducer that most Americans don't realistically have access to. If you're making figgie land dollars and not stacking paper toward "gently caress you money", barring some unusual personal circumstances, then I don't know what to tell you. Guinness fucked around with this message at 18:52 on Feb 22, 2024 |
|
#
?
Feb 22, 2024 18:47
|
|
|
a dingus posted:I keep about a year's worth of cash in our emergency fund. Six months cash and the rest in six month CDs is probably a better bet. Let your paper stack itself.
|
|
#
?
Feb 22, 2024 18:51
|
|
|
ultrafilter posted:six month CDs
|
|
#
?
Feb 22, 2024 19:23
|
|
|
Vulture Culture posted:Back in 2019 when the market was hot, I took two months to find the right company. As a senior person I'd count on at least 3 months now, budget for 4-6 Yes, six months is the gold standard, strong agree with this If you have FAANG on your resume you can probably go work for a lower tier start up for 1/2 to 3/4 your current salary in 2-4 weeks if you interview well and that's your jam Unemployment tops out at about $900/wk so that will cover your rent and groceries in most places unless you bought a big house in the last 5 years, and will allow you to stretch out 4 months savings quite a while. Most states have a 2 week "cooling off" period, and the first check can take 6 weeks to arrive so plan for that contingency All bets are off if you can't reasonably pass for a senior in this market though
|
|
#
?
Feb 22, 2024 22:03
|
|
|
If you absolutely need a job, I'm not sure what the hell tiktok is doing over there, but literally two days don't go by without some recruiter messaging me about some job If you're super desperate for a job and don't mind working for the social media division of the Chinese CIA, I can put a good word in for you with Xi
|
|
#
?
Feb 22, 2024 22:11
|
|
|
|
| # ? May 23, 2024 12:15 |
|
|
Hadlock posted:If you absolutely need a job, I'm not sure what the hell tiktok is doing over there, but literally two days don't go by without some recruiter messaging me about some job All you gotta do is fail their first coding screen and then they'll never talk to you again
|
|
#
?
Feb 22, 2024 22:16
|
|