|
That's not very agile. I'd never submit myself to that type of torture, particularly since it suggests the company is so unprepared to conduct interviews that they can't even summarize their problem domains into a few 45min scenarios. Meanwhile, given the learning time required, I wouldn't expect much from 1dy; you might as well just post everything as contract-to-hire. I admit that lots of companies are crawling up to the 5hr--6hr mark, or basically the full day with lunch. Honestly, that's getting to be too much because I rarely see disagreements that require all those interviewers' feedback. I mean, does four coding problems give you much more than three? I think it's of greater benefit to extend the time per slot and use more general questions, so you can get a sense for how the candidate develops and modifies their approach when more information is added. My worst was the 6hr interview that became nine and a half. I should have walked out.
|
#
?
Jun 10, 2019 23:30
|
|
|
|
| # ? May 11, 2024 19:28 |
|
|
PhantomOfTheCopier posted:That's not very agile. I'd never submit myself to that type of torture, particularly since it suggests the company is so unprepared to conduct interviews that they can't even summarize their problem domains into a few 45min scenarios. Meanwhile, given the learning time required, I wouldn't expect much from 1dy; you might as well just post everything as contract-to-hire.
|
|
#
?
Jun 10, 2019 23:37
|
|
|
No one knows how to interview but everybody thinks being too easy is bad. As a result, most interviews are very hard and not particularly informative.
|
|
#
?
Jun 10, 2019 23:39
|
|
|
Blinkz0rz posted:I like interview questions that involve solving problems where this is no one good answer. I like the "distributed, dynamic property management for microservices" idea but mainly to look for candidates who react with "what, are env vars not good enough anymore? Backlog that and give me a real problem".
|
|
#
?
Jun 11, 2019 04:04
|
|
|
Getting so tired having to butcher our front end to match the incredibly inconsistent backend API it talks to. Working on a new set of forms and theres two sections where you add notes. The first note entry API is fairly straight forward, you hit an endpoint thats specifically meant for adding notes to the parent object, sending along a category property and the parent objects id, and it returns the note with user information and a date the server set when it was created. The second note entry section is completely identical as far as the front end is concerned, it's just a different category of note, but instead of being able to send a different category property like above, instead its a jsonb array on the parent object, and the front end has to set the name and date information, then do a put of the whole array on the parent object. Whyyyyyyyyy, theres so many other weird disconnects like this as well that makes building front end stuff even worse than it already is.
|
|
#
?
Jun 11, 2019 05:02
|
|
|
Internal APIs are always horrorshows. External-facing APIs are usually less bad, and only sometimes horrorshows.
|
|
#
?
Jun 11, 2019 07:10
|
|
|
Looking at the backend code for note endpoint, I can kind of figure out how this came about. PM: Hey we need to add a new category to notes. BE Dev: Ok, let me just take a look at this old legacy controller oh god its a rats nest PM: Oh yeah they need this done yesterday BE Dev: jsonb field it is. ad infinitum
|
|
#
?
Jun 11, 2019 07:46
|
|
|
ddiddles posted:Looking at the backend code for note endpoint, I can kind of figure out how this came about.
|
|
#
?
Jun 11, 2019 11:17
|
|
|
Kevin Mitnick P.E. posted:I like the "distributed, dynamic property management for microservices" idea but mainly to look for candidates who react with "what, are env vars not good enough anymore? Backlog that and give me a real problem". User data isn't modifiable on running EC2 instances. How do you propose updating env vars on 10 servers without a service outage? What about 50 servers? What about 500? What about 1000?
|
|
#
?
Jun 11, 2019 14:18
|
|
|
Blinkz0rz posted:User data isn't modifiable on running EC2 instances. How do you propose updating env vars on 10 servers without a service outage? What about 50 servers? What about 500? What about 1000? Hand it to devops or infrastructure and say please
|
|
#
?
Jun 11, 2019 14:22
|
|
|
Boiled Water posted:Hand it to devops or infrastructure and say please I hope you never get hired
|
|
#
?
Jun 11, 2019 14:27
|
|
|
JawnV6 posted:it strikes me less as establishing a baseline vocabulary for "testing problem-solving" and more selecting for folks with ample free time I'm not happy to be out here defending Google, but they will let you schedule the onsite interview arbitrarily far in the future. If you want 8 weeks to prepare, they don't care at all and are happy to schedule you 8 weeks in the future. Re: contrived interview problems vs. real-life problems: The biggest problem with asking people real-life problems is that it tests experience more than reasoning ability or ability to think under pressure. For a lot of teams, particularly very large teams, there is little to no additional value in any particular piece of knowledge or experience that you have. What matters is your ability to solve novel problems, and your ability to not be a shithead while you do it. Contrived problems are relatively more likely to be novel to you, the person who actually works for a living, so they get to see how you work through it in real time rather than see how you worked through it in the past. Obviously there is a finite set of these contrived problems, and they are possible to study for, but the process is always going to be imperfect and the trade-off here feels reasonable. The interview I give most often is systems design, and the question I usually ask is grounded in reality, but not a real problem anyone at our scale actually has to solve. It's a useful thought exercise to see how people think, and it also reveals a surprising number of angry babies who get visibly mad the moment they are outside of familiar territory, which is one of the top things I want to learn in an interview. Blinkz0rz posted:I hope you never get hired absolutely empty quoting Comradephate fucked around with this message at 17:04 on Jun 11, 2019 |
|
#
?
Jun 11, 2019 17:02
|
|
|
redleader posted:Internal APIs are always horrorshows. External-facing APIs are usually less bad, and only sometimes horrorshows.  Or, for that matter, when every API call inherently does a full-table-sort before getting you your (n) slice of the results
|
|
#
?
Jun 11, 2019 17:39
|
|
|
Blinkz0rz posted:User data isn't modifiable on running EC2 instances. How do you propose updating env vars on 10 servers without a service outage? What about 50 servers? What about 500? What about 1000? Same way you do a kernel update w/o outage.
|
|
#
?
Jun 11, 2019 19:51
|
|
|
Kevin Mitnick P.E. posted:Same way you do a kernel update w/o outage. you don't do kernel updates on EC2 instances.
|
|
#
?
Jun 11, 2019 20:11
|
|
|
BabyFur Denny posted:you don't do kernel updates on EC2 instances. Right, you terminate them and let the new instance have the correct config.
|
|
#
?
Jun 11, 2019 22:11
|
|
|
Blinkz0rz posted:I hope you never get hired  Comradephate posted:Re: contrived interview problems vs. real-life problems: Not sure what you're trying to say here. A "real world" problem is one where you take a scenario and throw out all the pieces that are meaningless in an interview, modify one or two things to suit constraints, and you're ready. A contrived problem is one where you say, "wtf you just made this up so you'd have something to ask me?" People with "real world experience" in a system can flub if they try to "over-apply" their experience instead of discussing the scenario in the interview. Candidates without that experience have to apply the same basic solving skills. The scenario doesn't give an advantage beyond that naturally afforded to more experienced candidates. On the other hand, a contrived problem may be tackled excitedly by a candidate lacking "real world experience" because they've been riding leetcode. The person with the experience is likely to leave, laugh, or later observe, "Why the gently caress would I want to work there if those are the problems they need me to solve?" It's easy to simplify scenarios if candidates are stuck. It's harder to get good info if you spend your hour scaling up from "build an array" to "build the cloud".
|
|
#
?
Jun 11, 2019 22:45
|
|
|
Kevin Mitnick P.E. posted:Right, you terminate them and let the new instance have the correct config. Yeah terminating 1000 instances to tweak thread pools or rotate db credentials is probably a bad idea Anyway you get the point. It's a question that you can continue to tweak and probe on to get a sense of a candidate's problem solving technique.
|
|
#
?
Jun 11, 2019 23:15
|
|
|
Just had a client ask me to ping a device on their local 192.168.1.X network. So, y'know. That's a thing that happened to me today.
|
|
#
?
Jun 11, 2019 23:31
|
|
|
The neverending CI saga In the beforetimes, there was a legacy system that did vaguely CI-like things. It was a dumpster fire that was sucking up too much time from our small team, so we tasked a plucky junior engineer with building a replacement. We debated using Jenkins but decided against it for two primary reasons: harmonizing with our existing testing framework; and since we're doing embedded firmware testing, we have to use our own tools and widgets and doodads anyway, so the Jenkins value proposition didn't really seem all that attractive. That project went on for a year or so and was mothballed. The same engineer was told to start from scratch, this time using Jenkins. That project went on for a year or so and was mothballed. We discovered that another office had been using Jenkins for several years to do embedded firmware testing, and we were told to adopt it. The same engineer was told to work on that Jenkins implementation, and he did for about 6 months or so before requesting to either: A) be drug out behind the building and shot or B) given something else to work on. We are now being told that the other office's Jenkins implementation is No Good and Very Bad and we must shoehorn CI capabilities into our existing testing framework.
|
|
#
?
Jun 11, 2019 23:33
|
|
|
That's every CI story I've ever heard: You need a team continuously implementing CI tooling to achieve something like CI, but then an event will make you realize you need testing for that tooling, so you need CI for your CI... It's basically Zeno's Paradox for both CI and CD. Startup or corporation, I've never seen it succeed. And when you get really close, management will come in and tell you they want written, manual approval on steps to "avoid an outage".
|
|
#
?
Jun 12, 2019 00:48
|
|
|
About apis, i'm reminded of a client's launch of an analytics platform (built in-house with a fancy web/phone app dashboard, api, analytics engine, and backend). I was trying to pull data from it through the documented apis for an ML project. There was so much business logic embedded across browser, intermediate business logic layers, and the back-end that the devs on it recommended that I use browser emulation to mock up user interactions to pull out data from it.
|
|
#
?
Jun 12, 2019 02:14
|
|
|
It's me, the hiring manager who does not value experience solving the problems my team is asked to solve. Yes I am dumb as my interview process alludes to, why do you ask?
|
|
#
?
Jun 12, 2019 02:43
|
|
|
Blinkz0rz posted:Yeah terminating 1000 instances to tweak thread pools or rotate db credentials is probably a bad idea Hey I'm not the one who assumed that the only way a process environment could change was by mutilating the userdata. It's a good question though. I'd know right off that anyone asking it was someone I didn't want to work with.
|
|
#
?
Jun 12, 2019 03:11
|
|
|
If I'm running a bunch of code that was probably written under the assumption that environment constants aren't going to change underneath it, and I want to change or tweak some of those environment constants, shutting it down and restarting with the new values definitely seems like the way to go.
|
|
#
?
Jun 12, 2019 06:12
|
|
|
shrike82 posted:About apis, i'm reminded of a client's launch of an analytics platform (built in-house with a fancy web/phone app dashboard, api, analytics engine, and backend). We have a backend API integration test (do all services play nice together) that starts with pulling up a browser and capturing the cookie for authentication in the rest of the test. Using selenium, this is the step that fails a lot with the result that any failing test is fixed by running it again. I tried explaining that they might as well turn off and delete the tests if they are not reliable enough to give consistent results but people like the false feeling of security more than absolute certainty.
|
|
#
?
Jun 12, 2019 06:28
|
|
|
PhantomOfTheCopier posted:That's every CI story I've ever heard: You need a team continuously implementing CI tooling to achieve something like CI, but then an event will make you realize you need testing for that tooling, so you need CI for your CI... It's basically Zeno's Paradox for both CI and CD. Sure, but the alternative is no CI...
|
|
#
?
Jun 12, 2019 06:35
|
|
|
Jabor posted:If I'm running a bunch of code that was probably written under the assumption that environment constants aren't going to change underneath it, and I want to change or tweak some of those environment constants, shutting it down and restarting with the new values definitely seems like the way to go. Agreed I’ve never worked with middleware that took to changing poo poo like db connections parameters after startup. Hell I don’t even know how you do this with Spring, the most enterprise framework for java.
|
|
#
?
Jun 12, 2019 07:23
|
|
|
Janitor Prime posted:Hell I don’t even know how you do this with Spring, the most enterprise framework for java. Generally you reboot the instance and if you configured your AWS setup properly you can just have it automatically reboot the instances one by one.
|
|
#
?
Jun 12, 2019 08:45
|
|
|
Janitor Prime posted:Agreed We use https://github.com/Netflix/archaius which is pretty wild. Iirc spring cloud configuration can do it as well. There are various other libraries in other languages that do similar things.
|
|
#
?
Jun 12, 2019 11:09
|
|
|
The point is, and the reason I like questions like that, is that it requires a candidate to think through a broad space where there is no real right answer. I've gotten to a few solutions with candidates including:
However, I bristle at this kind of response in an interview: Kevin Mitnick P.E. posted:I like the "distributed, dynamic property management for microservices" idea but mainly to look for candidates who react with "what, are env vars not good enough anymore? Backlog that and give me a real problem". Because it smacks of the superiority complex that engineers tend to have. It's fine if you have an opinion, but doing the *dusts hands off* motion and smugly saying "give me a real problem" is a statement and an attitude which draws an instant "no hire" from me. And this: Boiled Water posted:Hand it to devops or infrastructure and say please Is even worse. If you're an engineer who is applying to work on software in the cloud "throw it over the wall to ops" is never an acceptable answer. Anyway, off my soapbox.
|
|
#
?
Jun 12, 2019 11:43
|
|
|
was just in a 3 hour meeting discussing this exact problem
|
|
#
?
Jun 12, 2019 14:17
|
|
|
Blinkz0rz posted:It's fine if you have an opinion, but doing the *dusts hands off* motion and smugly saying "give me a real problem" is a statement and an attitude which draws an instant "no hire" from me. I mean, I think there's a line to walk - it's totally appropriate to start with "My first step would be to talk to <people responsible for X>" because realistically that will often be the best solution, same as when someone tells you to reverse a string on a whiteboard your first answer should be "I use string.reverse()". Showing that you're able to use resources available to you is something that's also important to demonstrate. Naturally, in all cases, you should probably follow up with "However, in case <resource> isn't available, I would..."
|
|
#
?
Jun 12, 2019 14:25
|
|
|
Blinkz0rz posted:The point is, and the reason I like questions like that, is that it requires a candidate to think through a broad space where there is no real right answer. I've gotten to a few solutions with candidates including: Yeah no, what I have a problem with, and your interview question is a decent example of, is the industry-wide tendency to ignore important work in favor of interesting and challenging work. Then painting yourself into a corner with poorly-justified architectural choices that neglect operational concerns, because thinking about what happens when the DB breaks is much less interesting than DIYing a distributed scheduler. Janitor Prime posted:Agreed Spring doesn't do it. It's a hard problem with no right answer. Which means whatever you do will be wrong; instead, remove the problem causing you to think that changing your DB params after startup is something you need to do. I worked inside a system that used LDAP, of all things, for config management. It was really neat how you could update a node's, or a rack's, or a DC's, DB connection string and watch as the old connections drained and the new ones started up. Now imagine the amount of dev time that put into building and debugging that, just to work around the app servers holding so much state that restarts needed to be avoided at all costs. There was another bit for draining the state from a node so it could be restarted. More stuff I can't remember, from several years ago. Nothing that improved the product, just huge piles of dev time lit on fire for small improvements in operability.
|
|
#
?
Jun 12, 2019 15:02
|
|
|
ChickenWing posted:I mean, I think there's a line to walk - it's totally appropriate to start with "My first step would be to talk to <people responsible for X>" because realistically that will often be the best solution, same as when someone tells you to reverse a string on a whiteboard your first answer should be "I use string.reverse()". Showing that you're able to use resources available to you is something that's also important to demonstrate. Naturally, in all cases, you should probably follow up with "However, in case <resource> isn't available, I would..." It is absolutely crackpot to assign any value, good or bad, to whether a candidate snap replies "I use string.reverse()" before moving onto an actual implementation. The candidates who don't simply know from experience what the real nature of the question will be and are skipping to that part. It tells you nothing about whether they will "use resources available to them" in a real workplace setting.
|
|
#
?
Jun 12, 2019 17:06
|
|
|
Blinkz0rz posted:Anyway, off my soapbox. The DevOps answer is Consul
|
|
#
?
Jun 12, 2019 20:26
|
|
|
I am just going to leave this here http://seldo.com/weblog/2014/08/26/you_suck_at_technical_interviews
|
|
#
?
Jun 12, 2019 21:08
|
|
|
Keetron posted:I am just going to leave this here This website loving sucks (shocking as he's COO of NPM) but I agree with all of his points.
|
|
#
?
Jun 12, 2019 21:12
|
|
|
Protocol7 posted:This website loving sucks (shocking as he's COO of NPM) but I agree with all of his points. https://hub.packtpub.com/surprise-npm-layoffs-raise-questions-about-the-company-culture/
|
|
#
?
Jun 12, 2019 21:26
|
|
|
|
| # ? May 11, 2024 19:28 |
|
|
Vulture Culture posted:I've long thought of Laurie as a tremendously intelligent person, but take his thoughts with a grain of salt as you consider the way this situation unfolded earlier this year: I've actually argued with Isaac Schlueter on Reddit and he seemed like a crazy person with another C-level title at NPM, so I guess I'm not shocked. I wish NPM was handled by literally any other management.
|
|
#
?
Jun 12, 2019 21:39
|
|