|
im the student padding their first industry resume with things like "plays guitar", "did unrelated activity x" in highschool, or drops refs to "real passion to teamwork"
|
#
¿
Jan 27, 2018 17:52
|
|
|
|
| # ¿ Apr 27, 2024 00:14 |
|
|
I mean I get how it is and never judge someone negatively about it, because we all went there (at least I did), but oh man is it always fun to see how they tried to pad the stack.
|
|
#
¿
Jan 27, 2018 17:55
|
|
|
I've seen a lot of students just put their homework on github once it had been turned in.
|
|
#
¿
Jan 27, 2018 18:55
|
|
|
might be shorter to ask the teacher for the permission (or giving them a heads up) than spending all your free time on side-projects to fluff your job applications tho
|
|
#
¿
Jan 27, 2018 21:36
|
|
|
cheque_some posted:internal transfers suck because you always end up still getting called for help from your previous group I got that but with please help us with an incident, roughly a year after I had quit that job
|
|
#
¿
Jan 31, 2018 13:11
|
|
|
interviewed a dude who was technically very proficient and we intentionally threw some easier vague beginner technical questions like "explain to me how x works" or "can you tell me the difference between x and y?", and the guy seemed visibly flustered as if that stuff was beneath him and later ended up leaving very quickly without waiting for info on when he'd be called back. I think the dude implicitly failed the "can you, as a technical leader, explain things to junior members of the team" part of the interview without realizing it.
|
|
#
¿
Jan 31, 2018 16:13
|
|
|
MononcQc posted:interviewed a dude who was technically very proficient and we intentionally threw some easier vague beginner technical questions like "explain to me how x works" or "can you tell me the difference between x and y?", and the guy seemed visibly flustered as if that stuff was beneath him and later ended up leaving very quickly without waiting for info on when he'd be called back. dude got mad and e-mailed HR with a terribly written quebecois insult e-mail before HR had even reached out to him. Here's my rough translation of it, with fewer typos than the original, but I kept some for the feeling of it: quote:hey there u lil loving nerd of loving pseudo success so uh, our hard pass is validated E: example for the liberal translation: the original text contained 'criss vs un objet da ltra de q' is what I guess is "crissez-vous un objet dans le trou d'cul". I don't know if the dude tried to bypass email filters but the literal equivalent would "gently caress u an object in ya rear end hal" MononcQc fucked around with this message at 16:55 on Feb 7, 2018 |
|
#
¿
Feb 7, 2018 16:48
|
|
|
I have no idea, but all I can think is that at least the feeling of not working together is fully mutual. Hooray for preventing a technically competent person but also gigantic manbaby from joining the team.
|
|
#
¿
Feb 7, 2018 17:14
|
|
|
The Leck posted:"but unit tests just slow down development because 1) you have to spend time to write them, then 2) you have to change them when the code behavior changes!" - my (thankfully former) architect and multiple team leads if the behavior keeps changing so often writing tests is a major slowdown rather than a crucial safety net you might just be writing a prototype that's gonna be pushed in production.
|
|
#
¿
Feb 24, 2018 02:27
|
|
|
cis autodrag posted:I wish anyone would ever give me time to prototype in my whole life but my experience so far in my career is that prototype to prod is a result of external pressures from people up or downstream the way I try to counter this kind of pressure is by figuring out what the big uncertain stuff I know too little about in the project, and what I feel confident about. The uncertain stuff is what I test in the prototype and take measures for (and probably write tests to even make sure it works). The stuff I'm more confident on, I half-rear end and make sure it's below acceptable when finishing the code. I try to couple that with frequent progress reports so nobody has too bad of a surprise. So the ideal situation once the prototype is done is "we've got this thing that is just not good enough to go in prod, but the good news is we figured out the hard parts and can possibly keep them." Hopefully by then you get the time to extract that critical stuff (or rewrite it) and wrap it up with the rest of the code you should already be more comfortable writing. I'm probably arguing that iterative development shouldn't be done with an end-to-end prototype that then gets improved, but with a uncertain-bits-first approach. If what you're the least certain about is whether customers will even want the product, then 'prototype to prod' may be entirely reasonable as an approach because that's the biggest risk to tackle and figure out at that point, but I think it's usually good to put a fatal flaw in the prototype that prevents it from being possible to make prod-ready without some big reorganization.
|
|
#
¿
Feb 25, 2018 15:01
|
|
|
iirc I enjoyed the data structures chapter in Skienna’s algorithm design manual for the decent overview. most of my data structures learning though was going on a Wikipedia page for like AVL trees, making an implementation of it, then going to related pages and going at it again. if you’re looking for functional stuff, nothing beats Okasaki’s book.
|
|
#
¿
Feb 28, 2018 04:58
|
|
|
FMguru posted:of course, all this applies in the reverse too. really good companies dont have lots of open reqs and turnover. the counterpoint to "if youre such a good worker, why are you unemployed/unhappy with your current job" is "if your company is such a great place to work, why is this position even open for applications" I don't know that this is necessarily true, depending what you consider 'lots of turnover'. People come and join and leave companies all the time for reasons that may not be related, based on what they are looking for right now in their personal lives, and the lives of their families also impact things. If you have a really solid company with absolutely competent top-level staff, you have to expect not to have enough high-ranking positions for all the junior employees you are also great at training right now that some of them will be poached and will leave, just because there's an upper bound to higher-level positions you can have. Like what would you do with 150 tech leads and level whatever senior devs and 4 juniors? Is this a possible thing? Probably not. Turnover rates that are too low can in fact be a sign of an unhealthy work environment as much as high turnover rates. Very low turnover rates are at times associated with a business that cannot get rid of its bad/under-performing/unambitious/toxic (depending on the source) employees, weak managers who can't get the guts to fire anyone even if they should, or it could mean anything like permanent under-staffing in a geographically isolated area (nobody can leave, nobody's getting in either). If you are growing and are hiring N people a year and are not even losing a few of them because they are not fitting in, they're misbehaving, or not progressing and adapting the way you thought they would, you either have the secret hiring sauce with amazing on-boarding and constant training without any skill ceiling, or, more likely, something is not working great. Like 20% turnover is probably high as hell, but then 5% may be rather worryingly low if you're not in a highly specialized area with low competition.
|
|
#
¿
Mar 19, 2018 18:51
|
|
|
An experienced generalist is not just someone who goes and knows the surface of a bunch of technologies, it's a person who knows a vastly satisfying amount about multiple techs. A workplace should see their value. They are going to be those employees who can break the silos of various teams or specialities on a team, and can foresee issues in interactions with other components in an entire stack. There's nothing more easily preventable than a guru in fancy algorithms for rendering or physics simulation not having the breadth of experience required to write safe, performant SQL queries. Your good generalists skip over the borders between circles of expertise in an organisation and carry valuable information and experience with them. A team that recognizes that and makes use of it will get much better results than one who builds disjoint circles around experienced experts who do not communicate enough or can't get a vision on a broader area than the one they are an expert in. In a small business or agency, where the workload varies a lot over time depending on contracts, a good generalist is the last person fired (after the boss's family) because they can replace, at least for a while, most other employees in some area. The generalist is more easily replaceable by any expert in one single area of work, but can also offer the most bang for your buck when the job is not always being specialized. Knowing a bit of everything is worth more than a lot of a few things when the nature of your work is that you do a bit of everything! Expertise does come with higher salaries, but a higher long-term risk. If you made your reputation in interactive games and sites by focusing a few years in Flash to the point of being an expert about it, and that that market dies with one iPhone release, you probably have to start from further back than a bunch of people who already knew far more varied pieces of tech and for whom their general experience can be reused better in new environments. What I find happening is a kind of oscillation between generalisation and specialisation: try a lot of things, dig deeper in one you like, and once you're solid enough there, start looking a bit around again to prevent yourself from walling you in. Notorious b.s.d. is kind of right in saying that domain expertise is what is really worth it, but I think it's a bit larger than that as well. Any cross-competencies can end up being real useful to people who need them. I'm an expert at Erlang and whatnot, but what makes me worth hiring the most is that I also ended up having decent competences in system design, training and teaching, documentation writing, and operations. There's one expertise where people find me, but it's the other things around that makes me better suited at say, building a team made out of people who never used functional programming before, than someone who only knows the tech stuff very well.
|
|
#
¿
Mar 24, 2018 18:11
|
|
|
If you like the idea of being a generalist and advertising yourself as such, look for jobs that have a polyglot environments. They are a bit more likely to understand the importance of a generalist there.
|
|
#
¿
Mar 25, 2018 16:01
|
|
|
people need to receive peopleware as mandatory reading
|
|
#
¿
Apr 6, 2018 18:10
|
|
|
Arcsech posted:senior engineer at work basically told me to start looking for new jobs because our upper management blows rear end today Heroku might fit some of these criterias -- hiring US remotes with JS and some front-end and tools teams also do Elixir. But there also be a bunch of go in there
|
|
#
¿
Apr 11, 2018 14:17
|
|
|
Notorious b.s.d. posted:stock in a non-public company should be valued at $0 for comp purposes you can still get some dividends out of it; you can ask what it is, but it's almost guaranteed to be a fraction of what you'd get otherwise. I.e. it's possible you get like $500k in options of a private stock (the value of witch is usually defined by the CFO or whoever crunches their fictional numbers), but the dividends you get every year out of it may be only like $2k at most, and unless the company goes public soon or has an explicit buyback policy, you'll never get to sell that $500k and can only get the $2k/y in dividends.
|
|
#
¿
Apr 16, 2018 15:46
|
|
|
most companies are not the size or do not see the traffic necessary to have engineers spend time making sure there are no points of failure in the infra when a 5-10 minutes outages with a person restarting a server is going to be fine for most cases. Those that are really nervous, like stores around black friday, can just overstaff or overprovision for a few weeks a year. Chaos engineering when done netflix-style is usually done by purely online businesses that have engineering departments in a good enough shape to want to purposefully cause small outages to prevent larger ones. Most places are not at that stage to begin with.
|
|
#
¿
Apr 26, 2018 23:12
|
|
|
Sapozhnik posted:when you've got a working set that can't fit into a single instance's ram then you start thinking about application level sharding They probably don't have that much data in terms of absolute storage (I'd bet all poo poo like videos and images get thrown in a separate store and they just keep a ref/URI in the main DB), but thing is you can get really loving far with just sharding.
|
|
#
¿
Apr 27, 2018 22:24
|
|
|
Since the local interviews are soon, tell them you're a bit busy because things are hectic right now and may need a few days/weeks before being able to leave and will confirm dates later. If it works with one of the local ones, say that things changed and you have to no longer pursue things with them (but are open to blah blah later) and if it bombs with the local ones come back with "sorry about the delay, would your team be good with day x? I'm free around then" and see how it goes. They won't and can't ask details, and I'm frankly pretty certain they'll be understanding if it includes flying people out.
|
|
#
¿
May 1, 2018 01:19
|
|
|
Notorious b.s.d. posted:i would think about this long and hard, especially if you are at the beginning of your career. remote is a big ole poo poo sandwich, and the poo poo's piled deeper for younger, less senior staff The stuff you're describing is really the experience of someone who is the only remote employee in a team. If you are working on an actual remote team (with more than half of the employees also being remote), then you are not losing on chances to learn, you're probably getting more of them: technical discussions and decisions are likely all discussed and documented through some long-standing medium, whether through mailing list archives, issues, or whatever. Frankly, a good distributed team can operate a bit like an open source project would. What's interesting is that instead of only being part of interesting discussions if you happen to be at the right lunch table or watercooler, you can just subscribe to about anything and go learn about whatever you want. I've found office work to be drastically less prone to knowledge sharing because you tend to get far more restricted in terms of scope of what you can get. ADINSX posted:Seconding (or whatever) the opinion that remote work sucks. Don't under estimate the importance of getting lunch with the team, after work beers, etc. Not only is it good to make personal relationships with your peers and possibly higher-ups, but these outings inevitably talk about work, and its a good time to shine especially if you're more junior (maybe you're not invited to the big design meeting, but you can always bring up ideas informally) That definitely depends on personality, I find. I also think it's kinda bullshit if you have to hang out with people after work to talk about work in order to be good about work. I'd just get out of there and go for a place where coworkers can talk about something else than work when away from there.
|
|
#
¿
May 3, 2018 01:57
|
|
|
Notorious b.s.d. posted:(emphasis mine) I've learned more from online communities and open source projects than I have from most face-to-face interactions put together hands down. If you work in any kind of office that looks somewhat open plan, where folks have headphones to help focus and you ping them on chat or send e-mails rather than getting up and walking to their part of the office just to ask a question, congratulations, you have just replicated most of the remote experience except you commute to do it and likely are in a high cost of living area for it. This is my 4th remote job now. Heroku was the third. I liked remote before, and I still like remote after. There are some teams or places where the work culture just isn't amenable to it, and there are places where it works fine. I can easily imagine an extroverted person who loves facetime hating the remote experience, but I tend to like being in calm and silence to focus on whatever, and being around larger crowds tires me out. Any time I visit coworkers on-site, I end up doing nearly no work whatsoever and I am 3-4 times more tired than any other day anyway, and that's usually without even requiring a commute because I get a hotel nearby. I get you consider remote teams to be second rate. I simply disagree and would think that a team for which it's impossible to work remotely probably has implicit communication patterns and power dynamics that turn out to be counterproductive in the long run, informally institutionalized within a circle of a few long-standing employees that just walk around and somehow turn out having untraceable impact on a fuckton of projects just because they hold some perceived authority or get to talk louder. The teams and companies I worked at where alignment, processes and decisions were the clearest and best explained always turned out to be those that were remote-friendliest because this was the only way things could actually work fine. The good thing though is that working remotely with someone like you on the team is probably what would make it a second rate experience for me as well, so as long as we don't get to work together, I bet we'll be fine.
|
|
#
¿
May 4, 2018 01:26
|
|
|
attn: long care post on communication patternsNotorious b.s.d. posted:this is how actual human cultures work. implicit communication. organic formation of working groups. informal institutions. overlapping circles. walking and talking. This is how they work informally, but this is also how they break down over a long period of time. The most informal level is nobody writes down anything aside from code. They talk it over whatever open space isle of desks they have and come to an agreement and move forwards. Done deal. Maybe they have a few post-it notes, But this has a scaling limit, and does not let you remember things for very long. The moment you have enough devs to fill more than 1-2 rooms, these patterns start to break down. You get the same issues because not everyone is in the same room for the same conversations; employee X who is kind of essential to this has moved on to the platform team, on which you are not, and so they need to be dragged into every meeting even if theyre not relevant in case their help is required, or someone has to ping them and ask them to come (or leave their team's room to go meet them). The points of contention in collaborative efforts in tech tend to break down according to the communication channels you have. So you move on to the next levels of communication patterns, those that are more durable, because they make it simpler to work with all the folks in a growing org. Does your organisation not do retrospectives, postmortems, track projects on tools where people can see what happen, use bug trackers, CC important decisions to their managers, write onboarding documentation for new hires, procedures for operations and so on? If so, congratulations, you've dropped informal natural communications in favor of a more permanent kind. It starts to feel more enterprisey, and it is. Do you go the level above and schedule meetings in calendars and then have someone take down notes of what happens and e-mail them to folks afterwards? You don't for some meetings probably (because who cares we're 3 devs on the team just loving do it and add a comment to the ticket) but do for others, in all likelihood. Those are all traces that you leave through more official media in order that institutional knowledge doesn't get lost. Now imagine if instead of asking someone to take notes for a meeting to e-mail it later and then half the time forgetting to do it, you had a trace of these interactions: chat logs, e-mail threads, and the same reliance on all the other tools, etc. My anecdotal experience is that teams that are super-local and never adopt these tools are great at moving fast locally, but whenever you try to make larger changes that requires the coordination of 3-4 teams, it's suddenly a total shitshow of nothing working right. Either you need to re-shape the org to fit the project better, and some people get the short stick of acting as communication emissaries that end up sitting in 18 hours of meeting a week across all teams to make sure they repeat the same info to everyone every day, or you change how you work. Basically, my whole point is that as organisations grow and need to gain more permanence, they tend to automatically gravitate towards tooling that are remote-friendly. If you've been to a place where people draw a diagram on a whiteboard, then take a picture and e-mail it to themselves for archival purpose, that's a good place to improve tooling! Get one of these boards that tracks pens and automatically records the drawing session and images and it's better. Get something like a microsoft surface, or any drawing software that accepts working with a tablet (just project it on a bigger screen, which you should have anyway if you are doing code walks or just collectively check your progress in whatever tool you have), and chances are you now get collaborative whiteboard sessions across physical sites out of the box. An organisation that is remote-friendly is also likely to be friendlier to cross-team projects of a larger size because they'll have similar communication needs. If you do neither, you'll be almost guaranteed to land into this thing where nobody understands why this simple project that would have taken their team 3 weeks is now on its 6th quarter of allotted time and no closer to being delivered. The answer is almost never that the tech was bad, and always that communication patterns broke down. Notorious b.s.d. posted:i don't want my day job to be run like an apache project. clarity doesn't come for free I've never worked on an Apache project so I can't compare the experience there. I'm working at a company that's a bit of the opposite right now. They are so married to local tribes that there are 3-4 key dudes that need to be dragged by the arm across campus buildings for every significant meetings because after 20 years in this company, they still only have oral communication patterns. Nothing gets written down unless it's been done by the technical writing department, or the project tracking because they check time budgets with it. I've had to sit on meetings/discussions where 15 minutes breaks were taken as people were looking for that one person they need to ask a question to right now because none of them use chat nor use e-mail with any semblance of care in the world. They have the tools, but do not use them. It has been 100% impossible to work remotely with them because they're just not amenable to that, and I ended up pairing with most of their satellite offices because they feel the same problems with the main one, but are able to communicate with each other. This organisation basically ended up having the big central set of offices that work on some kinds of projects, and all the satellite ones that collaborate on other ones, because it's been essentially impossible to get them to cross the gap and talk to each other well, mostly because the central one has a one-way communication channel where they receive information but let none out. --- TL:DR; lax informal communication patterns are super fun but only work great for small local projects and teams. The moment you need to work on larger systems or products with bigger teams, you tend to naturally get more permanent communication media and those are usually good for remote anyway.
|
|
#
¿
May 4, 2018 12:50
|
|
|
Notorious b.s.d. posted:this describes every successful business organization in the history of mankind. like this is the very heart of the theory of the firm There's types of distances other than physical. One simple example being organisational distance: if you have to collaborate with person X from team B, how easy is that to do? Can you get their time to work on things or help you with it? Does it involve asking permissions and going through layers of management? A distributed team (or hell, even a team at opposite ends of a single city) where cross-team collaboration of that kind is simple is likely to get better dynamics than one where teams are silo'd by organisational design even if they were all in the biggest open floor plan you could imagine. An easy way to think about that is to wonder how easy it is to grab a UX, or say marketing or manufacturing person for a project that is led by software groups. Then flip it around. When they have a question, how do they do it? Do the questions even make it to the people at the sharp end of business, or are all the questions having to bubble through a couple of layers of management each way? When was the last time they talked to you? There's really a fuckton of cases where even if people are physically close, they're still distant and unavailable, or where the current team and company culture basically never encourage these interactions and possibly frowns upon them. If you have a physically colocated team where that cross-communication is still simple and encouraged even with hundreds of employees, that's great. Notorious b.s.d. posted:my company has several skyscrapers in manhattan alone. this is not cheap, and it is not accidental The emissaries are managers when you have a company whose influence structure is mainly defined by its org chart. The emissaries are going to be first-ten-employees ICs when they've been dev-centric with a rather flat org and lots of informal communications for most of their history. The emissaries are going to be generalists who are loaned from team to team or move around the company when cross-domain projects take place. The emissaries are going to be your SRE team if you have it when what you get are weird bugs where they end up having their ear to the ground for all of that. If your only emissaries are managers, then you probably have a low cross-team collaboration environment with limited horizontal mobility, or a top-down management structure that basically aims to isolate groups from each other. There's no reason for this to be the only model. quote:process and formal communication are not free; they're not a tickbox on "we're a big boy company now" Agreed. But you know, It's kind of nice to have a thing where you go into a project log and go: we considered options x and y, and the 4 devs on the team agreed to try option z instead and so we ran with it. Put it in a code comment, in a wiki, in a ticket system, in an e-mail thread, in a google doc, whatever. Maybe have a document somewhere with the list of certs and when they expire and who owns the accounts. Same for domains. Then maybe have a short doc explaining how to install and build most software so that when an intern or a new employee joins, they don't require a few days of senior dev time to set them up. You know, enable yourself not to be interrupted for basic questions. Save time by taking the time by making some info permanent. IMO that should be the bare minimum requirement for any important tech decision you embed in your tech org. If that kind of poo poo is too mind-numbing for your water-cooler fuelled team, holy poo poo what kind of debt are they leaving for the future generations of developers that will replace you? A legacy system is a system where people don't know how it works and are afraid to change it. Keeping all institutional knowledge by oral tradition and campfire-told sagas of the system is a surefire way to create legacy at breakneck pace. Notorious b.s.d. posted:inside your own loving employer you have discovered that "remote" is a weakness and source of difficulty, and you still want to try and spin this? I'm also not blaming these teams for not liking remote. It's part of the company culture, and if it doesn't fit, it doesn't fit. That's why, as I said, I work with satellite offices that are remote-friendly, and it's going fine. I feel like you're taking my defence of remote as an attack on on-site teams. It isn't. On-site teams work very often and it's a functional model. I still recognize the importance of face-to-face time and spend 3-5 days out of every month on-site with the current teams I work with. When I worked with 100% distributed teams, it would be 3-4 times a year instead, and for longer periods of time, possibly renting apartments and whatnot. It's a good thing. I just don't feel it needs to be 100% of the time to work. You're the one here who felt that remote teams were inherently dysfunctional and this is what I am disagreeing with. Not the fact that on-site teams work.
|
|
#
¿
May 5, 2018 04:48
|
|
|
Assuming everything is 100% the same otherwise, with good culture and policies on all sides, then yeah. You do get higher bandwidth communication face-to-face. However, with a remote team you do get a much larger hiring pool, even if you stick to a single timezone, and possibly 'round the clock coverage if you're going for more time distance. You don't have nearly as much facilities to pay either (though paying for home office internet and travel fees for on-site visits is expected), but if you cheap out on that, usually that's bad no matter where or how your team works. In terms of salary though I'm paid literally less than one third what I'd be earning in the bay area, but my buying power is much higher anyway. I can personally buy a house on a few years' salary, have zero commute time or costs, and can work on interesting products without needing to uproot my family or leave friends behind. So of course I will be biased towards that stuff. But basically you could get 3 senior devs for the cost of 1 by going remote. (anecdotal data, Heroku employee happiness for those within fully on-site teams was always rated at least 10% lower than remote teams, no matter how much money the org would pour into all kinds of perks and amenities; the rest being all equal, remotes were generally paid less, were happier, and more loyal. YMMV, I haven't been on a more distributed company so I don't have other stuff to compare, and feel free to dismiss it)
|
|
#
¿
May 5, 2018 19:30
|
|
|
to be honest, being extrovert or introvert has jackshit to do with communication skills, though there may be some corrélations because one practices more than the other by default. Afaict the big difference is whether you draw or spend energy around people, but being a poor communicator would put you in a bad position in any team. like yeah being an introvert probably makes being alone in your home office more bearable or even pleasant, but if you can’t communicate clearly you’re dead meat to an even bigger extent than local teams because nobody can force you to talk. distributed teams require overcommunication to function better, and good communication to function at all.
|
|
#
¿
May 5, 2018 21:37
|
|
|
the trick is to start with them on-site or in an expensive area, and then move out to a cheap place and work remote. many employers won't have the guts to cut your salary, they'll just keep it flat for years instead, but still higher than if you had a CoL-adjusted salary to begin with and then got many promotions (I didn't actually do this, but it was somewhat common pattern for bay area coworkers I had)
|
|
#
¿
May 6, 2018 17:32
|
|
|
Pollyanna posted:ill bet you gotta actually be integral to the company before trying that tho or they’ll just dump you you gotta be pretty integral to be the one person to pull it at a company without remote folks, but if you work at a remote-friendly company it's fairly common because those tend not to see remote employees as second class employees to begin with.
|
|
#
¿
May 6, 2018 17:58
|
|
|
a lot of companies will always try to save money however they can. see: startups buying a ping pong table and nerf guns instead of handing out shares, handing out shares instead of money even when they know they're out of runway, or getting beer on tap in lieu of health insurance. gitlab affords to pay employees living in cheaper areas less because they're a company building tech products employees believe in and will line up to work cheaper for because they like it, the way videogame companies can make folks work overtime more than anyone because there's a million people waiting for the same job at any conditions. Don't expect gifts or decency where none is required. It has little to be related with expected value you bring to the table and everything with what prospective employees will accept to let them get away with. MononcQc fucked around with this message at 21:12 on May 6, 2018 |
|
#
¿
May 6, 2018 21:00
|
|
|
ThePeavstenator posted:help I'm getting an intern how do find the happy medium between micromanaging and explaining everything down to where the power button on the computer is vs leaving them to the wolves 0. Have a chat with them to see where they're at, learn to know them a little bit, see what gaps there may be in their knowledge. 1. set expectations on the kind of work they'll be doing. High level objectives of what you'd consider them to be demonstrating good progress over time. Is it okay for them to ask questions, and if they do, will you think less of them as an intern (the answer should be no, especially not early on; as time goes you may expect them to be a bit more self-directed but it's okay to feel lost at first). When is it okay to ask questions and interrupt you? What kind of work they might be doing, and so on. 2. ask them whether they have expectations, what they'd like to learn or push into. It's possible you'll get a shy answer like "well I don't know" or they may be stumped because what you had in mind for them isn't what they thought they'd be doing. It's possibly a good point to get that clear with them, see if there's any common ground 3. tell them about the tools you usually use, any standards you may have in code or procedures, and give them a tour of the tools. If you have relevant docs, send them links, and make sure they'll have time to get through a bit of them. Present them to the team so they're not afraid to talk to other people either even if you're their main point of contact At any step, let them ask questions or discuss things. If you find out you all develop on platforms they're not familiar with, you'll have to adjust your expectations and provide a different amount of guidance. If there's areas where they don't necessarily know stuff, you can probably show them the basics and broad lines, and then give references to more advanced docs if they need it. Really, talk to them, keep objectives and expectations clear, and also make it explicit that you want to help them succeed. Let them get comfortable with that kind of relationship and it might become a lot simpler to answer their specific needs rather than trying to balance more abstract concepts like over- and under-managing or explaining.
|
|
#
¿
May 13, 2018 03:54
|
|
|
The Leck posted:got an offer, but it's for a pretty significant drop in total comp and a higher cost of living city. not really feeling too confident about negotiating this one to the point where it would be a raise even without taking into account col differences. i'm really sick of the job hunting process, but i don't know that i can bring myself to take this one. aside from being sick of job hunting, the job not being worth it for you at this point is the easiest way to negotiate because you're currently not willing to bend over backwards to go work there and it's now up to them to convince you to go work there. Like if you're thinking of just not taking it because it's not worth it financially speaking, get in there and tell them. This represents too much of a drop, and unless they can make a better or more competitive offer, this is not a job offer you can legitimately accept. They may ask for a figure; give one and it's up to them to match it or not. They might say no, but you were already thinking of not working there, so you've got little to lose there. If they say yes super quick, they were lowballing you and you now have that knowledge for future negotiations with them, and you know there's more money where it came from. If they say yes but take a lot of time to think, you may not get much better than this unless finances or management change at that company, so be prepared to maybe switch jobs in a couple of years to improve conditions if you feel the need for that.
|
|
#
¿
May 15, 2018 14:45
|
|
|
personal story time: I once had an employer that paid me fairly little, and the moment I told them I was leaving for another job and told them the new salary I'd be making (something like 30% more or above), they took less than 5 seconds to offer to match it. That's when I learned that they were really loving happy to under-pay me and knew my real value was much higher than that. There was no coming back from that negotiation. Another company I switched to at another point asked my salary expectations, when I told them, they answered "that's too low" and offered me a bunch money more than that. They got my loyalty for a few years because they showed that they would not just take the money and run, even if I later learned that I was asking below any of the pre-defined salary scales they had and could literally not pay me what I asked because HR wouldn't have let them.
|
|
#
¿
May 15, 2018 14:49
|
|
|
TheFluff posted:despite having worked a lot in erlang and liking functional programming he wasn't a big fan of expressive type systems since he didn't like the compiler getting in his way. 
|
|
#
¿
Jun 7, 2018 15:38
|
|
|
my favorite resumes are those of people who have like 10+ years experience but still have specific sections with listed hobbies like karate or paintball at the end just in case they might be Dwight Schrute
|
|
#
¿
Aug 23, 2018 14:37
|
|
|
Ciaphas posted:
I usually go into interviews and when/if they ask for a programming problem I go "well the simplest solution that can work is this <...> but it will be slower for large inputs. What did you have in mind for that?" Like if they don't give you details, force them to give them to you. Turn the drat interview interactive. "ah yeah if you have dozens of thousands of these, then you might want to sort-then-elimintate. That will change it from O(n˛) to something like O(n log n) since the sort is a boundary there, and the implementation will be simple and predictable. Would that be good enough?" They'd probably hint at "I'm looking for something even faster" after which you get stuck at knowing the trick they expect you to know. You're almost guaranteed to get stuck on some minute details like "oh you need to know if the numbers' negative version is in there, but do you need to know how many pairs of dupes there are?" because for these algorithmic cases, you generally don't have a choice but to exploit one of these corner cases that lets you leverage a data structure or procedure that is more or less well-known. Like the "fill a hash of all numbers that are positive, check the negative ones for a match" works well until you need to know how many pairs match, at which point you need another hash (one to increment on positives and decrement on negatives, one for the total number seen, then do a subtraction of both hashes' identical values to know how many pairs of each were matched). It would be trickier to come up with the general case before the tricky optimized one, and doing it iteratively makes it easier. Even then, you may not find the solution they wanted. But by that time, you've interacted with them, you've been past the initial blocker you had on the simple solution you froze on with, and you've been far enough in the interview and have asked enough questions that the interviewers themselves may start to think "holy poo poo that was a bad exercise to propose" and will take that into consideration as well --- at least as long as you don't visibly ask questions to tank their problem, but really go "here's a solution but is this what you really wanted???" It'll turn their initial judgement from "this idiot didn't know the secret trick to this problem I have known for years" to "well all things considered I liked how they refined things iteratively" or something to that effect. Like the interviewers who put the most emphasis on stupid technical problems of the kind may want to either focus on "can they program loops" in which case it won't matter, or will want "are they clever at solutions" where either you'll have to know the thing first, or play them into showing how you work in a way that changes what they expected to get out of the interview. It won't always work, to be honest. I've had a technical interview turning me down because the 2-3 methods of "finding all duplicates in two binary trees" were not the one implementation they were looking for, but at that point, gently caress these people.
|
|
#
¿
Sep 13, 2018 19:54
|
|
|
I know people who love pair programming and swear by it, but I can't imagine the practice not making me 10x more tired at the end of the day.
|
|
#
¿
Sep 21, 2018 14:51
|
|
|
the first few chapters of the algorithm design manual by skienna is usually pretty good, and it contains a bit of exercises that are worded like trap interview questions
|
|
#
¿
Oct 9, 2018 01:44
|
|
|
FMguru posted:yeah there are three aspects to the unlimited vacation scam Heroku's unlimited vacation policy owned as a remote employee for this reason. The Canadian government mandates a minimum defined set of vacation weeks that can be paid when leaving or reimbursed at the end of the year if not used. At some point, they wanted to change the policy for Canadian employees from "unlimited vacations" to "N weeks according to experience". Since many of us had decent managers that did allow to go for more than the default N weeks (2-4 years for juniors-tech lead ranks iirc), there was a bunch of angry e-mail threads that resulted in a policy of "unlimited vacation with N weeks minimum, and please do enter vacation time in the tracking system so we can be compliant", which is frankly the best of both worlds. Accept unlimited vacations if it comes with a clearly defined base number of weeks you are guaranteed to take and get paid. Proceed with extreme caution otherwise, and consult employees in the exact group you'd be working with to know what things are like, and then a different group just to see how widespread it is of a practice.
|
|
#
¿
Oct 9, 2018 15:29
|
|
|
trust your coworkers above your management 
|
|
#
¿
Oct 9, 2018 15:31
|
|
|
|
| # ¿ Apr 27, 2024 00:14 |
|
|
im filling in an expense report to replace all tables in the interview room to be glass so i can see the shoes
|
|
#
¿
Oct 17, 2018 13:25
|
|