|
I screen a lot of resumes and do the occasional technical interview when someone seems like a good candidate. Because I do a lot of research projects with DARPA/Army/NASA/Air Force/etc., I'm restricted to only candidates that are green card holders or US citizens and who want to do all of the secret squirrel stuff, so I tend to get a lot of lazy scrubs that think they should be handed a job because they already have a security clearance. Github projects score major points for me if they hit the right check boxes (for Linux system programming): 1. Clean code. That means comments, proper indenting, consistent variable and function naming, good API, etc. 2. Code that shows some measure of experience. That means error checking, use of const, simple-but-functional, etc.. For example, I am a bit wary when I see someone roll their own linked list instead of using an STL container of some sort. If it is a resource-starved project for embedded, then this could be OK and a good starting point for a discussion on the pros and cons of doing so. But for a daemon for a Linux server somewhere, I wonder why they reinvented the wheel. If I bring something like this up and I hear "yeah, I wasn't as experienced as I am now when I wrote that, but I did it the right way over here and just haven't rewritten the old stuff", then that is definitely points in the candidate's favor. 3. Documentation. Is there a web page, usage document, or even a generated Doxygen listing of the API? At least a Readme file? It could be a huge project, or it could just be a convenience wrapper around another library. I've looked at a lot of SDL wrappers around audio and network libraries, for example. I've also looked at libraries for LLVM optimization passes and other non-trivial projects that are tightly coupled with another massive project. Another filter that I use when I do a verbal interview is the "repeat, but not related" filter. If I ask you a question and you repeat the same deflection answer that you gave me before for a different question, I'll raise an eyebrow. For example, if I ask if you've had experience with some aspect of systems programming and you tell me "well, I've done a project with X, which is kind of similar", that is OK. However, if I keep getting back that same response with multiple things that I bring up, I get the impression that you are coasting on some previous project that you worked on and that you are hoping to leverage the reputation of that project to coast on a new project. If, instead of telling me "no, I'm not familiar with that" you repeat something else that you did that is completely unrelated, that is worse than telling me that you are unfamiliar with it. I tell candidates flat-out at the start that I don't expect them to know the answer to every question and to be honest with me. They lie anyway. Go figure. Also, if you come across as an arrogant tool, I don't care if you are an absolute genius. The rest of us have to work with you each day. If you can't at least smile and say a quick hello and nod to your officemates that you pass before sitting down and coding for hours, you need to work on that. Being an introvert is totally OK with me, and I'm not going to penalize people for not feeling comfortable doing the typical office smalltalk. But, there is a big difference between being shy and being an arrogant jerk, and it is very easy to spot the difference. Face to face interviews are my chance to see what kind of person you are. You aren't just a sack of meat that takes in coffee and spits out code. You are a member of the team and I'd like to keep you around for a few years (if for no other reason than to avoid doing the interview process again). I have seen quite a few applicants that were pretty good, but who just seemed like they would be awful to put up with. I think they were that way because they actually were really good, and were probably the best developer at a previous job. The habit of talking down to colleagues and management became ingrained, and then we have to live with the "you should be happy to have me" type of attitude. I see this more in the developers with around 3-5 years of experience or less. The more experienced guys that have been through a few product development cycles have a better perspective and attitude (from what I have observed). You'll sometimes get a dev that worked at the same defense contractor for 15 years that has this "you should be happy to have me" attitude. Yes, we are happy to have you. No, we aren't happy that you are an arrogant jerk. Lighten up. If you have a previous job position on your resume/CV that involves the words "rockstar" or "ninja" without you being a literal rockstar or ninja, you may very well fit into the category of person that I mentioned. That being said, I would jump at the chance to have an actual ninja working at the office. You'd turn to him in a meeting to assign him work and there would be a puff of smoke and a log sitting in the seat where he just was a moment ago. As an experienced guy, I always hope that I get interviewed by someone with a similar level of experience. This rarely happens. Edit: If you do a lot of hand waving during your interview and beat around the bush, I'll do whiteboard questions to see what your thought process is for solving various small problems with multiple solutions. If you can explain solutions to me clearly at a high level, I skip whiteboard stuff because it is clear that you understand the problem and can form a high-level solution. The whiteboard is more of a filter for lower-end candidates. hendersa fucked around with this message at 14:27 on Aug 3, 2016 |
#
¿
Aug 3, 2016 14:10
|
|
|
|
| # ¿ May 21, 2024 07:19 |
|
|
Blinkz0rz posted:In more than 10 years of professional software development I've never come across a situation where I've needed it. I have an anecdote for the other side of this coin. Maybe eight or so years ago, I joined a company that had a mature software product that was widely deployed. It was messaging middleware for hospitals and the like. So, when you hit the bedside button to call the nurse to your bed, the software would send messages out to the nurses via their pagers, Cisco phones, Vocera badges, etc. While the software worked, it was written by a bunch of talented (but junior) staff at the "main" office. I joined a new office that would be taking over software development duties (which later became the "main" office). A quick overview of the products situation when I got there: 1. Most related to algorithmic complexity was the fact that no one had ever run a profiler on the code. I was the first, and I found major slow spots where the previous developers had done silly things with exponential algorithms where linear would do. Management was too focused on fighting fires with incoming bug reports, so I actually had to call a meeting with management to justify the time and funding to rework those pieces of the product and to show the staff what a profiler was and train them on how to use it. So, I had the exponential/logarithmic/linear charts and did a CS 101 explanation of it to two VPs. 2. No STL containers. There were something like five roll-your-own linked list implementations in there. No "const" qualifiers anywhere. "char *" instead of std::string. No asserts anywhere because "they make the program crash".  3. Tons of customer-specific branches of the product. There were features in one branch that weren't in others, and bug reports had to be applied to a specific branch and then added to other branches. Over the span of a year, I merged something like seven branches into one with a minimal set of build #defines for customer-specific features. 4. No documentation beyond sparse comments in the code. I spent a lot of time making notes as I went, which later became wiki-fied in a central documentation location that everyone began contributing to. 5. They were shipping stripped debug builds because release builds "didn't work for some reason". They included the debug C++ libraries in the installer because most customers didn't have them. That would certainly explain the crashes due to asserts. 6. No unit tests were in place. No regression testing procedures. No continual/nightly builds. It was the "fix a bug and do a customer-specific release" school of delivery. All of these items do a pretty good job of showing what the difference is between a talented junior developer and an experienced senior one. Yes, the company was doing well with their product, but it could have been doing so much better without wasting so much time doing a zillion software releases and constantly playing whack-a-mole with bugs. I spent a lot of late nights consolidating, testing, and cleaning up code. I also spent a lot of time working with other developers and mentoring them on better ways to do things. It ended up paying off in the long run, as the company was acquired twice over a span of three years. I'd probably still be there if I hadn't left to go back to grad school. hendersa fucked around with this message at 14:34 on Aug 22, 2016 |
|
#
¿
Aug 22, 2016 14:04
|
|
|
MrMoo posted:This is impressive, I presume no advantage was taken of everyone using the debug build either. Nope. While some sort of fancy remote debugging would have been useful in a few cases, the standard method for troubleshooting a customer issue was to provide the customer with another build full of logging fprintf() calls and hope that the log gives you something useful. It has been my experience that "build with debug, strip, and ship" is commonly seen in shops desperate to get a release out that has a lot of uninitialized variables, since debug initializes all of your variables to 0, null, etc. This solves a surprising number of bugs that would not immediately appear as bugs if someone unfamiliar with this quirk was doing a code review. What, pay attention to compile warnings about using uninitialized variables? Pffft. They had a pragma in the build configuration to silence a ton of warnings! necrobobsledder posted:That kind of situation is the default state of programming in the real world, sadly. Sometimes they start with good teams that leave, sometimes management squeezed budget on engineering when they didn't have much money at first, the reasons are as varied as the kinds of developers out there. I've found this also to be the case in outsourced code that was brought back in-house from overseas when outsourcing turned out to be a disaster. AskYourself posted:Just wondering, did management assigned you time in your regular schedule to do all that work or did you end up doing it for free in unpaid overtime ? Did you get something out of making the company more efficient ? I was doing it on my own time at first, but it was becoming more and more apparent after several months of scrambling that it would not work out that way in the long run. That is why I made an appointment with management to present my findings and request time and funding to do training and get everything cleaned up. I am an outlier in this as I got an MBA along the way and made a compelling business case for return on investment for making the change in the way development was done. Development managers that were excellent devs and who were promoted into management often have a difficult time making the business case for this kind of stuff outside of the claim of "but it is the right thing to do!" Just like development, the business side of things takes mentoring and experience to do really effectively and to bridge that gap between the "business" people and the "engineering" people. Edit: To take it to management: Figure out how much time is being spent on rapid releases and the time needed to troubleshooting and fix a bug. Figure out how much of that is "overhead" that could be eliminated by reducing the number of releases. Figure out how many bugs are due to regression. Estimate how much time is wasted trying to reinvent the wheel or looking for info that only so-and-so knows. Apply a dollar value to that time. Estimate the amount of money required for training (and loss of development time during training), additional tools, books for the office, etc. Compare the costs to savings and find an estimated break even point. Estimate what the return on that investment is on multiple timeframes (quarter, year, 3-year, etc.). Finally, suggest what intangibles might result from the improvement in process (improved customer perception of product, give the appearance of outpacing competitors, etc.). Measure what hasn't been measured and make it easy for management to make a decision that would improve the state of things. hendersa fucked around with this message at 15:21 on Aug 22, 2016 |
|
#
¿
Aug 22, 2016 15:07
|
|
|
Just a touch under ten years ago, a recruiter contacted me about a position at a company that makes giant displays and timers for sporting events. Think of their product as these huge "blocks" of LED arrays that could be combined together to make arbitrarily large displays. The company was looking for a development manager/lead developer, and I had the right background, so they asked me to come in for a one-hour interview. I did the interview, everything went well, and then an engineer came in and told me it was time for the developer code test. He wanted me to sit down at a PC without an internet connection and code some C++ based upon a class definition in a header file, and he told me that it should only take me "a few hours". The recruiter said it was going to be a one-hour interview. The company's HR also said it was going to be a one-hour interview. I told this engineer that I was going back to work and that I had already gone well over the hour I had allocated for the interview, and he said, "but... everyone does this test when they come in!" I apologized, said that I wasn't going to do it there, but that I would be happy to take an hour or two and look at it later that evening after work. He rocked back and forth on his feet for a few seconds before he said "ok, but I need to give you my cell phone number in case you have questions." He was insistent on giving me his number and he kept telling me to be sure to call him if I ran into trouble. Maybe 8:00 that evening, I finally had time to look at this header file they gave me. It was designed all wrong, and it clearly wasn't going to work the way the interfaces were set up. We're talking about passing pointers to buffers of variable size into methods, but without any sort of buffer length parameter, known terminator in the buffer, etc. to know how big the buffer is. I spent maybe 30 minutes looking at it thinking about how it was all wrong before I gave the engineer a call. I told him that I had looked at his test and that I could not write code for it as-is without reworking the header file first. He asked me what was wrong with it, and I gave him five or six things that needed to be fixed before it could be implemented. Then he said "congratulations! You passed the test! I'll let HR know tomorrow." I was offered the job position. I did not accept it. If you want to test people's ability, that's fine, but don't turn it into the movie Saw or something.
|
|
#
¿
Oct 7, 2016 16:44
|
|
|
leper khan posted:It made hendersa reject the position though, and that seems bad. My concern was more along the lines of their HR department reassuring me that it would be a one-hour interview (they were aware I had a job and was coming in on my lunch hour) and then springing a coding interview on me well past the end of that hour as I was just about to walk out of the door to leave. I didn't have an issue with their particular coding test, for much the same reasons as pr0zac pointed out. It felt pretty awkward to have to call someone at home outside of business hours to tell him that the test was "broken", though. During part of the interview, one of my interviewers told me that the company had already interviewed about ten people for the position. That means that HR had already been through this interview process ten times, so they should have been familiar with the scheduling requirements when interviewing a candidate. If they wanted to keep the code test a surprise until the interview, that's fine. Just ask the candidate to come in for a two-hour interview and then do the code test for the second half of the interview period. I wouldn't reject a job solely because of something like this, though. There were other aspects of the position that I wasn't too keen on. This was just one more concern added onto the pile. Then again, maybe I was just the first candidate that made it through the hour of interviews and wasn't tossed out prior to the coding test! 
|
|
#
¿
Oct 9, 2016 22:36
|
|
|
Good Will Hrunting posted:Why would you listen to your parents? Chances are that they have no idea about the current state of education and employment, especially in our sector. I don't think any of my mom or dad's career advice has ever been remotely close to passable, let alone "good". I believe that the last career advice I received from my parents for something like this (at least 15 years ago or so when I was laid off from a dotcom startup that was being purchased) was that I should hand-carry my resume into a large corporation and then ask to speak with a manager to personally deliver it. This is how "you get them to remember you and you get the job." 
|
|
#
¿
Nov 2, 2016 14:46
|
|
|
csammis posted:I think his problem might have been that he didn't put working at Google on a high enough pedestal Isn't Google one of those things that kind of happens to you while you are off doing actual, productive work? I've had Google recruiters ping me a few times here and there out of the blue over the past few years, but I was already doing interesting work and wasn't in a position to drop everything and move the family across the country for a new job. I can only imagine what those poor recruiters thought when they did a web search for this guy and found his blog. Sadly, there was probably just a lot of sighing before they tossed his resume into the circular file. Bonus points to this guy if he went for broke and actually listed that blog on his resume.
|
|
#
¿
Jan 11, 2017 20:49
|
|
|
mrmcd posted:I've noticed a growing trend in SV and its satellite tech cities of software devs who feel the need to build a "personal brand" for some reason. The results are almost always mystifying, infuriating, and irritating. But, if you're ranting on twitter or have a blog full of crazy-person ramblings, then... not so much.
|
|
#
¿
Jan 13, 2017 19:52
|
|
|
Vulture Culture posted:in every other industry this is called "credential creep"
|
|
#
¿
Jan 14, 2017 03:28
|
|
|
Vulture Culture posted:If "everyone" should be establishing a brand for themselves, how does that not inflate the baseline? I understand your point, and I don't disagree. If everyone does XYZ, then companies will come to expect XYZ from all potential candidates, even when that isn't an explicitly-stated requirement for the job. Baseline expectations inflate. However, there are many different facets of the software development industry and geographic software markets where branding among engineers is hardly done. Government R&D in general, firmware and embedded systems outside of the hot geographic market areas (programming toaster firmware in Boise, Idaho or something), legacy software porting and maintenance, etc.. These organizations aren't actively seeking out prestige hires, and having the branding would certainly make you stand out. These positions also aren't web front/back-end development, cloud-based services, or other sexy jobs that are currently sought out by engineers seeking to work for the very best. You aren't competing with a bunch of H1Bs or younger developers whose job is their life. You're looking more at the 9-5 developers with a family and a house and life outside of work. They want a paycheck, but do not wish to establish any personal branding, and suggesting that they brand themselves will result in a response of "no thanks, that sounds like more effort than it is worth." Thus, it isn't always the case that "everyone" has the desire to do some branding. I have no doubt that many of the goons in this thread see a lot of shameless self-promotion among candidates in your area of the industry or geographic market. And, I do agree with what you say. But, there is a lot of industry out there that isn't a start-up culture or VC-backed pressure cooker based in San Francisco, Santa Clara, or New York City. If a particular job market is saturated with candidates that constantly polish their reputation, then the candidate not doing that is out of luck. There are a lot of markets where that doesn't happen, though. So, I should modify my original statement to say that everyone should establish a personal brand if he/she wants to maximize the opportunity for long-term success and professional growth. In high-pressure markets, it is expected. In other markets, it will certainly make you stand out.
|
|
#
¿
Jan 14, 2017 18:59
|
|
|
Thermopyle posted:I guess I'll ask this here first before I head to BFC...I'm drawing a complete blank on what you call the document that I've seen some freelancers use wherein an on-going client has a contract of sorts where it lists all the stuff that doesn't change from job to job. Then for each job they just sign a short thing describing the job that doesn't include all the boilerplate-ish stuff like warranty terms, licensing, etc.
|
|
#
¿
Jan 29, 2017 20:06
|
|
|
Arachnamus posted:Also called a "schedule". Under US contract law, "statement of work" means more than just a schedule. From the legal standpoint, it is an addendum to the original contract (like leper khan mentioned). Thermopyle asked what this type of document is called, so... there you go.
|
|
#
¿
Jan 31, 2017 21:53
|
|
|
Arachnamus posted:Ah, UK law must be different, as a "schedule" takes that role in many of the renewable contracts I've worked under in the UK. Not a problem!  Jose Valasquez posted:Employees of defense contractors typically have to track hours as well, at least in my experience. I have to do this for my government research work. Even though I am salaried and exempt from over-time, I still have to track hours worked for bookkeeping and billing accountability. Direct labor costs (paychecks) are only something like 35% of the costs associated with a program. If you're working more hours, you don't get paid more, but you are technically using more company resources during that time that have to still be paid for. IT and housekeeping services, electricity, insurance, etc. get proportionally paid out of the remaining piece based upon the hours billed to that project versus total hours across the company. The government requires these details to be tracked. It's ironic that this is done to avoid wasteful spending and fraud, but it is one of the major sources of expense in many programs! It's even more ironic that doing it this way is still way cheaper than the government research labs taking on the work themselves. Your tax dollars at work. Hughlander posted:Or 1/10th of hours as I recall at Ratheon (6 minute intervals!) It was 6 minute intervals at Lockheed Martin back when I worked there, as well. LMCO's project overhead makes our overhead look like a rounding error (though we still track hours in 0.1 hour increments).
|
|
#
¿
Feb 1, 2017 17:45
|
|
|
lifg posted:I prefer being salaried. It saves my sanity to not deal with this small stuff. I once asked my manager what the charge number was for time spent looking up charge numbers.
|
|
#
¿
Feb 2, 2017 18:55
|
|
|
prisoner of waffles posted:Under that line of thinking, tech debt is "risk that the way we solve stuff with code/systems now ceases to be a good solution at some point in time."
|
|
#
¿
Mar 27, 2017 21:30
|
|
|
Pollyanna posted:Had that phone screen today. Recruiter clarified that it was in fact a 2-year contract through his own company (some Genericorp-sounding name) but I'd be handling the taxes, getting my own benefits, etc. I told him that my contracting rate would be $150/hr or more, and I'd be taking a hit otherwise. The conversation basically ended right there. When I review my budgets at $BIG_COMPANY, approximately 1/3rd of a project's budget goes to direct labor. The other 2/3rds goes to indirect (overhead, benefits, contracts, travel, your share of company IT and janitorial, etc.) and a built-in profit margin of 8-10%. A dev making $150k is approximately $75/hr of direct labor, meaning that it costs the company about $225/hr out of the funds for a particular program. My general rule of thumb when consulting on a long term project is to charge an hourly rate twice what your direct labor rate would be as a salaried worker. If you're making $150k a year, an hourly rate of $150/hr is reasonable, as it is 50% lower than what it would cost that company for a salaried worker with benefits ($225/hr). Roughly half of what you make is going to go to taxes, and then you need to figure benefits on top of that, so charge more than twice the DL rate if consulting is your only business (or accept that you're making less per year in exchange for the If you have a short-deadline, high-pressure contract dumped in your lap, though, charge more. I've gone 4x my salaried hourly rate for one-shot contracts for organizations that have grabbed me out of the blue and need an evaluation of ABC running under Linux on XYZ within the next five days for an upcoming VC meeting...
|
|
#
¿
Mar 31, 2017 14:24
|
|
Did I ask for too much? I worked out the numbers, and that seems to be about 2x~3x what I make as a salaried employee at my current job.
|
So... I applied for a new job. I have an offer letter for that job in hand. I have a meeting with a VP tomorrow about leaving my current position. Overall, I'm giving about six weeks notice. Right now, other than the VP and one director, none of my co-workers know that I plan on leaving. As background material, I have a senior role as a principal investigator. I have a few million in R&D budget under my watch, as well as a number of programs, schedules, and engineers that I manage. I work with the US DoD, DARPA, Air Force, NASA, etc. on $SECRET_STUFF. I manage my engineers by example, so I also do a lot of hands-on engineering work in embedded systems. This is both concrete work in getting systems up-and-running on new EVMs and theoretical OS work (micro/monolithic kernel performance, schedulers, latencies, etc.) on what the limits are to different approaches. The running joke is that if a fire is burning on any of our projects, my body is used to smother the flames. I get loaned out to other programs all of the time to provide technical know-how and mentorship. My hands-on work is a necessary evil, as I have been unable to find and hire someone with the necessary qualifications to do the work. I have a few mentored engineers capable of doing many aspects of the work, but I'm the only one around with the PhD-level knowledge to do key parts of it. I'm trying to prepare a continuity plan with a realistic proposal of how to reallocate the work I was doing. Unfortunately, I have been doing the work of about three people: a researcher, a senior engineer, and a project manager. This work has integrated into my workload slowly over the past 4.5 years. I have a PhD in electrical and computer engineering and an MBA, am a native US citizen with a secret security clearance, and I have a little military experience. I can't even begin to imagine where the company will have to look for someone qualified and eager to jump into the spot I'm leaving behind. A light week of work for me is about 50 hours, with 60-65 hour weeks during proposal writing season. I often wrote papers, books, etc. on my own time, so that isn't even figured into that hour count. If any of you are coming from an academic background, this probably sounds like a pretty reasonable work-life balance and a pretty sweet deal. Industry people know the truth of it. It is not. At all. I've got ulcers flaring up and I need a change. Badly. Now for the questions: 1. I have been the primary advocate for work-life balance for my engineers. I seem to be kinda alone in this, as we always have "a lot to do." Any way I can get something in place prior to my departure to help shield them from unrealistic scheduling in the future? I want to explicitly mention this in the continuity plan to make upper management aware of the need for it. People won't quit because I leave, but they will quit if they begin to be treated poorly. Most of our staff are foreign nationals, but my crews are all US citizens with clearances working on the heavy-duty stuff. The US folks generally won't put up with the "aggressive scheduling" that the foreign employees will tolerate, but our management (VPs/directors) are all Chinese and Indian PhDs coming from an academic background... 2. I have research publications under submission in which I am the first (primary) author. I did all of the research work, gathered/analyzed the data, and wrote the papers. I will leave before I get accept/reject notifications on them. Do any of you have experience with how to handle this sort of thing? If any papers are accepted, someone still needs to attend the appropriate conferences to present the findings. I'm not worried about my pending patents, as my name was listed as a co-inventor on the filings and I can't imagine I'd be removed from anything after the fact because I left... 3. The VP I will be meeting with is not based out of my facility. He is flying here to meet with me. I will be firm on leaving, but can anyone offer suggestions on what kind of oddball requests might come my way? Demands for a longer notice period? Pressure to be a contractor to ease the transition of my existing programs? Demands that I complete X amount of work in my remaining time, and it is completely impossible to do so? Demands that I find a replacement before I leave? I don't want to be caught off guard by some bad request... I am so not looking forward to this meeting tomorrow. 
|
|
#
¿
Apr 24, 2017 18:44
|
|
|
Skandranon posted:I think the best you can do is make your case that any more "aggressive scheduling" will lead to further turnover. I doubt there's anything you can really do to enforce it. You'll likely get them to believe you, but they'll probably go back on everything they said within a few months. The only way you can continue to act as a shield for your team is for you to stay. I guess the best that I can do is emphasize this point and hope that it doesn't all go to hell. csammis posted:Short of a literal labor union, no. Even at the most well-intentioned of companies a departing manager's requests are "great suggestions" until budget or contracts get in the way. The best thing you can do for your engineers is inform them: be honest about why you're leaving, emphasize that one's health should be a priority, and let them know (individually and quietly if necessary) that you'll be a positive reference for them in the future. I know it sucks because you want to do right by them, but at the end of the day your engineers will have to make their own decisions about how best to proceed in your absence. lifg posted:You might be a bit too high end for even this thread. (I'd ask if you work for Mitre, but they're supposed to have a great work/life balance.) raminasi posted:In my (admittedly somewhat limited) experience this doesn't really affect anything - if you can't continue to collaborate after you leave due to security concerns then just hand it over to one of the other authors for revisions and presentation. The author order shouldn't change. csammis posted:Be sure to check back on this from time to time. I had the interesting(ly stupid) experience of leaving a company with a pending patent application that never got actually filed, despite the provisional application having being filed for months before I left and the company's patent attorney hounding me a couple months after I left for a signature on the application declaration. The company was in the process of being sold to a Chinese owner and most of the software people were laid off afterwards so I'm not sure if it was lost in the shuffle or just ignored because I wasn't around. csammis posted:In addition to the list you made one that I can think of is that you may get asked which of your team can be promoted to replace you. Usually* the shortest and cheapest path to management continuity is to promote from within. csammis posted:I hear ya  kind of day for updates.
|
|
#
¿
Apr 24, 2017 22:01
|
|
Let us know how it goes!
|
necrobobsledder posted:They won't have to look terribly hard IMO, no need for remorse and don't let anyone make you feel any. Defense is uniquely overweight with academicians partly due to larger contracts favoring companies with a higher percentage of PhDs on staff, and you know that academia is bursting with plenty of people that are eager to work 80+ hours / week for mediocre pay - this is where most contracting companies will scoop people up out of universities oftentimes from PhDs outside CS/EE/math (biology, chem, and physics are popular non-tech degree farming grounds). But just like you, most of these over-achievers will likely leave for greener pastures of industry research at the usual Big Tech places or found their own companies in short time when they realize how short-changed they're getting in every metric possible. What's especially difficult is the secrecy of defense work that makes it difficult to collaborate, and it's oddly similar to the problems Apple's had with its culture of secrecy and its researchers having almost no collaboration outside the company. quote:If you're separating from the intelligence community, grats! A lot of the indoctrination and fear-mongering from the clearance and indoctrination process from the intelligence community following separation is pretty much BS. For example, almost nobody has their resume reviewed constantly unless you're writing in great detail in a CV up to like U//FOUO or C classification about your work. In fact, I actually sent a resume in for review before via letter and got nothing back one way or the other. But the cool thing I guess is that your clearance can be re-activated for 10 years since your last renewal but those of us that got a TS only have 6 years.
|
|
#
¿
Apr 25, 2017 15:38
|
|
|
I just got my meeting with the VP rescheduled to tomorrow morning. Oh well. So much for getting things settled today and then trying to relax tonight. 
|
|
#
¿
Apr 25, 2017 20:28
|
|
|
leper khan posted:Don't push your leave date. The new job is just thrilled that I'm accepting the job and was more than happy to work with me on the later start date. Looks like everything is pretty much wrapped up at this point. Thanks, goons!  Skandranon posted:It's going to be hard to jump into a dedicated embedded role from webdev. Why don't you start with some IoT type project? Hook up some sort of Raspberry PI to measure the water in some flowers and make available via REST? You'll get a lot further if you can lean on some of your previous experience. As a sidenote, the local university has been asking me to teach a grad class or two on embedded development. With the new job, I'll actually have the time to do it! geeves posted:I would also say to get out. 
|
|
#
¿
Apr 26, 2017 20:42
|
|
|
Having PTO is one thing, but actually being able to use that PTO is another. I currently get 15 days of PTO with something like another 11 days off here and there for holidays and stuff. The problem that I run into is that I'm often not allowed to take my PTO when I want because there always seems to be a customer/company meeting or some deadline. Time when I'd like to take PTO (like around Christmas and New Years) is off the table because that is "proposal season" where everyone is working long hours to get funding proposals out for the next calendar year. It's not unusual for my co-workers to send out a mail around right now (early summer) saying "I'm going back to China for three weeks, so I'll see you all next month." That's fine if you don't have kids, but if your kids are in school you can't always take a week of PTO when it is convenient for the company (around now, when the kids are still in school). Since I will be leaving for a new job, I hope that this is a moot point. I do have PTO scheduled during my notice period prior to my departure, but I also gave two months notice and am only taking 5 days of PTO during that time. Just yesterday, I was asked on a conference call to cancel my PTO to spend several full days during that time training a group of engineers to be my replacement. I just simply said "no" and reminded them that, despite my urging, four of my eight weeks of notice had already elapsed before anyone thought to get some replacement training scheduled. The reason for this delay is that (surprise, surprise) a director and a few engineers are off taking 3-4 weeks of PTO time and are out of the country in China.  They are clearly pretty upset with me over the pushback on not cancelling my PTO . Now, I have to spend the weekend putting together a training course for a two-day crunch on secure microkernel design, as they are now pushing the training up to next week. I doubt the engineers that I am training will retain much past the first hour or two of each day of training, since this is pretty heavy-duty stuff and they are a bit on the green side. When June 16th rolls around, it won't matter much anyway as I will be moving on to another, much better job. 
hendersa fucked around with this message at 13:55 on May 19, 2017 |
|
#
¿
May 19, 2017 13:25
|
|
|
Mniot posted:Or else what? Two reasons: not burning bridges at the place I've worked at for the past five years and for the sake of the engineers being thrown to the wolves in my place. I have been documenting my engineering work for continuity purposes these past few weeks, so I'm turning my notebook scribbles and random notes into complete sentences and grouping them logically to hand them off. I'm not making a formal course with slides or anything like that. It's more like "here's everything I have, now lets walk through it and talk about what you don't understand" for two days. It's stuff I'd have to do anyway, but I'd rather get it done this weekend so that I can hand it off and never worry about it again with a guilt-free conscience. Then, I can concentrate on wrapping up project management loose ends during my last two weeks when I come back from PTO.
|
|
#
¿
May 19, 2017 14:43
|
|
|
Arachnamus posted:"Hey I've got this job opening and it seems like you have a lot of relevant experience" I once had a recruiter contact me to present a job opportunity that I was actually the hiring manager for. I had written the job description for it, opened the job req, and was actively reviewing submitted resumes. It was the perfect storm of a recruiter that paid for both scraped job postings AND scraped resumes. I figured it was a good opportunity to see what made these scumbags tick, so I asked her where she had heard of the position and how she had come by my resume. She assured me that she was retained directly by my company to find top-level candidates and that I had submitted my resume to a job search board. Neither of these were true.
|
|
#
¿
Jun 13, 2017 20:31
|
|
|
ToxicSlurpee posted:Has anybody ever gotten a recruiter trying to recruit them for the company they're already working for? Well, if you scroll back up the page a little bit... Arachnamus posted:"Hey I've got this job opening and it seems like you have a lot of relevant experience" hendersa posted:I once had a recruiter contact me to present a job opportunity that I was actually the hiring manager for. I had written the job description for it, opened the job req, and was actively reviewing submitted resumes. It was the perfect storm of a recruiter that paid for both scraped job postings AND scraped resumes. I figured it was a good opportunity to see what made these scumbags tick, so I asked her where she had heard of the position and how she had come by my resume. She assured me that she was retained directly by my company to find top-level candidates and that I had submitted my resume to a job search board. Neither of these were true. So... yes?
|
|
#
¿
Jun 15, 2017 00:24
|
|
|
kitten smoothie posted:I was dumb and thought I'd do a CS masters' immediately after finishing my CS undergrad. 1. You can have someone else pay for it.  2. You have something concrete to show that you're working towards during your annual review. 3. You have the added work experience of developing software or planning projects to aid in your schoolwork. Of course, you have to work your classwork into the hustle and bustle of your already-overcrowded schedule. Still, it is doable. Your education isn't a race, and it can take a long (sometimes very long) time to complete. I've had false starts on degrees, moved across the country and had to continue a degree program at a different university, taken courses via distance education, and have even set my career aside and gone back to school full-time for a while. If you want a masters degree (you like to learn, want to shift focus to a new area, or it will open some more doors for you), go for it. If you just want one more box for companies to check when hiring you, it probably isn't worth the effort and money. If you view the experience of a masters degree as some kind of awful uphill slog to get a piece of paper that you view as a non-expiring technical cert, I would advise against doing it. Spend your time improving elsewhere. One thing that I will suggest to pretty much anyone is to consider getting an MBA. I know, I know... developers don't like MBAs because those people are all used car salesman-types, right? But, hear me out on this one: 1. You know all those awful, insecure managers that you have had that are terrible with people and who can't manage anything, right? What kind of formal training have they had on budgets, organizational behavior, project management, and product positioning/analysis? They probably picked that stuff up here and there by watching some other clueless manager when they were starting out. An MBA teaches you a set of skills that will help you to avoid making the same mistakes as those guys. I mean... sure, you'll still be insecure inside. But you'll get a lot of practice at faking it until you make it, and you'll get experience with presenting material to normal people without seeming like a condescending jerk. 2. It is a good generic graduate degree that is generally of lower difficulty than a technical program. Trying to get an MBA while working is much easier on you than getting a CS/CE/EE/whatever degree. They're also often tailored toward working individuals, so evening/weekend classes are more common. 3. The skills are pretty transferable, and you'll really view organizations way differently and understand more once you get to understand what many of the other pieces of the company are doing. 4. You wouldn't believe how much more attractive it makes you to organizations when you act as a consultant. That technical BS with an MBA is a pretty powerful one-two punch. Want to get seed capital or a loan to start a business? Subcontracts from a big firm? That MBA is a big first step in the right direction for doing so. 5. Many managers believe that an MBA holder has some form of magical powers. You'll get more traction when arguing for functionality or schedule changes if you can approach it from a market/product/strategic standpoint and frame it with a supporting business case. You'll be that one developer that management thinks finally gets it. 6. You know that nebulous "networking" thing that you're supposed to do to get the inside track on those hidden, awesome jobs out there? Your MBA classmates will be masters at it, and they're going to eventually be sprinkled throughout the management structure of all sorts of companies. You're going to get dragged along for the ride if you play your cards right. Who are they going to think of when some technical position opens up at their job? That one smart "computer guy" who aced the operations management and finance classes (those dreaded math classes) and helped them get through it, that's who. 7. An MBA is the entry-level degree for a whole different skill tree of jobs. Want to punch the reset button and try something else? Here's your golden ticket. You'll get better mileage out of your MBA education if you start it after a few years of working because you'll have better context in which to view everything that you're learning. There are some 4 + 1 CS/MBA programs out there, but you miss out on having that practical experience context. Some of you hated school, and I understand that. It isn't for everyone, and sitting through even more school is liked by even fewer people. Still, if you're putting in the effort to learn something to get you a better job, why not pick something that will help make you a better and more well-rounded person? Disclaimer: I got an MBA maybe five years after I finished my CS bachelors, and it helped me out so drat much over the course of my career. I even got my PhD in EE/CE over a decade after my MBA while developing software all the while, so it didn't doom me to a life of middle management, either! 
|
|
#
¿
Feb 6, 2018 04:23
|
|
|
Love Stole the Day posted:Just to let everybody know, there is also an alternative thing that focuses only on finance parts of the MBA program, is wayyyy cheaper, is entirely self-taught, and is equivalent to a Masters Degree in some countries for visa purposes (e.g. UK, Aus, NZ). It's called the CFA and all you have to do is pass their 3 exams. I passed the 1st one a couple of years ago despite absolutely zero finance background at all and am currently preparing for the 2nd one in my spare time along with working on this programming job stuff. They're pretty hard (~40% pass rate), which is why they're so much cheaper to do compared to the MBA. CFA Institute website posted:- Evaluating or applying financial, economic, and/or statistical data as part of the investment decision-making process; supervising persons who conduct such activities; or teaching such activities. (Are they still recommending the Fabozzi book for studying fixed-income securities? Good God I hated that thing.) leper khan posted:Pretty sure that's just part of hendrsa's natural magic. ! No one gave me this kind of advice when I was getting my career rolling, and I really wish that they had. So, I'm passing my experience along in the hope that it helps at least one of you out somehow.
|
|
#
¿
Feb 6, 2018 14:30
|
|
|
LLSix posted:I've got an interview for a senior software engineer position tomorrow with a company that makes remote controlled cars/planes/boats etc. Sounds like it'll be about half mentoring (I've taught on and off so I'm confident about that) and half device driver writing which I'm less confident in. Any advice on interview prep for device driver stuff specifically? I think I'd feel less nervous if I had something to review before going in. This is a bit tough to answer with specifics, as the implementation of device drivers varies a lot depending upon the environment that you're running in (bare metal, specific OS, SoC/microcontroller/etc.). However, there are some common aspects that will be a part of all hardware interfacing. I'd concentrate on these aspects when preparing for your interview (they're what I'd ask a candidate about, anyway): 1. Like csammis mentioned, know your low-level communication methods for speaking with hardware. For sensors and control systems like what you'd see in RC vehicles, these will probably be things like I2C, SPI, GPIOs, and UARTs, as well as PWM and ADC. Knowing what these guys can do and what their limitations are is good. Knowing how a microcontroller, SoC, or BIOS exposes memory-mapped I/O control registers for these guys is good. Those MMIO registers are how you're going to be interacting with hardware, so show that you know the basics on how to do that and where you'd find address/register info ("it's in the 4000-pages of SoC documentation", "I'd go talk to the BIOS guy", "I could probably scrape an address out of a device tree in the Linux kernel and then Google it to find the right docs", etc.). 2. Interrupt-driven design. Top-half and bottom-half interrupt handlers are important to know, though a simple design with lax constraints could get by with immediately servicing interrupts completely without any queuing for later processing. If you have experience with interrupt management with a particular microcontroller or SoC, explaining a concrete example of that is good. Examples of when interrupts might fire (say, data arriving on a UART from a serial-based MAVLink connection) and how you'd service that before returning to the main event loop is good. Comparing/contrasting interrupts to polling and knowing when it is appropriate to use each will most certainly be asked about if your interviewer knows anything about device drivers. 3. DMA will probably not be a concern for you, since your problem domain is concerned with sampling and writing small amounts of data to/from sensors and motors at regular intervals. You're not pushing large blocks of data around, unless you're capturing video data from a camera and transmitting it back or something like that. A cursory knowledge of what DMA is and what it is used for would probably be enough to just check the box on that one, if it even gets mentioned during your interview. 4. State machines, particularly on a bare-metal system without an OS. Show that you understand the main event loop of embedded firmware (deadlines, scheduled polling, etc.) and that you understand more of the big picture of where device drivers fit into the system. Your device driver itself may also contain a rudimentary state machine of some sort (init, shutdown, delay, sample, etc.). 5. Stuff that you should avoid doing in a device driver. Some good examples are avoiding floating point math, variable/large-sized buffers, large stack frames, non-word aligned memory accesses, concurrency/locking (sometimes), and text/data manipulation. Get the data in/out of the hardware quickily and at the correct point in time. Minimize processing of data in the driver itself. Keep memory/resource usage as small as possible. Ironically, avoid blocking/busy-waiting on I/O. On bare-metal, all bets are off on this stuff, but these items are generally best practice. 6. Debugging. The unexpected will happen, and you'll need to show that you have what it takes to figure out why. Have you ever used a logic analyzer, oscilloscope, or JTAG to watch hardware behavior? It isn't a dealbreaker if you haven't, but if you have you can demonstrate some real strength in this area. Also, if you have Arduino, RasPi, BeagleBone, etc. hardware interfacing experience, you can use that as a testbed to shake down hardware interfacing code before moving it back over to the target platform. If you have a serial terminal to push debug output over on the target platform, make sure to explain that, while useful, using it will slow things down, blow your timing budget, etc. Blinking an LED via a GPIO is also a tried-and-true aid to debugging device drivers during their initial development and troubleshooting. Your goal is to show that you won't get stuck because you've run out of debugging techniques to try. Or, at least, that you've got a few good ideas on what to try first. Try to think of a few good ones that you can mention (hell, just use the ones I listed) to give assurances to your interviewer that you can handle this type of debugging. If I were hiring a device driver developer for something like what you've mentioned, I'd ideally want someone that I could hand a sensor/motor/servo control IC datasheet to and say, "we want to be able to sample/adjust this at 100Hz on a continual basis. We've got some samples, so breadboard this out with an SBC to drive it. See if you can find some sample Arduino or Linux code available for you to start with. Get this chip talking and tell me if there are going to be any problems." I'd then (eventually) get back some C code with best/worst case time when polling and any appropriate interrupt handler info or jitter issues or whatever caveats or dealbreakers turned up. Once given the green light to proceed after the proof-of-concept, that developer would then lock down the device driver, coordinate to get it integrated into the software build (kernel/bootloader/BIOS/etc. as appropriate), document it, and perform integration testing on the target hardware side-by-side with the hardware team as appropriate. If the system misbehaves down the line, the developer will be able to collect enough information to assist the hardware folks in troubleshooting the issue from the software side, and adjust the software side as needed to address the issue. Some reference materials that might be of some use: Linux Device Drivers, 3rd Edition (check out Chapter 10 on interrupt handing): https://lwn.net/Kernel/LDD3/ ArduPilot firmware libraries: https://github.com/ArduPilot/ardupilot/tree/master/libraries Quick overview of SPI, I2C, UART, GPIO (if this material is new to you): https://tessel.io/blog/108840925797/a-web-developers-guide-to-communication-protocols Good luck! 
|
|
#
¿
Feb 7, 2018 01:34
|
|
|
While I have not taken Adderall or Ritalin or what have you, I have had good luck in the past using Racetams paired with choline citrate for two to three month stretches. It takes a few weeks to get up to full strength, so you need to stick with it. I'm kinda afraid of what might happen if I took Adderall. I might stare at something hard enough to actually light it on fire. There is an epidemic of Adderall abuse among university undergrads. Sometimes, for a change of scenery, I'd pack up my laptop and move from the lab to the common study area of the library to review papers and work. Students would walk from table to table, asking people if they had any extra Adderall that they could buy from them. It was common enough that it was not at all unusual, especially around midterms and finals. Lots of money was changing hands, so a prescription for Adderall with good insurance must have been like having a license to print money. Honestly, the most effective thing that I did to keep focus was to get on a stationary bike for 20 or 30 minutes every four hours or so. Get up off your butt every now and then and go stretch your legs. It works wonders, and it will help keep you from turning into a heart attack waiting to happen. Xarn posted:You won't just wake up one day and be knowledgeable, motivated, etc, you have to work on it.
|
|
#
¿
Feb 7, 2018 16:37
|
|
|
Pollyanna posted:Has this been broken down anywhere? But, there will always be good jobs and bad jobs. All over the place. There will even be jobs that are better than your current one where you would be hired with better pay and benefits, if you were to physically move to that market. "Are there good jobs?" isn't the correct question to ask, though. The correct question is, "if I were one of 100 applicants for an awesome available job right now, why would they pick me over everyone else?" That's what you should be spending your time and energy pondering. Is it the breadth of your skills? Your attitude? Level of expertise in some topic? Work experience at some particular company in the past? Figure that out and you'll find that there are good jobs all over the place! Some may even come straight to you. Speaking of hiring, it's entry-level hiring time! I've been doing the university career fair circuit for the past few weeks. I've actually asked students this question as some polite variation of "so, what makes you better than the rest of the resumes I have in my pile, here?" Having a reasonable answer to that question moves you up in the pile very quickly. Also, when students are inquiring about H1-B visa sponsorship, I always ask "what extra-ordinary skills do you have that would merit H1-B sponsorship?" and I have always gotten a dumb look back in response.
|
|
#
¿
Feb 11, 2018 22:43
|
|
|
leper khan posted:I think he was looking for literally any answer? It’s just priming people to tell you what they’re good at/sell themselves.
|
|
#
¿
Feb 12, 2018 15:26
|
|
|
geeves posted:What I'm worried about is becoming less hands off with code which I still love to do even with my long term goal of getting to the CTO level. If you understand the technology, that's great. It will enable you to better communicate with your direct reports and better communicate the company's needs to them in such a way that it will make "sense" when passed down to the technical doers. If you have a reputation as being a strong engineer, that's great. It will give you some street cred with the doers and give them the feeling that someone in upper management understands the nuts and bolts of what they do. Realistically, you're going to be repeatedly placed in the position of dealing with problems that you are unable to directly solve by getting hands-on. If you are a hands-on person, this is incredibly frustrating. You must rely upon your staff to actually fix things. For example, a big customer has a problem and complains directly to upper management via sales channels. You are told from upper management to get it fixed ASAP, but your staff are already overloaded because you have 10 job reqs sitting open and incoming resumes have been garbage. Something's got to give, so what is it going to be? What project is going to slip? Will the managers/developers actually support the context change and jump right on it to help? Will it generate lots of trash talk about marketing/sales from the doers and lower morale? Ever had a bad manager that was really good at the tech stuff and awful at managing people? Those bad managers are now acting as your eyes, ears, and hands if you are the VP. Can you deal with that? Can you mentor bad managers into good ones? Can you spot good management skills in others and buoy them up via management training? I would be quite nervous about any such opportunity until I could get the full story on how the position became vacant. A healthy organization should already have a senior manager or director that has been groomed for a VP position and is ready to step up. VP positions don't suddenly become available on the open market, bypassing a succession plan, unless something is going wrong.
|
|
#
¿
Feb 24, 2018 06:42
|
|
|
ultrafilter posted:If you're making progress, somewhere around two to four years in is where you start to realize just how much further you have to go. Embrace the suck and keep pushing yourself to get better.  One of the best indicators of how well you're coming along is how mortified you feel when you think back to how much worse you were only two or three years ago. If you're doing it right and always learning and pushing yourself, well... that feeling probably won't ever go away.
|
|
#
¿
Feb 26, 2018 04:53
|
|
|
Thermopyle posted:FWIW, I've always found hourly rate * 1000 = annual to work about right for contracting/freelancing work.
|
|
#
¿
Feb 27, 2018 00:18
|
|
|
While there are so many web/enterprise/front-end/back-end/whatever jobs available, there are also a ton of people fighting over the jobs in this area. I'm coming from the embedded space, which has far fewer positions to interview for, and these stories about take-home projects, graph algorithm white board interview questions, and meta-interview prep studying amaze me. You folks have it tough. Embedded development interviews are far more straight-forward with far fewer games. We generally run into two big hurdles when interviewing, though: 1. You're being interviewed by people that don't have the knowledge to properly assess you on the material. It could be that a company suddenly find itself with a need to hire someone with knowledge on XYZ because they don't have that knowledge in-house, so they assign a couple of people to interview you who don't understand the details of what they're asking about. Or, maybe you're being interviewed by a PM that knows software and absolutely nothing about hardware. That's OK, though... these companies will eventually end up with some shyster that will make them think that he is working hard, but he's actually screwing around for 12-18 months before moving on just before he gets discovered. 2. You're being interviewed by a prima donna "expert" of some sort that wants to use the interview as an opportunity to show off what he knows. These guys love "trivia" questions and very specific questions that focus on really esoteric tidbits that only they know about because they tripped over it themselves three or four years ago. The big risk is that you won't be given the thumbs-up unless you have skills that fit into a particular band of ability. If you're too good, you're a "threat" and they'll find some excuse to avoid hiring you. If you're good and can do the job, you might get filtered because you aren't "good enough" per the expert's inflated ego. You have to be very good, but not too good, to pass that filter (which can be a bit tricky). Plus, do you really want to work with that guy if you get hired? To be fair, the majority of times that I have interviewed (maybe 90% of the time) have been with geeky guys that really enjoy working hands-on with embedded stuff. They're looking for someone that they can converse with on a technical level who can do the work and who clearly "gets" and "likes" doing that kind of work. I have run into both of the two interviewing hurdles I listed above on more than one occasion, though, and it has always been delightfully awkward each time.
|
|
#
¿
Mar 17, 2018 17:33
|
|
|
ultrafilter posted:I'm not really sure that those problems are unique to embedded development. I doubt they are.
|
|
#
¿
Mar 17, 2018 17:57
|
|
|
BurntCornMuffin posted:Can you go into further detail what a typical embedded interview is like? Like, what sorts of things get talked about in the course of a typical one? It all really depends on the position. My specialty has always been on using Linux, so questions about how to tailor a Linux kernel for an embedded environment, Linux device drivers, and embedded filesystem gotchas tend to be the main areas of focus in my prior interviews. I think you could ask a lot of the embedded folks on the forums what they get asked and get a broad variety of different answers. Embedded developers are also coming from EE, CE, or CS backgrounds, so they can focus on different aspects of the same development tasks. Being a person that can work on a team is so important in the embedded space: you're going to have to work with others to bring a product together. Very rarely is one person going to be able to handle all development aspects of an embedded project, unless the project is little more than a few tweaks to a vendor-supplied design and BSP. That's why I mentioned that your interviewers are typically trying to make sure you like and "get" the technology and that you are someone that they won't mind working with on it.
|
|
#
¿
Mar 17, 2018 21:00
|
|
|
speng31b posted:There are a lot more opportunities to remain IC out there; it's becoming more and more the path of least resistance nowadays in the opportunities I see popping up. Some of us relish the role of being an IC because it gives us time to privately consult on the side to double/triple the amount we can make. Sometimes, looking for the right IC role isn't about putting your eggs in the right basket, but rather about making sure that you always have more than one basket in the works.  I get that a lot of people don't have an entrepreneurial streak and just want to find a job that doesn't suck with a big paycheck. But... those truly awesome IC jobs are few, far between, and competitive. It's not so bad treading water at an average day job and then consulting/writing/whatever on the side. Seeing that this is the "oldie" thread, I would assume that most of the folks here have the technical experience to provide value as a consultant.
|
|
#
¿
Jun 2, 2018 18:18
|
|
|
mrmcd posted:I guess it depends on what you mean by a dream IC job? If it just money, it's not that hard to get a 200k+ total comp job as an experienced IC in NYC or the Bay Area if you go somewhere that isn't a startup trying to pay you in options monopoly money. True, but I suppose I'm talking more about those job markets with lower salaries that don't have such a critical mass of employers and jobs. Once you step outside of markets like NYC and work your way out towards the middle of the US, the job market is less dense and the cost of living is much lower. There are plenty of places where you can live a very nice 9-5 suburban lifestyle with your family in a house doing pretty boring dev work for $60k-$70k a year. It must be terribly frustrating for those experienced, ambitious engineers that can't relocate to one of the hotter market areas to experience a six-figure salary. But, they get their benefits in the form of a more laid-back lifestyle. The upshot is that if you're still a workaholic or someone that wishes to stay busy, consulting can really augment a lower IC 9-5 salary a lot and give you the opportunity to experience the without living in one of the primary job markets. You might also end up working on something far more interesting than your day job. 2nd Rate Poster posted:Are you able to talk some about how you started your consulting side business? It's something I've always been interested in, but finding clients seems tough. When looking at the typical scenario where a consultant works with an organization, the reason for hiring the consultant is to get skills or expertise that don't exist (or that there aren't enough of) within the company. The reason for that need might be the difficulty in finding the right person for the company to hire. Or, the need is a short-term need (prototyping, venture capital pitch, etc.). Either way, there is an immediate need and hiring a consultant or contractor is deemed the best path forward by the company. I would say that the two big challenges in consulting are finding the work and establishing your credentials as the right person to do it. The credentials portion is a bit more concrete, as you can build a portfolio of projects as you work your way through your career. Working at easily-recognized companies during the course of your career certainly helps. Open source projects help. Writing that helps establish you as an expert on the material (industry blog posts, magazine articles, books) goes a long way. Get really good at what you do. Ideally, if the company was to open a job req for a full-time position to do the work, you'd be a super strong candidate. Finding the work (or having the work find you) is the more difficult part. Hopefully, you've been networking as you've moved through your career. I don't mean shoving your business card into the face and hands of anyone and everyone and being pushy about how great you are. Seriously, don't be that guy. I mean becoming known as "that one guy from this other job I worked who really knows his stuff and is good to work with." Think back through the jobs that you've had and you'll probably remember a few engineers that were really good at their jobs that you would trust with their doing something really, really well. These engineers are the types that you'd recommend if your company had an opening and you were asked if you knew anyone who would be good. Your goal should be to become that engineer. It doesn't happen overnight, but rather happens over the course of your career. Make friends, demonstrate competence, and generally be that awesome person that gets things done. Hopefully, you've been doing this already. Roughly 40% of the consulting work I do is either someone I worked with pinging me to work on a specific project or me pinging them asking if there are any projects behind schedule that I could help out with. If you want to start consulting, this is where you start finding your first jobs. Track down old co-workers and ask them if their teams could use your assistance. The other 60% is from companies contacting me out of the blue asking if I can talk with them about a potential project. Almost every one of these contacts is from a manager that was given my name from one of his/her IC reports. The IC making the referral was digging around for info and came across my name from a response on a mailing list, forums post, code I wrote, paper/article I authored, conference talk I gave, or something like that. Sometimes, the IC had sent me a mail asking me specific technical questions that I responded to with a solid answer. You'd think that answering questions "for free" is a bad way to do business if you want to get a job providing solutions, right? But, I've always had really good results by doing this. Plus, after a while a lot of the questions are just a cut-and-paste of the same answers you gave someone else. Writing a book is, in my experience, the best way to establish your expertise and drive unsolicited work inquiries to you. PM me if you want tips and info on how to get started doing that. Having a website that shows off the things that you work on and your expertise helps. I don't use social media or a LinkedIn profile, so I can't speak to using those to advertise yourself and bolster your business. I get enough junk mail from recruiters as it is, so I'm just fine with staying off the standard tech talent radar. I have never cold-called a company and tried to solicit business. I suppose you could try doing that by looking for companies with a lot of open positions and then using LinkedIn or strategic googling to contact a manager and pitch yourself as a consultant. That is very much not my style and I would feel uncomfortable doing it like that. Niche expertise pays a hefty premium, but jobs are fewer and far between. It is also harder to establish yourself as an expert in these areas. Generalist work is much more common and easier to get. Such work doesn't require an expert, though one is certainly welcome if the expertise can be had at a good price. Pick your poison. Start as a generalist and work towards niche work when possible.
|
|
#
¿
Jun 2, 2018 21:22
|
|
|
|
| # ¿ May 21, 2024 07:19 |
|
|
Way, way back in April 2017, I was looking at changing jobs and asked the thread a few questions. Among them was this:quote:2. I have research publications under submission in which I am the first (primary) author. I did all of the research work, gathered/analyzed the data, and wrote the papers. I will leave before I get accept/reject notifications on them. Do any of you have experience with how to handle this sort of thing? If any papers are accepted, someone still needs to attend the appropriate conferences to present the findings. I'm not worried about my pending patents, as my name was listed as a co-inventor on the filings and I can't imagine I'd be removed from anything after the fact because I left... I have an update! I don't think I ever mentioned that paper again, but it did end up getting accepted. I presented it at a conference in September 2017. I paid out of pocket for the conference registration, plane tickets, hotel, and other expenses because my old company wasn't going to. After presenting the paper and filling in my old PhD advisor (one of my co-authors) on how it all went, my old advisor told me to prepare an expense report for all of my expenses and that his lab would cover it all. As for the last patent application that I had pending, that patent was awarded by the US Patent Office about a week ago. I didn't even know that it went through until I suddenly received a bunch of junk mail from several companies trying to sell me one of those patent award plaques that companies like to hang up in their lobbies to impress people. The new job has been going well for the past year and I've even made a few referrals that have been hired. So, all's well that ends well!
|
|
#
¿
Jul 18, 2018 00:35
|
|