|
i'm a senior developer, which in my experience means "has a >50% chance of being able to locate own rear end with both hands"
|
# ? Sep 10, 2020 06:53 |
|
|
# ? Apr 25, 2024 18:35 |
|
redleader posted:i'm a senior developer, which in my experience means "has a >50% chance of being able to locate own rear end with both hands" senior software engineer means "may be able to find own rear end with two hands and a map." it's a very fine distinction.
|
# ? Sep 10, 2020 13:13 |
|
I’m a solutions architect, which means at my last interview I asked for the title “architect.”
|
# ? Sep 10, 2020 16:01 |
|
My actual job title is Sr Researcher. It means that it was easier to rename my position to make bureaucracy happy, than it was to explain to them that I am doing actual research with the title of Sw. Engineer.
|
# ? Sep 10, 2020 18:23 |
|
I got Director of Engineering, I think. As we've discussed, engineers may take offense to the idea that I'm directing engineers. I'm also not sure I feel like a director, but I'll take it.
|
# ? Sep 10, 2020 18:39 |
|
kayakyakr posted:I got Director of Engineering, I think. As we've discussed, engineers may take offense to the idea that I'm directing engineers. I'm also not sure I feel like a director, but I'll take it. If anyone complains about you being a Director, change their title to something like Key Grip.
|
# ? Sep 10, 2020 19:43 |
|
lifg posted:If anyone complains about you being a Director, change their title to something like Key Grip. Best Boy
|
# ? Sep 10, 2020 21:30 |
|
lifg posted:If anyone complains about you being a Director, change their title to something like Key Grip. arbybaconator posted:Best Boy Gaffer Or, somehow appropriate, Python Wrangler
|
# ? Sep 10, 2020 21:41 |
|
I generally take "architect" to mean "the guy you need to convince before you change a non-trivial core part of functionality Our architect has been involved in converting internal technical dead ends in our monolith into RESTful APIs (not microservices), and then also gave the stamp of approval for moving to containers in production, also approved some new ETL crap that interfaces with our main database I feel like that's stuff the VP or CIO or at least director level ought to be rubber stamping, but we've successfully divorced management leadership from technical leadership and now we have architects I've seen some Engineers get promoted to "senior" because management was concerned about them leaving and couldn't justify the "don't leave me, baby, please" paybump any other way
|
# ? Sep 11, 2020 00:46 |
|
Hadlock posted:I generally take "architect" to mean "the guy you need to convince before you change a non-trivial core part of functionality I worked at a place where everyone had a lead title just so they could get moved to a new salary band. This place also had managers and even senior managers with no reports, so they had issues.
|
# ? Sep 11, 2020 02:48 |
|
That actually sounds like pretty decent direct management that knew how to play the game embedded in a larger org that otherwise would've stagnated people's careers Of course there's less charitable ways of reading what you wrote, but I'm gonna go with the happy story
|
# ? Sep 11, 2020 03:34 |
|
Hadlock posted:I've seen some Engineers get promoted to "senior" because management was concerned about them leaving and couldn't justify the "don't leave me, baby, please" paybump any other way TBH I find that "if this guy left, we wouldn't know what to do" is a pretty decent definition of a senior engineer, no matter their age or experience. YMMV but I'm fine with the above policy.
|
# ? Sep 11, 2020 11:13 |
|
Hadlock posted:I generally take "architect" to mean "the guy you need to convince before you change a non-trivial core part of functionality my current job is first time i talk to an architect (didnt even know the title before) and it's kinda alright. they do the high level specification, tech stacks, etc etc and read through all the boring documentation to figure out how to implement it (oauth im looking at you) and we just hit the keyboard until it works
|
# ? Sep 11, 2020 13:48 |
|
kayakyakr posted:Gaffer Boffin
|
# ? Sep 11, 2020 14:05 |
|
Hadlock posted:I've seen some Engineers get promoted to "senior" because management was concerned about them leaving and couldn't justify the "don't leave me, baby, please" paybump any other way this is why i've had 3 made up title changes at the same job without any change of duties. rigid HR pay structures ftmfw
|
# ? Sep 11, 2020 16:51 |
|
My company has very wide overlapping bands, so we have some juniors earning as much as seniors. Totally dependant on the luck/when you got hired. Oh, and we don't do cost of living increases. You gotta "earn" the (usually minuscule) bump. And gently caress you if you're stagnating/dealing with poo poo in your life during pandemic. We'll fire you because we only want winners. There's so many people with their resume files visible on the desktop when they zoom share, that it's not even a thing any more. Anybody hiring?
|
# ? Sep 11, 2020 17:47 |
|
Inacio posted:my current job is first time i talk to an architect (didnt even know the title before) and it's kinda alright. they do the high level specification, tech stacks, etc etc and read through all the boring documentation to figure out how to implement it (oauth im looking at you) and we just hit the keyboard until it works I kind of gave up trying to bring sanity to projects after that. Basically if you have an architect they need to have a lot more connection with the actual engineering teams. The job before that the architecture duties were split between me and the actual principal architect; we'd have weekly arch meetings where we'd hash out where we wanted to go and write preliminary specs for the other engineers. But we'd all be involved in actually building the drat thing so we'd figure out pain points and issues real fast. That being said I couldn't stand having a job where I wouldn't at least have a say in that kind of thing, because guess what I'm actually really good at it. Ghost of Reagan Past fucked around with this message at 22:56 on Sep 11, 2020 |
# ? Sep 11, 2020 17:54 |
|
The role of Architect in a software organization can apparently be done in many different ways. The only time I've been on a huge software project (~120 scrum-sized teams), they had a setup where a few guys had done the overall architecture together, which turned out to work so-so once we were two years into the project, as architectures always do. Remarkably, they were still with the project and acted as technical coordinators; chairing technical committee meetings, contributing design documents and acting as code guardians on some key components. Some "subordinate" architects were code guardians and technically responsible for other components, meaning they negotiated APIs etc. Surprisingly, it sort of worked! Once the product came out of beta (1,5-2 years into the project, I forget), it had horribly outgrown the initial architecture, running on too many VMs, consuming an inordinate amount of resources to run, and it was more or less impossible to migrate it to a better one without breaking compatibility. But they're still adding features and coming up with various clever ways to deploy it on kubernetes and what have you, so it's going better than I anticipated 5 years ago. I'm not sure what to attribute to the project setup and what was plain luck or hard toil.
|
# ? Sep 11, 2020 19:09 |
|
Frankly I'm amazed that a project with one hundred and twenty teams involved in development was able to get out of beta inside of 2 years with anything that was even remotely functional. Resembling the original design is pure gravy at that scale.
|
# ? Sep 11, 2020 19:42 |
|
I've decided that my new title is Staff Code Archaeologist
|
# ? Sep 12, 2020 02:12 |
|
Actually you're a computer-toucher. Staff computer-toucher if you like.
|
# ? Sep 12, 2020 03:32 |
|
Steve French posted:I've decided that my new title is Staff Code Archaeologist I've described myself as an archaeologist and been serious about it. Most of my career has been going into old, brittle systems and figuring out how they work, and being EXTREMELY CAREFUL about it when I ...make changes... look it's not a perfect analogy okay but I like it.
|
# ? Sep 12, 2020 04:45 |
|
Che Delilas posted:I've described myself as an archaeologist and been serious about it. Most of my career has been going into old, brittle systems and figuring out how they work, and being EXTREMELY CAREFUL about it when I ...make changes... look it's not a perfect analogy okay but I like it.
|
# ? Sep 12, 2020 06:23 |
|
A former coworker described that work as surgery and I think that's a very good way of thinking about it.
|
# ? Sep 12, 2020 14:10 |
|
I like to say Software Janitor because nobody else in the company wants to touch it. So, instead of a rare artifact buried deep in the Earth, or a tumor that needs to be extracted, it's toxic radioactive sewage.
|
# ? Sep 12, 2020 16:25 |
|
I used to call myself a firefighter. I stopped because I didn't want to mistaken for someone actually useful.
|
# ? Sep 12, 2020 19:34 |
|
ultrafilter posted:A former coworker described that work as surgery and I think that's a very good way of thinking about it. Love Stole the Day posted:I like to say Software Janitor because nobody else in the company wants to touch it. Both of these are very appropriate
|
# ? Sep 12, 2020 20:22 |
|
Love Stole the Day posted:I like to say Software Janitor because nobody else in the company wants to touch it. One thing I discovered about five years into my software career that I really get a kick out out of fixing/installing real plumbing, and that I enjoy fixing broken plumbing in, say, a bathroom myself way more than fixing someone else's memory leaks. If I have to fix someone's code in an emergency situation, the code is often going to be way more disgusting to me than whatever's going wrong in a bathroom.
|
# ? Sep 13, 2020 18:14 |
|
Looking for feedback on a technical interview question for a senior full stack developer. I threw together this fiddle http://sqlfiddle.com/#!18/53b2a2 and ask for a query that returns latest status name for an Order. Then, to try to pivot into systems design I'd ask, given an existing stack that uses this (happens to be .Net/Azure here), greenfield a system to deliver an alert when status changes using whatever you want. In addition to comfort talking through problem, I'd be looking for whether they mention the word 'queue' when I bring up a concern about message volume, think to use a text/email service at all, or even think of the browser alert capability that we all have to thank for those loving popups to allow alerts on every engagement mill site.
|
# ? Sep 24, 2020 17:53 |
|
The SQL fiddle example seems overly complex: - You have limited time in an interview, so communicate as simply as possible. An ER diagram would communicate the table relationships faster than the raw table definitions. - OrderStates and OrderStatus are very similar names; maybe StatusNames and OrderStatus is clearer? - the OrderStates are inserted without explicit IDs, but those IDs are used in the OrderStatus table, which would only work if the OrderStates table was initially empty. And sure, it is, but that's just happenstance and I needed to go and check the SQL above to confirm that was the case. Just explicitly set the ID; you're testing whether they know what a JOIN and GROUP BY is, not whether they know about the behavior of INSERT and autogenerated IDs (which is Db-specific anyway). - I'd suggest starting with a simpler task: show the StatusName for each OrderStatus. Then move to showing it for each Order + Order Status. Then move to just showing the latest OrderStatus. From experience, many people will fall at the first hurdle (which is just a JOIN), and if they do you can move on to other things. - The full solution can be done a few ways, but some of them are RDBMS-specific. In Postgres you might use a window function, but older versions of MySQL don't have that. So you can't test that here. A FSE position requires broad but not necessarily deep knowledge. What signal do you want to get from this question? I would bet that the above question as originally stated will take ~15-20 mins for an average candidate before you have to move on, and it only tests a specific aspect of SQL. Maybe if you made a simpler question, you'd get the signal "yeah, they know SQL enough to know what a JOIN is" within 5 minutes so you can move on to asking them about the many other things they'll need to know as an FSE. The system design question seems better and more open-ended. It's a conversation that could go many different directions. Be prepared for them to ask you for constraints: how often do status updates occur? Do we need to batch alerts if there are many updates in a short timespan? Do we need to batch alerts across orders for the same customer? To avoid those kinds of questions from derailing the interview, I prefer to get them to start small and constrained. Then if they make something awful, you can stop there and move on. If they make something workable, then you can tweak one aspect of it, like "we need to scale to 100000 alerts per hour", or "we need to give alert digests so we don't spam people", or "people want to choose how they receive alerts". minato fucked around with this message at 18:38 on Sep 24, 2020 |
# ? Sep 24, 2020 18:35 |
|
Candidates are probably going to be overwhelmed and spend too much time looking into the table options for some gotcha. I assume they're all just the defaults but the export tool makes the explicit? Does it matter that STATISTICS_NORECOMPUTE = OFF? Are you trying to catch me out with some odd behaviour of SET ANSI_NULLS ON?
|
# ? Sep 24, 2020 23:36 |
|
minato posted:The SQL fiddle example seems overly complex: Yeah, this is killer, I opened up the fiddle and my brain just farted from having to look at all the raw SQL and this is stuff I have worked with. A diagram would be 100x better to describe the data. Serious chance having to try to parse all that on the spot in an interview scenario would have me just be deer in the headlights, even though it's conceptually not complicated. All the extraneous table configuration is mega distracting as well and probably irrelevant to the question at hand right? Feels way overcomplicated just to see if someone knows how to write some SQL select statements with joins. Guinness fucked around with this message at 23:47 on Sep 24, 2020 |
# ? Sep 24, 2020 23:42 |
|
Seriously, not trying to be a jerk, but does anyone write sql statements by hands these days? I feel pretty confident having spent my career working with relational dbs, manual queries way back 100% of the time, and I still went "oof" when I opened the fiddle. I'd have to Google to remember some deets that are not party of my daily use, though I probably can cobble up a solid pseudo-schema for a specific business use need in a heartbeat. This would be a point where, if I was interviewing and got presented this, I would probably think your company cares more about syntax/gotchas than concepts.
|
# ? Sep 25, 2020 01:19 |
|
gbut posted:Seriously, not trying to be a jerk, but does anyone write sql statements by hands these days? I feel pretty confident having spent my career working with relational dbs, manual queries way back 100% of the time, and I still went "oof" when I opened the fiddle. I'd have to Google to remember some deets that are not party of my daily use, though I probably can cobble up a solid pseudo-schema for a specific business use need in a heartbeat. In a data engineering role it's really important to have mastery of SQL. Due to a combination of poor monitoring, vacations, and a junior engineer who had a just a basic understanding of SQL we lit $37,000 on fire last month. wins32767 fucked around with this message at 02:03 on Sep 25, 2020 |
# ? Sep 25, 2020 01:35 |
|
Writing very complex queries by hand is generally easier than writing programs to write very complex queries.
|
# ? Sep 25, 2020 01:59 |
|
handwritten sql is Cool and Good, my friend. there is no substitute
|
# ? Sep 25, 2020 01:59 |
|
80% is real optimistic for when orms Just Work, if you're gonna give the standard orm spiel, too
|
# ? Sep 25, 2020 02:06 |
|
Seems like at every job I work at, whenever we hire somebody super senior, the very first thing they do is look at top 10 queries by total time, then rewrite them by hand, as they're doing something really dumb in the ORM, and we get back 30% of our production DB load. The queries they end up rewriting are typically old, small side features that were originally projects given to an intern who was carving down a giant redwood tree to make a single toothpick, and they go in and replace the tree with a 2x4 or something. Boom instant 50% speed improvement because they can look at the data and see that, oh hey, maybe if we don't use a bunch of ancient prebuilt code to pull a list of all customers ever, sorted by customer gender, then sorted by customer age, then left join those two lists together, to create a list of all paid/current accounts, sorted by transaction amount, to create a list of most popular SKU of all time, then select by transactions in the last 24 hours to find yesterday's most popular SKU in the shoe department.
|
# ? Sep 25, 2020 02:14 |
|
Don't get me wrong, I'm not hating on SQL. I actually love it, and love being able to elegantly pull things off that would be impossible or very hard using some dumbed-down abstraction. The expediency of delivering "features" has removed me from the guts of it for years now. I know a bunch of senior devs who are "full stack" who's operating knowledge of SQL stops at basic crud, and I understood the question targeting that bunch.
|
# ? Sep 25, 2020 02:15 |
|
|
# ? Apr 25, 2024 18:35 |
|
People who don't know much SQL shouldn't be writing very complex queries, but most of them generally don't know how little they know. It's the age old problem.
|
# ? Sep 25, 2020 02:17 |