|
I'm okay with whiteboarding, but I hate the "make it real code that compiles" requirement. If you want that, give me a laptop with a projector.
|
# ? Oct 22, 2019 03:03 |
|
|
# ? May 24, 2024 21:08 |
|
I handwave things like exact syntax, or writing the relevant methods for container objects, etc. Getting to the solution is much more interesting. Don't shy away from a naive solution, unless your interviewer is heavily hinting that you're going in the wrong direction. Coming to a naive solution is better than coming to no solution.
|
# ? Oct 22, 2019 15:17 |
|
lifg posted:I'm okay with whiteboarding, but I hate the "make it real code that compiles" requirement. If you want that, give me a laptop with a projector. When I'm hinting, a great place to start is "here's where the compiler would complain." Like if there's a magic variable that's doing a couple things I'll ask about the declaration. If they're shifting 32 bits into nothing and storing a bunch of 0's into a 64bit number, I know how the compiler warns you about that and will poke at the line. The goal is still a working algorithm, the "compiler" as a villain makes for an easy way to hint about a deficiency at the moment. I think *some* bad candidates latch onto the "make it compile" complaint and conflate it with this style of hinting. Rounding up "i got a compiler-sounding hint" to "omg they wanted PERFECT will-compile code?!?!??! on a WHITEBOARD??"
|
# ? Oct 22, 2019 17:58 |
|
Generally if the coding interview is a full 45 minutes of that and not split between that and behavioral stuff (Amazon) then I have time to do both a naive and an optimized solution. I just wonder if coding the naive solution is rigging me with a bad first impression and I should cut it out. It's looking like if I have good confidence in getting to the faster solution then I should just skip writing out an initial version.
|
# ? Oct 22, 2019 20:52 |
|
Things usually don't go that well for me if I get a naive solution while explaining things along the way and the interviewer isn't interested in the "just make it work first" approach and doesn't even tell me that until after I've spent like half the interview. Like even with FizzBuzz I explain the output, patterns I'm observing, and setup conditions - I don't insult a problem ever but I try to make it clear if I've seen the problem before and that it may not be the best test of my skills but rather memorization. If you're expecting me to solve like a queens problem solver with a whole 10 minutes left in the interview of a 30 minute slot after I take like 15 minutes over-engineering FizzBuzz, you'll need to tell me to hurry up or start asking better questions before I waste our collective time.
|
# ? Oct 22, 2019 22:41 |
|
Rocko Bonaparte posted:Generally if the coding interview is a full 45 minutes of that and not split between that and behavioral stuff (Amazon) then I have time to do both a naive and an optimized solution. I just wonder if coding the naive solution is rigging me with a bad first impression and I should cut it out. It's looking like if I have good confidence in getting to the faster solution then I should just skip writing out an initial version. Unless you can pop out the full naive implementation in literally a couple minutes I wouldn't write it down, I would quickly acknowledge it, explain how it could be done, and then say "but I think we can do better then that" and move on to the next version. The question you are asked may not be the full question the interviewer wants to ask you, my go-to question has two parts, many candidates never know there is a second part because they struggle with part 1 or just spend too much time on it.
|
# ? Oct 23, 2019 00:06 |
|
Let's see how many of my technical interview questions have appeared online... 0/5 found so far. Regarding the brute force approach, I'd recommend you (as the candidate) provide the three-sentence summary version, note its performance issues, then ask if they'd like to see the code for that before moving onward to a better approach. The interviewer may have one or two questions just to clarify that you both have the same understanding of the solution, but most will know and expect that answer and will be all too happy to move past it to something more exciting. For coding interviews, yes you need to get some code on the board, but if you're targeting the 50-line solution in the given time you're doing it wrong. You also need to demonstrate good programming technique, which means helper functions, library calls, whatever. I'd rather see a complete algorithm that calls five helper functions, and then ask the candidate to code one of the helpers really well. That's solving the problem together with cleaner code and a chance to fully discuss program flow and data manipulation. I don't believe I've ever used a hypothetical question that has multiple parts. Instead the conversation starts by establishing reasonable expectations (limits) which can be broadened afterwards. "What if the customer really wanted support for feature X?" is a more realistic motivator than "Okay now solve it for n=4". I still see it a lot from interviewers using trivia/homework exercises though because there's little opportunity for extension. On the other hand, if some asks you FizzBuzz, it's a good bet they want to see the code. PhantomOfTheCopier fucked around with this message at 02:07 on Oct 23, 2019 |
# ? Oct 23, 2019 01:42 |
|
PhantomOfTheCopier posted:I don't believe I've ever used a hypothetical question that has multiple parts. Instead the conversation starts by establishing reasonable expectations (limits) which can be broadened afterwards. "What if the customer really wanted support for feature X?" is a more realistic motivator than "Okay now solve it for n=4". I still see it a lot from interviewers using trivia/homework exercises though because there's little opportunity for extension. That's what's meant by multiple parts, though. The classics being "now what if your grid is sparse and 1000 times larger" or "now let's say you cannot hold everything in memory at the same time" or "ok, let's say that this particular API call is both blocking and has high latency, is there a different way to do this that would work better for that case?"
|
# ? Oct 23, 2019 05:02 |
|
Does anybody here have 10% time/freestyle time at their workplace, and if so, do you take advantage of it? Has it been well received? How useful/worthwhile has it been?
|
# ? Oct 23, 2019 17:57 |
|
At my company, the assumption is that you are working on things you can learn from, so it should be a technical project, rather than say gardening... I take one day every second week instead of taking half day every week, because it works better for me, and never had any problems with it.
|
# ? Oct 23, 2019 18:03 |
|
I had it at my last job. My boss just gave it to us, no idea if upper management knew. The idea was you had development goals in Workday, and you would use the 4 hours a week to work towards those goals.
|
# ? Oct 23, 2019 18:24 |
|
I've got 20% time, but I've only briefly used it once. I just haven't had anything come that I've been passionate about enough while also interruptible enough for it to make sense.
|
# ? Oct 23, 2019 18:28 |
|
Pollyanna posted:Does anybody here have 10% time/freestyle time at their workplace, and if so, do you take advantage of it? Has it been well received? How useful/worthwhile has it been? I'm getting 10% time at my new job I'm starting on Monday, I've never had it before, so I'll be curious to see how it works in practice!
|
# ? Oct 23, 2019 18:30 |
|
I've never had 10% time, even when I worked for AWS, but I've had plenty of managers and directors claiming they wanted their teams and orgs to make time for it. They followed one week later with 20% more work though, so it was clear they were just pandering. Yet another "what's good for Google is good for the world". The closest I saw was when the director announced it during a staff meeting. Everyone got excited and started their list of what to learn to boost their creativity. A week later we got an email about "approved projects for 10% time". Volmarias posted:That's what's meant by multiple parts, though. The classics being "now what if your grid is sparse and 1000 times larger" or "now let's say you cannot hold everything in memory at the same time" or "ok, let's say that this particular API call is both blocking and has high latency, is there a different way to do this that would work better for that case?"
|
# ? Oct 23, 2019 22:35 |
|
I had a team at an old job that experimented with 20% time, and you were ostensibly supposed to work on your project on Fridays. What actually happened was it was more like 120% time because it was a team-only initiative and leadership kind of sucked at protecting our time from others. You still had to get all the same amount of work done and make progress on your project because the bosses wanted to see results justifying the 20% time initiative.
|
# ? Oct 23, 2019 23:27 |
|
kitten smoothie posted:I had a team at an old job that experimented with 20% time, and you were ostensibly supposed to work on your project on Fridays.
|
# ? Oct 24, 2019 03:48 |
|
My old job had 20% time, but I was basically the only person in the company that took it. It was cool though. Eventually I ended up in the same boat as everybody else: “x needs to be done, no time for 20% this week” every week. By that point, I’d done a handful of 20% projects that got me little or no intra-company recognition, but did get me a decent cert and some conference talks. I’d say the program worked pretty well My current job has 20% time, but they straight tell you in orientation that if you don’t want your career progression to suffer, you better make sure that the project you want to do 20% work on is on your team (or personal I guess) OKRs. This is fine for e.g. dev work, but it makes it kind of rough if youre interested in doing 20% work in a totally different area (eg humanities or social science research) Tbh I could probably get a 20% okr added for the work id like to do because my eng manager and program (or is it project?) manager both rule. But I haven’t tried yet and don’t know if I will in the near future
|
# ? Oct 24, 2019 04:57 |
|
Hey guys, so I’ve been in my new job for a month and a half now and it’s going very well. People are cool, overall environment is positive and rewarding. It’s amazing how much better I am at things here now that I’m no longer being poo poo on all the time or feel like I’m being set up for failure every sprint. Also the absence of sexist dickholes is a huge plus. And it’s really nice being on a dev team that has an even gender ratio. However, the front end codebase is an ungodly nightmare and the more I delve into it the worse it gets (the dev responsible for architecting it is no longer with the company). It’s inconsistent, brittle, convoluted, difficult to read, inefficient, and contains all sorts of duplication (like three components that all display the same options list, just in slightly different contexts). A lot of it is sheer sloppiness and cutting corners without regard to maintainability or other developers working on it down the line, and the rest is a bunch of misapplied overwrought patterns. The whole thing is eligible for Coding Horrors, pretty much. The upside is that the next major version is substantially different enough that we can justify a ground-up rewrite in which I get to take charge of structuring and building the view layer (after designing the UI ) and can Do It Right This Time. Looking forward to some greenfield work and getting away from attempting to improve and maintain a thing that is unmaintainable and strongly resistant to improvement. edit: Oh hey lots of posts happened while I had the reply open. My previous job started doing a yearly personal goals thing with some small fraction of work time dedicated to it (which quickly turned into on your own time, and it was required and would be talked about in your performance review). I designed myself a cool project with crossfilter.js to improve a neglected event log display in the application, but my boss later canceled it because I guess the lead dev didn’t want anything encroaching on his API work. My new job doesn’t have anything explicitly, but we’re encouraged to spend time here and there learning new things and being inquisitive and whatnot, and to go home at a reasonable time and have a life. Queen Victorian fucked around with this message at 06:58 on Oct 24, 2019 |
# ? Oct 24, 2019 06:40 |
|
That is very nice to hear, Queen! Here's hoping the honeymoon phase lasts a while. I never worked somewhere that had 20% time but was subjected to so called Innovation-sprints, which are appearantly a two week period where "engineers can focus on what they want and do some real innovation" which always turned into "but it has to be useful to the business and how will our users benefit from this?". I tried explaining that this has a chilling effect on the goal of innovation but yeah, cynical old fart and so on. So I mostly spend my time cleaning up tech debt that I found annoying.
|
# ? Oct 24, 2019 07:20 |
|
My company doesn't really do 10/20% time as much as 100% on whatever else you'd rather work on time. For example, recently some engineers started a separate project that was more important to finish than the one they were working on because it turns out it'll help us leapfrog incumbents in a vertical we're after and they got approved to fix it in a 2 week sprint within about like... 30 minutes of explaining to their manager how important it is and how much time they think they'd need. The push-back is usually around "are you sure it's only 2 weeks?" rather than whether there's clear value. Most of the engineers with the balls to suggest anything have thought it through and PMs are only there to block if there's something pressing requiring all our attention like a big compliance or platform change that could impact all our customers and teams. Our project management rigor is kind of garbage, but we get what needs to be done with pretty decent quality given our resources which is more than what I could say for other companies of similar size I've been at that had significantly better project management but much worse output.
|
# ? Oct 24, 2019 13:45 |
|
I'd be pretty satisfied if 20% time was just being able to pick anything from the backlog so I could just spend it on technical debt
|
# ? Oct 24, 2019 16:05 |
|
Queen Victorian posted:Hey guys, so I’ve been in my new job for a month and a half now and it’s going very well. People are cool, overall environment is positive and rewarding. It’s amazing how much better I am at things here now that I’m no longer being poo poo on all the time or feel like I’m being set up for failure every sprint. Also the absence of sexist dickholes is a huge plus. And it’s really nice being on a dev team that has an even gender ratio. I'm glad things have gotten better!
|
# ? Oct 24, 2019 16:33 |
|
Makeout Patrol posted:I'd be pretty satisfied if 20% time was just being able to pick anything from the backlog so I could just spend it on technical debt The exception is for junior developers who get 20% time to work on things outside of their team, like other projects or organizing meetups etc.
|
# ? Oct 24, 2019 16:55 |
|
We don’t have 20% time but we do spend three days a quarter in a company-wide hackathon which I thought was stupid when I first heard about it but worked out really well.
|
# ? Oct 24, 2019 17:14 |
|
I once worked on a team that had "fix-it Friday" where each dev would spend Friday trying to fix any bug. It was good for morale and our software.
|
# ? Oct 24, 2019 17:20 |
|
raminasi posted:We don’t have 20% time but we do spend three days a quarter in a company-wide hackathon which I thought was stupid when I first heard about it but worked out really well. The one time we tried to do a hackathon at my old job, our manager had to approve it and never did despite us talking to him about approving it on several occasions. Said he would, never did.
|
# ? Oct 24, 2019 17:29 |
|
raminasi posted:We don’t have 20% time but we do spend three days a quarter in a company-wide hackathon which I thought was stupid when I first heard about it but worked out really well. How did it work out well? Anything specifically happened/came out from it? I do think that hackatons are there for the company to reap a benefit not for you, the employee, but maybe I've been looking at them wrong.
|
# ? Oct 24, 2019 18:36 |
|
Volguus posted:How did it work out well? Anything specifically happened/came out from it? I do think that hackatons are there for the company to reap a benefit not for you, the employee, but maybe I've been looking at them wrong. Preferably, it's good for both of you. Engineers get to take a break from their normal work, stretch their legs, and just work on something they decided was interesting for a week. It's a nice mental health break. Employers get a minor bump in productivity after, potentially new skills for their employees, and possibly the start of a new, unexpected product.
|
# ? Oct 24, 2019 19:36 |
|
Queen Victorian posted:Hey guys, so I’ve been in my new job for a month and a half now and it’s going very well. People are cool, overall environment is positive and rewarding. It’s amazing how much better I am at things here now that I’m no longer being poo poo on all the time or feel like I’m being set up for failure every sprint. Second, I got a little misty because I realized that "I'm being poo poo on all the time and feel like I'm being set up for failure", which is one of the reasons I'll be taking part of my forthcoming day off to check the world of job openings. I don't claim to have anything quite as egregious as you, but my team is consistently playing this game of "we approve of all the design details... (work done)... we don't approve of what our packages require to ship those design details". Given that I don't see this with other code reviews, I'm starting to feel singled out. Yeah "if there's always a problem when you're around the problem is you", but in this case I think I'm just not the best person to support the team's passions at this time. Anyway it took multiple iterations to learn the right balance of "sticking with it" and "knowing when enough is enough". Glad that you've started a bit earlier learning that.
|
# ? Oct 24, 2019 23:16 |
|
raminasi posted:We don’t have 20% time but we do spend three days a quarter in a company-wide hackathon which I thought was stupid when I first heard about it but worked out really well. Vulture Culture fucked around with this message at 01:51 on Oct 25, 2019 |
# ? Oct 25, 2019 01:46 |
|
Vulture Culture posted:The 120% time concept was something Marissa Mayer talked about when she moved to Yahoo. Stuffing it into the end of the week is one of the worst possible ways to exercise it, thoughone of the main values is that it gives people something to work toward to break the monotony of whatever other thing they have to work on, to help people keep energy levels up. It benefits absentee managers, but rarely other employees. Yep. The idea with Fridays was that they could declare No Meeting Fridays and theoretically give you an opportunity for some deep work time on your 20% project. But instead No Meeting Friday becomes a release valve for all the time pressure you had built up during Full Of Meetings Mondays Through Thursdays.
|
# ? Oct 25, 2019 03:38 |
|
i was at a place that started "no meeting wednesday" and it quickly became "i know you're in your cube, sucker"
|
# ? Oct 25, 2019 03:42 |
|
Protocol7 posted:The one time we tried to do a hackathon at my old job, our manager had to approve it and never did despite us talking to him about approving it on several occasions. Said he would, never did. I think it being company-wide is an important part of avoiding this trap. Even if my manager were a shithead, his boss wouldn't be expecting our team to be getting anything done during those three days. And our PM loved it too because he could just put his own head down and burn through some stuff that required him not to be in meetings six hours a day. Volguus posted:How did it work out well? Anything specifically happened/came out from it? I do think that hackatons are there for the company to reap a benefit not for you, the employee, but maybe I've been looking at them wrong. The company definitely reaps a benefit, that's why they happen. But it's not like you have to get approval for whatever you're going to do ahead of time, or justify anything you do afterwards. You can gently caress around doing whatever you want. Hell, you could probably spend the whole time playing video games at home in your underwear and nobody would even notice. I didn't see one of my teammates for three days because he was teaching himself React Native on a different floor. As for concrete benefits, among others, we got some performance wins from a team that got to just sit down and try to optimize poo poo without worrying about whether they could justify their attempts in planning; new feature prototypes from developers who had ideas they couldn't get into the normal product pipeline; a group of new moms who put their heads together to make a scheduling system for the pumping room; a bunch of non-engineering teams borrowing engineers to do little side projects to improve their quality of life; and my personal favorite: an anonymous engineering salary spreadsheet. The best case outcome is a bunch of stuff that's definitely worth doing but doesn't fit into the normal planning cycle. The worst case outcome is engineers learning things. Vulture Culture posted:I will continue to bait you until I figure out who you are That reminds me to try to get into our Slack.
|
# ? Oct 25, 2019 04:57 |
|
Did someone say Hackathons? The latest trend in out-of-touch Management trying to emulate other, notable companies without understanding why it works there? Or perhaps it's just my excitement in the recent announcement that we're going to be getting a dedicated Hackathon Week later this year! To...work on backlog items. You know, if those pesky stories we care about aren't being prioritized, then we get to...do our normal jobs...for a week. But hey, the company is printing up stickers and posters and paying the marketing artists a bunch to brand this internal event
|
# ? Oct 25, 2019 09:11 |
|
How do hackathon teams' projects actually get included in production repositories? We have an open event coming up next month, but even with project proposals required a couple months before the event, I don't see even the working code getting included because it assumes the owning team can handle the increased maintenance costs. ("Shiny aluminum siding bro, but where's that going on my brick house?") Has anyone seen successful integration of hackathon code? Oh yes, the other problem with interview a la programming homework that I just witnessed a few days ago is scope limitations: Problem is so easy that you have ten spare minutes in the interview and no more code to discuss.
|
# ? Oct 25, 2019 10:55 |
|
PhantomOfTheCopier posted:How do hackathon teams' projects actually get included in production repositories? We have an open event coming up next month, but even with project proposals required a couple months before the event, I don't see even the working code getting included because it assumes the owning team can handle the increased maintenance costs. ("Shiny aluminum siding bro, but where's that going on my brick house?") Has anyone seen successful integration of hackathon code? I converted a hackathon project into a product offering a few years ago. Pokemon go had just come out and the mobile company I was at had some people wanting to do a location aware service, grabbed front end engineers, backend, and had a POC in a day or so. I partnered with a game team to get them to A/B test it in a release and worked with other locations on having it be a formal offering. EDIT: same place earlier someone did a hackathon of porting an iOS game to OSX and they did the extra 2 weeks of work for it to be legit part of the build/release pipeline and it accounted for 8% of gross bookings after that.
|
# ? Oct 25, 2019 14:23 |
|
Generally in a hackathon you build a proof-of-concept, if people actually like it and the concept is proven then you get real time budgeted to make it actually happen. This could be integrating the hackathon code, or it could be rewriting the project entirely now that you're not making hacks and design compromises to go from zero to proof-of-concept in a few days.
|
# ? Oct 25, 2019 16:47 |
|
In my experience Innovation Sprints were enjoyable but mostly entirely useless dog and pony shows that were left to rot on the factory floor at end of the Innovation Sprint. You’d see new engineers come in excited and creating really interesting stuff and then after two or three Innovation Sprints they’d just concede to fixing tech debt like the rest of us because very few want to champion finishing an entire feature in their nights and weekends.
|
# ? Oct 26, 2019 19:47 |
|
Yeah, at my old job the innovation sprints were almost always used for tech debt and related tasks. What few ideas people did have never really matured past infancy if they even made a PoC for it. Some of the most useful things people did were come up with utilities to help automate, or simplify some dev processes. Most of which were born out of frustration. Turns out having a real problem is a great motivator for problem solving!
|
# ? Oct 27, 2019 05:05 |
|
|
# ? May 24, 2024 21:08 |
|
The most depressing thought of actually doing something cool and marketable and pushing it to completion without input from above is your effort and work gets devoured into the maw of the people above you.
|
# ? Oct 27, 2019 06:03 |