|
Startups aren't all the same. There's various phases of growth (five man, 20 man, 100, etc.). Find out how many clients they have, their revenue, and their growth projections, and see if their projections make sense. Companies with established clients and revenue (instead of bleeding VC capital dry) must be doing something right. Also, honestly, pretend equity doesn't exist. Equity is great if the company grows large enough and if you're around long enough for it to matter, but otherwise you have to live for now. It's one thing to take a pay cut for the benefit of being able to work on interesting problems, but evaluate the opportunity just on that, and not the mythical equity money that might or might not (probably not) come.
|
#
¿
Mar 5, 2015 21:08
|
|
|
|
| # ¿ Apr 29, 2024 13:03 |
|
|
Che Delilas posted:I could just as easily say I don't expect them to pay for a computer because I have one at the location I'll be working (home) anyway.
|
|
#
¿
Mar 21, 2015 20:19
|
|
|
Skandranon posted:Computers don't really break down that way. So a monitor I own, that I mostly use for work, just went bad on me a few weeks ago. Its warranty replacement has awful backlight bleed, so I ended up purchasing a new (open box) monitor and keeping the old one as a spare. I didn't expense the replacement in part due to hassle, and in part because I don't use it exclusively for work purposes (though I do ~80%). If the replacement cost much more than it did though, I probably would've tried to expense it.
|
|
#
¿
Mar 21, 2015 23:22
|
|
|
Pollyanna posted:I'd take a personal day or work from home, but I'm already in hot water for doing that too much for my manager's tastes, How many days have you taken off this year?
|
|
#
¿
Sep 11, 2015 02:10
|
|
|
Pollyanna posted:How much suffering is actually caused by paying the new guy more than the more senior employees? Then, as part of hiring they bring on a new guy who makes 30% more than the folks who've been there for years waiting for things to get better. That's a sudden, shocking realization for these kinds of folks that they're definitely being abused (intentionally or not). This also has a tendency to happen as those underpaid guys (who were probably hired in their early-mid twenties when they were willing to take such a risky opportunity) are starting to reprioritize their lives to focus on a house, family, etc. That salary difference means not being able to afford as nice of a house (or a house at all), waiting longer to have children, etc. So, it can turn into a mess, fast. The best thing the company can do is raise salaries across the board, but they may not be able to afford to do it just yet--then what?
|
|
#
¿
Sep 25, 2015 17:39
|
|
|
Urit posted:All this interview chat + my nightly reading of Cracking the Coding Interview is really making me nervous because I keep discovering stuff that is "easy comp-sci degree stuff" that I absolutely do not know and have never even heard of in some cases (e.g. AVL trees) and I've got a software engineering interview on the 9th. Hoo boy! For those who are aware of the out-of-balance problem, I would expect them to know that self-balancing BSTs exist and, bonus points if they can recall the name of one. I don't expect (or care) about the details of a particular self-balancing tree's implementation, other than a general description that "self-balancing trees redistribute existing items upon insertion of new items" or something like that. While BSTs are a popular interview topic, I don't know if self-balancing ones really are. I recall learning about AVL and Red-Black trees in our undergraduate data structures course, but I've never had to implement one in my professional career and can't think of a reason I'd want to instead of using an existing library. If I did have to implement one professionally I wouldn't work off an undergraduate text either, but would look at the implementations used in popular libraries (e.g., Java Collections) and try to understand the motivations for the selection of the specific implementation they use, and select an implementation appropriate for the criteria that's forcing me to implement one in the first place. To echo what some of the other have said earlier, interviews for "recent graduate" entry-junior positions tend to concentrate on reasoning and knowledge of CS fundamentals simply because the applicants do not have enough differentiating experience otherwise--usually at a career fair we'll get a stack of resumes from students that are identical except for name and address. If you do have experience, whether applying for an experienced-junior or senior position, or even if you're a recent graduate with hobby projects, I'm always interested in hearing about your experiences first. Sure, you have to be technically proficient and that will be tested in some form, but I'm really far more interested in working with your strengths to see where/whether it's a good fit for the both of us, than I am interested in grading your expertise in undergraduate minutiae. ExcessBLarg! fucked around with this message at 04:28 on Mar 7, 2016 |
|
#
¿
Mar 7, 2016 04:26
|
|
|
Computer Engineering, in both hardware and software/systems variants, is a legitimate engineering discipline. It shares a lot of fundamental skills (problem scoping, modeling, risk/defect analysis, etc.) with traditional disciplines (mechanical, electrical, etc.), but significant portions of the traditional curriculum (physics, mechanics) don't really apply. For example, I have a Computer Engineering degree from an engineering department of an accredited institution, but I haven't taken the PE exam and there's not really a point in doing so. Calling oneself an engineer gets muddied up if it's a protected title, since that focuses on the PE and traditional disciplines, but what we do is very much engineering. Programming is one task that a computer engineer does, but it's not the only task, and there's also people who program for a living, but don't have an Engineering degree. Whether those programmers consider themselves to be engineers is something of an identity thing (especially since computer systems is a field that's feasibly self taught, albeit rarely), but might also depend on exactly what they do when programming. If they're architecting or scoping a system they're probably engaged in engineering. If they're just taking already-scoped tasks to implement minor features, that might be "just programming". However, because there is not licensing or an exam for computer engineers I hesitate to make opinionated distinctions over whether an individual worker (aside from those I hire) should be title as "Computer Engineer" or just "Programmer". As for why there's so many "Engineer" titles, a simple reason is that those personnel may (legitimately) work within an engineering department, and so having an Engineer title is not unexpected even if their actual work is on the fringe of what we'd call "engineering".
|
|
#
¿
Apr 6, 2016 18:14
|
|
|
necrobobsledder posted:I'm not one to care too much about ABET accreditation as a barometer of competency, but from a legal standpoint it does matter very much. It's what's kept me from hiring some folks I knew were probably better than kids from random state schools but their lack of degree kept me from moving forward. For example, what matters in much of the US for traditional engineering is having a license, and even that's to sign off on engineeing work--junior engineers are often not-yet-licensed. And there, it's the responsibility of the licensing authority to ensure that the applicant is meets the required qualifications for a license, it's not something the employer has to independently vet. Then, in the software world, there is no license. Maybe a software firm could be found negligent if something happened in a safety critical system and it came out that the "engineers" of said system were woefully underqualified, but the majority of software isn't safety critical.
|
|
#
¿
Apr 6, 2016 20:51
|
|
|
Flaming June posted:I generally try to make the interviewer relax in a situation that can be awkward on both sides.
|
|
#
¿
Aug 18, 2016 01:06
|
|
|
If you're early in your career I wouldn't focus so much on chasing the senior title, but rather make sure that the position you're in is offering sufficient opportunity for career growth. Early in my career I was fortunate enough to work with seniors/managers/mentors who taught a lot about how to be successful in team and business-oriented settings. My growth at that time wasn't even so much in technical knowledge (for which schooling had prepared me well), but obtaining the practical work skils that Kyth mentioned. Anyways, I found working with these folks to be invaluable, but eventually they retired or moved on, or I moved on, and while I have different growth opportunities now it's more trial-and-error on my own. While some of it is a matter of just gaining sheer experience, if you find yourself in a position where the people senior to you aren't really contributing constructively to your career growth, you might just not be in a good place. Similarly, even as a junior person you generally should be entrusted with additional responsibilities over time, and if not the people senior to you should be able to (if not regularly doing so) offer constructive criticism that highlight areas where you still have some growth to do. To be honest, there's people who aren't very good at their jobs across all levels. How they get hired or promoted into such positions isn't necessarily logical or fair. At the end of the day though, if you find yourself in a position that's not helpful to your career, it's time to move on.
|
|
#
¿
Oct 22, 2016 20:27
|
|
|
Good Will Hrunting posted:That's understandable, but to me it says something about the culture ....
|
|
#
¿
Dec 3, 2016 20:35
|
|
|
I can see why a DBA would want to be involved in code reviews too. It's not just table design, database performance is also a function of writing queries in a performant way. There's a professional way to have that conversation though.
|
|
#
¿
Feb 9, 2017 16:23
|
|
|
Mniot posted:I think we all assumed that someone who was coming in with a "senior" title would just know that you should write code in the same style as the rest of the file you're editing
|
|
#
¿
Feb 10, 2017 01:56
|
|
|
Pollyanna posted:The biggest thing that worries me is that this (and the stuff about being proactive) is feedback I've received before, and that this appears to be a pattern with me. That's really bad. That's the kinda thing that tanks confidence in me and I need to avoid it. I get that not everyone wants, or can, do over 40 hours during crunch time. However if it's crunch time for everyone else you can bet that you should be visibly busting rear end for the 40 hours you do work, which means training and side-projects take a back seat until the crunch is over.
|
|
#
¿
Feb 22, 2017 23:17
|
|
|
Che Delilas posted:Unfortunately it doesn't matter to me what they intend, what matters is that they are claiming these advantages at all. Because if the worst case happens, I would then face additional disadvantages (for instance, having to prove that an agreement I signed was not legally enforceable or too broad in scope to be valid). As gays fashion said, the implicit threat is already asserting control over what I do. However, it's a policy that most companies in this industry have, and they really do have it for their protection. The problem is that if a rogue employee creates a product on company time or with company resources and spins it off as its own thing and it turns out to be a significant revenue generator or competes with the company's own products, the company will have a difficult time proving that it was done on their time or with their resources (assuming it doesn't incorporate existing source code). Even if it was done on own time/resources it may well have benefited from inside knowledge of the company, even if such benefit doesn't involve trade secrets. From the company's perspective it's unusual for someone to put in eight hours a day programming, plus an additional four hours or so programming on a totally unrelated project after hours. Most employees have family or just don't want to "do work" after hours. So it's a clause that doesn't affect most of their employees personally while providing significant protection against rogue actors. Conversely, if you are a regular participant in external (say, open source) projects, most employment contracts I've seen have a space for you to list existing works that you contribute to, so you can make it clear that you work on specific projects after hours and they're not company IP. If you can get away with striking out that clause on your employment contract (along with onerous non-competes and other "not for your benefit" clauses) then more power to you. However, it's a common enough clause, and there's enough potential employees who don't care or who will tolerate it, that the company may say tough. ExcessBLarg! fucked around with this message at 21:28 on Apr 1, 2017 |
|
#
¿
Apr 1, 2017 21:24
|
|
|
Pollyanna posted:I remember an interviewer getting all huffy when I responded to a string manipulation question using core Ruby functions,
|
|
#
¿
May 12, 2017 13:58
|
|
|
While work-life-balance is important it's not a good topic of conversation in an interview with a (founding) CEO of a 400 person company. Among other reasons, that CEO almost certainly does not have good work-life-balance given they've invested a significant part of their career and personal investment growing the company towards success, even if it's something that's OK in the rest of the company culture. Beyond that though, you probably want to say something about yourself that's memorable in a good way. Since you're (potentially) one in a sea of 400, tell the CEO something interesting about yourself that might make them say "oh you're the ___ guy" the next time they see you, lest you be entirely forgettable.
|
|
#
¿
Nov 17, 2021 17:11
|
|
|
Why would you burn three engineers on grind code, dear lord.
|
|
#
¿
Apr 8, 2022 02:38
|
|
|
I was remote for years before the pandemic and basically never used video. In fact, during most calls I pace around like a crazy person. When everyone went remote video calls briefly became a thing, but my experience is the engineering/IT quickly figured out (as I did long before) that audio only is better. I never actually look at people on calls anyways. If I'm not pacing around I'm looking at my notes or working on something else.
|
|
#
¿
May 1, 2022 11:42
|
|
|
Guinness posted:I'm very pro-remote and work 99% remote still, but there is some validity to the arguments that in-person work for certain types of collaboration and communication is more effective, and in my experience a culture of video-on by default helps narrow that gap considerably. For 1:1 or career-focused meetings, sure, cameras make sense. But for daily meetings like "stand-ups" or technical discussions there's probably a lead doing a screenshare and nobody else needs to be on camera. There's no point to be looking at others since you're focusing on the screen share anyways. ExcessBLarg! fucked around with this message at 18:05 on May 1, 2022 |
|
#
¿
May 1, 2022 17:42
|
|
|
Mniot posted:If you're suggesting that communication would improve with lower bandwidth wouldn't it be even better as chat-only? Mniot posted:And then wouldn't that be improved by going email-only?
|
|
#
¿
May 2, 2022 16:05
|
|
|
Pollyanna posted:Yeah don’t trust any company that says they’re remote. Eventually the false confidence of butts in chairs will win out and everyone will get recalled cuz Covid is over baybee open er upppppppp hack cough wheeze
|
|
#
¿
May 10, 2022 16:40
|
|
|
Motronic posted:Interns take more of your teams time than they give. That's the entire idea. You just can't depend on an internship to produce something useful and even if it doesn't that isn't necessarily a poor reflection of the intern.
|
|
#
¿
Jun 27, 2022 02:41
|
|
|
|
| # ¿ Apr 29, 2024 13:03 |
|
|
Xarn posted:If you don't expect your intern to get anything done, why waste the money in hiring them?
|
|
#
¿
Jun 27, 2022 21:51
|
|