|
Doctor w-rw-rw- posted:I start on a trial at an early-stage startup (still in stealth) tomorrow. Any clues on what I should expect from companies where my employee number is going to be a single digit? "On trial"? Does this mean they don't pay you in full or something?
|
#
?
Feb 28, 2014 21:03
|
|
|
|
| # ? Apr 19, 2024 00:09 |
|
|
Otto Skorzeny posted:"On trial"? Does this mean they don't pay you in full or something? It means they hire me as a contractor before hiring me full-time. I knew one of the founders from college, and basically talked to them for an afternoon before they said "okay we'll try you out." The pay is very reasonable and the cofounders are reputable.
|
|
#
?
Mar 1, 2014 06:36
|
|
|
Doctor w-rw-rw- posted:It means they hire me as a contractor before hiring me full-time. I knew one of the founders from college, and basically talked to them for an afternoon before they said "okay we'll try you out." The pay is very reasonable and the cofounders are reputable. I can offer two bits of advice having worked for a variety of startups for the last decade. First, expect to wear a lot of hats. If you can't do a thing, you should be the kind of person that can learn to do that thing if nobody else already knows it. Someone else might be willing to learn it too, that's fine, but start from the assumption that you will do everything. If every employee doesn't have that attitude, your startup is doomed, so part of pulling your weight is taking responsibility for all of the things you can. Obviously this doesn't mean you must do the accounting, but it might, and it certainly means you'll want to know that the accounting is getting done, and done right. Second, and akin to the first, is that your communication is going to have to be very different in a startup, especially early-stage. Do NOT have meetings about everything, or long discussions about anything. Make decisions and get on with it, somebody has to. Learn what to bother others about and what not to. If it affects them, learn what to ask their opinion on and what to simply inform them of. Do not be afraid of arguing points with anyone, but never argue people. If you are going to take it personally that someone questions your every idea or choice, even if they're not going to literally do that, a startup may eat you alive. If the person to get eaten is one of your coworkers, better find that out quick, as you'll be taking a lot of responsibility for everything they can't handle. This is where you separate people from what they can or can't do. Don't argue people, but if someone can't do their job, you have to address it. It doesn't have to be personal, it shouldn't be, but it does have to be addressed. Everything else I could possibly relate to you is built off of that. Tread quickly, lightly, and get up every time you trip. Hope it works out well =cP
|
|
#
?
Mar 2, 2014 08:45
|
|
|
This is basically what I would have said as well. Expect responsibility, lots of it. Think about Microsoft in its early years, when the "shipping department" meant whoever happened to answer the phone when an order came in. And for the sake of your sanity, remember that some startups succeed but many more don't, and not only for lack of effort.
|
|
#
?
Mar 2, 2014 23:25
|
|
|
Protip for Google. Don't go for Frontend roles because then they make you do javascript/front-end questions for 3 interviews, then your choice of c, c++, java, python for 2. Plus since you're doing Frontend, they are free to ask frontend questions as well as CS fundamentals. (although I guess they mostly combine together) 
|
|
#
?
Mar 5, 2014 19:19
|
|
|
Strong Sauce posted:Protip for Google. Don't go for Google. They have a pretty broken hiring process overall. My most recent dealing with them was a phone screen that involved writing Java that compiled in a plaintext online editor and getting nitpicked on style. I ended up with a correct solution, but didn't pass on to the next stage probably because I sounded totally out of my element writing Java in an online notepad (no poo poo)! The previous time from that I was interviewed by a O(n) sperglord who wanted very mathematically precise bounds. Forgetting that he became a SDE after transitioning from a SRE, and that I was not interviewing for a core services group, that disqualified me too. Though that was slightly more justified I suppose, if you just take it for granted that that's what Google wants. EDIT: though I suppose that sounds like sour grapes, a number of people I know have tried and had similar experiences in their rejections Doctor w-rw-rw- fucked around with this message at 01:20 on Mar 6, 2014 |
|
#
?
Mar 6, 2014 01:13
|
|
|
Doctor w-rw-rw- posted:FTFY. I don't doubt that Google's hiring process is flawed since I've read all the horror stories. But who has a good one? I'm guessing Google rejects at a much higher frequency than most other companies mainly because it can afford to and you don't hear about the rejections from the midlevel companies. Anyways I went into an onsite today and they asked me the, "given rand5, write rand7". I've seen the question but didn't feel it was something that people actually asked. But I did get asked it and I bungled the answer. Not sure what I would have done had I knew the answer but when was the last time you had to worry about not being able to generate random numbers...
|
|
#
?
Mar 6, 2014 05:22
|
|
|
The idea is that they want to hire people who are not dumb. You don't need experience with random numbers to answer that question. Also, now that you mention it, I've worried about uniformity of random number generation several times in my career.
|
|
#
?
Mar 6, 2014 05:28
|
|
|
shrughes posted:The idea is that they want to hire people who are not dumb. You don't need experience with random numbers to answer that question. Haw you are probably right. Except I didn't say you needed to understand random numbers to get the answer. I meant the question is something no one has to worry about.
|
|
#
?
Mar 6, 2014 06:09
|
|
|
Well actually, if you want to generate a uniformly random number in C, you do have to worry about it. Whether you use rand() or read bytes off of /dev/urandom, you'll have to convert from base 2^k to whatever your number is.
|
|
#
?
Mar 6, 2014 06:25
|
|
|
What's really interesting actually is that two totally contrived-looking interview questions that my company used to ask wound up having slightly trickier versions actually practical to use in real code. One of them was akin to reordering messages that arrive out of order, only it looked like some kind of sorting algorithm, and another was akin to blocking read/write operations to sectors of a file while preceding read/write operations are still running (because the kernel or some filesystem doesn't guarantee ordering very strongly across threads or iocbs). Both the real problems were online versions of the interview problems.
|
|
#
?
Mar 6, 2014 06:30
|
|
|
shrughes posted:Well actually, if you want to generate a uniformly random number in C, you do have to worry about it. Whether you use rand() or read bytes off of /dev/urandom, you'll have to convert from base 2^k to whatever your number is. If you're using rand() you might as well not worry about it and just use mod since your results will be poo poo regardless of what you do.
|
|
#
?
Mar 6, 2014 06:55
|
|
|
shrughes posted:Well actually, if you want to generate a uniformly random number in C, you do have to worry about it. Whether you use rand() or read bytes off of /dev/urandom, you'll have to convert from base 2^k to whatever your number is. Yes. I'll make sure to take this into account if there is ever a situation where rand() is pseudorandom but rand5() is somehow truly generating a number between 1-5 randomly.
|
|
#
?
Mar 6, 2014 07:35
|
|
|
Plorkyeran posted:If you're using rand() you might as well not worry about it and just use mod since your results will be poo poo regardless of what you do. Please don't be that guy that assumes because you haven't heard of it, it doesn't exist or isn't important.
|
|
#
?
Mar 6, 2014 12:04
|
|
|
I hate the rand5/rand7 question because it's less about programming and more about math. If you want a mathematician, hire a mathematician. If you want a software developer, hire a software developer. If you want someone that can think, ask questions that demonstrate thinking ability, not specific exposure to mathematics or software development concepts. I typically start with a modification of fizzbuzz that won't evoke a simple regurgitation of a fizzbuzz (change fizz and buzz to something else, change the divisors and range, see how they do). If they immediately recognize it as a fizzbuzz style program, that's a different kind of intelligence and I think that passes my initial requirements of basic intelligence. If I want someone really smart I have more options. 3D graphics programmer? Get them a blacksmith's puzzle (one of those metal things that are combined and you have to figure out how to get the loop off or whatever). Want to know how organized they can be? Talk about marbles. Cats eyes of different kinds, mottled painted, shooter marbles, solid colors, clear, different weights, etc. See how they would organize them into small cups, make sure to have some categories that won't all fit in one cup (there are 3 cups worth of solid blue marbles, for instance). It's open ended, doesn't have a "right" answer, and will show you how they think about organizing things just like they'll organize code (at a rudimentary level). My favorite is to get something fundamental like how to program an ant on a 2D plane to find the sugar in a maze, report the location to its colony (at a wildly different location), and find a reasonably direct path. There is no way someone can spit that out in an interview, but it will teach you about their ability to think. The downside to this is you have to be as smart as you expect them to be at the very least. If you don't want to be as smart as the people you hire to do a thing, a good general style of question is general concepts that software engineers have to think about when defining their work. Talk about tradeoffs in algorithms, talk about the advantages and disadvantages of depth of knowledge in a specific language, or how it gets from the text you have into the thing that runs on the target hardware and how that actually gets affected at what stages (the code, the compiler/linker, the runtime, the processor, etc). Interviews can be fun or they can be petty pissing contests about how "field X" is somehow important. Minimal knowledge is required to be smart, so I despise people that want to know more about your academic memorization instead of your ability to think about problems and their possible solutions. Personally I prefer people that can do the latter, especially since it applies to all fields, not just software dev. My previous HR manager could think better than half the devs at my current job.
|
|
#
?
Mar 6, 2014 18:00
|
|
|
If someone asked me to solve one of those interlocking toys in an interview, I'd walk out.TodPunk posted:My favorite is to get something fundamental like how to program an ant on a 2D plane to find the sugar in a maze, report the location to its colony (at a wildly different location), and find a reasonably direct path. There is no way someone can spit that out in an interview, but it will teach you about their ability to think. A* only takes about a minute to describe. Either your interviews are really short, or you're wasting too much time playing with children's toys.
|
|
#
?
Mar 7, 2014 03:48
|
|
|
Grocer Goodwill posted:If someone asked me to solve one of those interlocking toys in an interview, I'd walk out. First, A* is only going to help if you know your destination. You don't know where the sugar is. Second, I used the word "fundamental" for a reason. It doesn't matter if they happen to know A* or they don't. Seeing how they approach the problem and identify that A* (or whatever they might make up) is applicable, that's more useful in determining their skills in problem solving, NOT programming. It's also not an algorithm that's commonly known outside games or AI. If I were in either of those industries I'd probably make up a different problem. I made up the ant one as I wrote the post, so I'm sure I could do it again in wildly different directions.
|
|
#
?
Mar 7, 2014 09:01
|
|
|
Also, the state space of a maze is proportional to the size of the problem description, so A* would be completely unnecessary.
|
|
#
?
Mar 7, 2014 09:15
|
|
|
TodPunk posted:I hate the rand5/rand7 question because it's less about programming and more about math. If you want a mathematician, hire a mathematician. If you want a software developer, hire a software developer. If you want someone that can think, ask questions that demonstrate thinking ability, not specific exposure to mathematics or software development concepts. I'm not going to tell you how to run your interviews but whipping out a toy puzzle sounds infantilizing.
|
|
#
?
Mar 18, 2014 02:26
|
|
|
RICHUNCLEPENNYBAGS posted:I'm not going to tell you how to run your interviews but whipping out a toy puzzle sounds infantilizing. So your position here is that because it is physical in nature, it must be for children? Examples: http://www.tavernpuzzle.com/ http://www.mrpuzzle.com.au/category65_1.htm If you would prefer, one could see their approach to something akin to Sudoku, so long as you can produce something they likely haven't seen before. For the 3D space thinking that the original intent was for, you could ask them to think about implementing Escher stairs or something if you just want to have a chat.
|
|
#
?
Mar 20, 2014 14:10
|
|
|
TodPunk posted:The rand5/rand7 question is silly because it has nothing to do with the job I'm hiring for, instead I would ask programmers about organizing marbles and solving blacksmith puzzles.
|
|
#
?
Mar 20, 2014 15:21
|
|
|
There's an old pen and paper game that starts with a grid of 1-9 or 1-16, the player has to have the pen on a number to start and other people call out the next number for them to draw a line to. Lines can't cross. Somehow this game came up out at lunch with some layout folks. They absolutely destroyed this game, in the way that makes you unable to imagine how there's any challenge in it for anyone else. Their skills at routing a bunch of wires around with goofy constraints mapped exceptionally well to the game. I don't think physical objects imply infantalization. I think admitting you have no germane test of the actual skill under consideration and must make a leap over to a close-but-not-quite children's timesink game is the objectionable bit. Do you actually do these things in your hiring process or are you guessin' it sounds good for folks you don't actually interview?
|
|
#
?
Mar 20, 2014 17:34
|
|
|
JawnV6 posted:I don't think physical objects imply infantalization. I think admitting you have no germane test of the actual skill under consideration and must make a leap over to a close-but-not-quite children's timesink game is the objectionable bit. Not really, I used them in my description mostly as example of the goal. I've used puzzles twice, and I didn't go into the interview planning to use them. Both interviewees got the job, but they were both entry level and struggled to sell themselves and their abilities to problem solve. I brought the puzzles in to help them show their ability to think through a problem and it worked well for both us and them. I also prefaced that it was weird but that I thought it would help them show off. I'm not going to stick to propriety if it will squander someone's potential for not reason. The last senior level developer position I interviewed someone for we talked shop with for a while and we talked about problem spaces he enjoyed and I came up with a couple code excercises in that general space. He was fantastic, but we didn't hire him, because that company is stupid and can't make a decision in under a month. He found someone else within a few days.
|
|
#
?
Mar 21, 2014 04:40
|
|
|
JawnV6 posted:I think admitting you have no germane test of the actual skill under consideration and must make a leap over to a close-but-not-quite children's timesink game is the objectionable bit. Do you actually have a test of 'general ability to program'? I'd love to have that before we hire anyone else. It would be legit weird to be handed a puzzle in an interview, though I'd probably enjoy that because I love that kind of stuff.
|
|
#
?
Mar 24, 2014 19:33
|
|
|
Munkeymon posted:Do you actually have a test of 'general ability to program'? I'd love to have that before we hire anyone else.
|
|
#
?
Mar 24, 2014 19:43
|
|
|
Cicero posted:I took a programming aptitude test like that in my senior year, when I was applying to Pariveda, a software consulting company. It just described the syntax for a simple language you haven't seen before, and then you did some very simple problems in that language. Me and the other CS major taking it (most of the people in the room were MIS) finished it very quickly, anyone with significant programming experience would find it trivial. As a former employee there, I can tell you it was the B-APT test seen here: http://www.psy-test.com/Baptd.html (may have been the advanced one, I don't know which one they gave) And while they never really hired anybody who was a total zero at programming, they could have been weeded out after a false positive on passing the test for all I know.
|
|
#
?
Mar 24, 2014 20:42
|
|
|
Munkeymon posted:Do you actually have a test of 'general ability to program'? I'd love to have that before we hire anyone else. Figure out IDE preference in phone screen. Create a skeleton program in that IDE with JavaDocs and pair program it with them driving. It works extremely well for us, with people who can't code or read docs filtered out.
|
|
#
?
Mar 24, 2014 20:43
|
|
|
I got this job doing .NET programming, and I'm totally disappointed. I consider myself a really good programmer, it has been one of my primary interests since like middle school, and I've been teaching myself constantly since then. Before I got this job while I was in school I was working on writing a library and publishing a paper on it with one of my professors, but some french dudes beat us to the punch and now their poo poo is getting adopted into boost so we stopped. I designed the whole thing, and actually took the leadership role while we were working on it (I was an undergrad then). Even though it didn't result in much, I'm proud of this fact and felt vindicated that a library which was designed and implemented the same way as mine is getting added to boost. Just mentioning this not to brag, but to show where I'm at skills-wise, and where my interests are. Anyway, this .NET job was the first one I applied to, and they rushed me through the whole process and then rushed me into accepting the job offer. I stopped going forward with a bunch of other companies which seemed a lot cooler because I didn't want to risk not being able to pay for student loans, food, and shelter. I was under the impression that it was an extremely competitive position (they have me administering technical interviews and exams now, and I can see it isn't very competitive). I ended up taking a few thousand less than the average .NET developer, I was OK with this because I could see how I might appear to be a risk (just out of school, not too many completed projects to my name. I turned down a lot of internships because they didn't interest me so I didn't have much of a work history.) and because I was told I could get raises quickly if I came in and kicked rear end. Since I been working here, I'm just like, goddamn. Their process is totally retarded, and no one (from my level to the CTO) seems to give a poo poo about or understand software engineering principals. In my second week I found myself making suggestions to everyone about how to improve the glaring flaws in the process, but I was argued down. I didn't want to be too assertive or sound condescending, since I was still new, but basically people walked all over me even though I knew they were wrong, which was very frustrating. To give an example of the magnitude of problems I am talking about: when I first came in, 40 - 50% of unit tests were failing. I was very surprised to learn that this had been the case for multiple iterations, and it was considered to be just an unfortunate fact. I couldn't believe a company which creates tools for the government and massive corporations had such lax standards! We even released software recently with failing unit tests (I mean a lot of failing unit tests). Another example is that project stakeholders do not review acceptance criteria in order to verify they are correct, normally a common practice. There was also no process in place to have developers implement CHANGES to acceptance criteria -- only new acceptance criteria was passed on to the developers. Managers ignored acceptance criteria otherwise. These are just a few of the problems with the software engineering process, and all of these things have resulted in tangible problems for the business owners in the past. The code base is terrible. Let me just say that our flagship project is a massive piece of software which interfaces with numerous other components in our suite. The bulk of the code (around 50%) for this core application is located in a single class -- Program. The project is 100s of thousands of lines of code. I think this fact alone should indicate that I could write for hours about the problems with the code base, but this is already getting too long. I know everyone here has encountered terrible code -- I've only been a professional developer for a few months, and I feel like I've seen it all. These problems with the codebase and process should be very real to everyone (business owners, managers, etc), not just myself and other developers. We released our latest version of the software about 4 months late, and now it is revealed that we will have to pull it most likely because it is so broken. But no one seems to care. I've always fought to improve our process and practices, and usually I'm argued down. 2 months after I make a suggestion, some disaster will happen, and my suggestions are usually implemented quietly. On the latest tasks I was assigned, I argued with senior level developers for 3 days to let me implement some refactors in the area I was working in. The way the area is designed right now is basically a war crime. For example, rather than having a member of a class just be a normal member, it is a static dictionary which associates thread ids to instances of the member. Rather than just working with the object you instantiated on that thread and looking at the value of its member, you consult the static dictionary, and check which thread you are on, to see the value of that property for the class on that thread. I proposed some redesigns (which seem obvious to me. I don't know how it ended up this crazy way in the first place) that would make this area of code like 1000x more maintainable. By the end of it, even though everyone agreed that my way was the best, they still wouldn't let me do it because there was no time. Surprise, surprise, our changes cause a huge amount of bugs in this utterly chaotic area of the code base and we now have to spend a ton of time fixing it. I practically begged them to just let me fix it properly, but still no go. I really resent having to explain basic things to my superiors, while still be condescended to regularly. All the while my very obvious suggestions are ignored. One time the senior level developers were doing profiling on the debug build. I told them that running performance profiling tests on the debug build was wrong, and that you should do profiling on the release build. They literally laughed at me, and dismissed my suggestion with some comments that reflected huge gaps in their knowledge. I tried to tell them some fundamentals about how compiled languages work and the differences in the assemblies which are generated in the two modes, but they wouldn't hear it. I finally just pulled up msdn and they admitted I was right, but still didn't do it. I finally got a raise after several months of work (it was prorated), and it was less than the rate of inflation. They city I'm in doesn't have a ton of other programming jobs and my lease doesn't expire for months. Please give me some advice about how I can get out of this trench. Are my expectations unrealistic? HELP
|
|
#
?
Mar 27, 2014 02:19
|
|
|
First, are you in the US? Second, government work probably has less rigorous processes. If things were written well the government could hire someone else to do the job. Obfuscation = Job Security It is obvious what you have to do. Move to another state where there are more jobs where they can pay you more. Depending on what state you live in, breaking a lease is doable for a penalty fee. It cannot possibly be more than the actual amount of money you should be making. At the very least you recognize you are being hosed over and this is your first job and not, say, your third job before you realize this. If you really cannot leave your city/state or whatever and don't want to break your lease. I would contact some of those other companies and see if they're still interested or have any positions open. Continuing to work at your current company is bad for your career and sanity. Oh yeah and when you tell them you are leaving, refuse when they offer to raise your salary.
|
|
#
?
Mar 27, 2014 02:40
|
|
|
Strong Sauce posted:Oh yeah and when you tell them you are leaving, refuse when they offer to raise your salary. Yeah, counteroffers are often a delaying tactic so they can train a replacement because they didn't care about bus factor. Too often, the damage has been done already and you're not in for the long haul and both parties know that. You need some pretty hefty incentives to make it worth it, and if they've already demonstrated how little they value you, they're not likely to change their mind until the pain of a lost employee is fully realized.
|
|
#
?
Mar 27, 2014 03:07
|
|
|
I'm in the US. It's not government work in that I'm working for the government, we just have a contract with the government so I guess the quality doesn't matter (my friend jokes with me that it is essentially a golden ticket). I feel like I gotta finish some personal projects before I start looking again, so that I have a better chance of getting a job in a field that I actually want to work in and have been studying for years. Like embedded systems or games. But there's no time, because I have to work unpaid OT (I'm salaried, which has only meant so far that I have to work late and on weekends for no extra money) all the time since we hosed up our release so bad. Haha, I definitely would not accept an offer to raise my salary. I dream of the day when I can give my two weeks notice. I can't imagine this company will last long, given the TERRIBLE quality of the software. Thanks for the advice guys, this poo poo has seriously got me stressed out. I can't imagine getting into a rut in this job and working here for years.
|
|
#
?
Mar 27, 2014 03:49
|
|
|
Dog Jones posted:when I first came in, 40 - 50% of unit tests were failing. I was very surprised to learn that this had been the case for multiple iterations, and it was considered to be just an unfortunate fact. Such as PHP.
|
|
#
?
Mar 27, 2014 05:04
|
|
|
Plorkyeran posted:It's okay, you're in good company. at least there are unit tests
|
|
#
?
Mar 28, 2014 02:07
|
|
|
Does a unit test actually exist if no one ever actually looks at the results of running it?
|
|
#
?
Mar 28, 2014 02:42
|
|
|
JawnV6 posted:There's an old pen and paper game that starts with a grid of 1-9 or 1-16, the player has to have the pen on a number to start and other people call out the next number for them to draw a line to. Lines can't cross. So the Zelda puzzle where you have to walk on all the tiles?
|
|
#
?
Mar 28, 2014 04:06
|
|
|
TodPunk posted:Not really, I used them in my description mostly as example of the goal. I've used puzzles twice, and I didn't go into the interview planning to use them. We do a design challenge. Essentially a small product we ask the candidate to architect and present. We make consumer electronics, and we scale the problem to the candidate (e.g. a senior candidate will be told to source an image sensor, with someone more junior we might provide one). It's proved a very effective filter for the type of candidates we're interviewing. Dog Jones posted:I got this job doing .NET programming, and I'm totally disappointed. I consider myself a really good programmer, it has been one of my primary interests since like middle school, and I've been teaching myself constantly since then. Dog Jones posted:They city I'm in doesn't have a ton of other programming jobs and my lease doesn't expire for months. Please give me some advice about how I can get out of this trench. Are my expectations unrealistic? HELP Suspicious Dish posted:So the Zelda puzzle where you have to walk on all the tiles? e: sorry, this was a draft for a while, posting instead of letting it languish the weekend
|
|
#
?
Mar 28, 2014 16:34
|
|
|
Are you sure that you're not coming off as a smug prick when you're interacting with your co-workers? I'm not saying that you're coming across that way here, but it's something to be careful about. I've been in a similar situation before, and I ended up being a smug prick and no one gave a drat about what I had to say because of it, even when I was right. Some people hate being told they're wrong, or that they're doing things in a bad way. Especially if the person saying it is a lot younger than them. I've learned since then to never outright tell someone that their code/architecture is bad, even if it's so awful that your eyes bleed when you look at it. Instead of being confrontational ("Hey, look at this stupid poo poo, what the gently caress, this is a war crime, we should be using the Butthole pattern instead!"), ask questions and be constructive ("Hey, I was looking this code over, and I was wondering why we didn't write it using the Butthole pattern?"). Sometimes, you'll ask that question and get an answer that surprises you. Sometimes, something that looks lovely was written that way for a very specific, weird-but-valid reason. If it makes you feel any better: based on your post, I'd call you in for an interview. You sound like you know what you're talking about in terms of software development principles, and I don't care if you have 0 years of experience if you write good code. New Yorp New Yorp fucked around with this message at 09:07 on Mar 29, 2014 |
|
#
?
Mar 29, 2014 08:56
|
|
|
rrrrrrrrrrrt posted:I'm sure there are plenty of stable jobs around, but I would plan on job hopping a couple times before landing in one. Don't settle for the first job you find if it isn't going to work out long term (and if you've been in the industry 10 years you should be able to figure this out pretty darn quickly). Explaining job hopping to interviewers sucks, but it's better than gutting it out at a terrible job for several years. Doctor w-rw-rw- posted:There are large stable .NET shops around, they just don't get talked about a lot. A friend of mine works at Ancestry.com, I think, and they have a lot of .NET. I think they're transitioning a bit to Java, though. Thanks for the advice guys. I went on a few interviews and landed a .net development/ALM position with a large and established consulting firm where I'll make 16k a year more.
|
|
#
?
Apr 20, 2014 14:21
|
|
|
In response to the OP, I'll throw in my experiences of working different job types in different company types for the sake of deciding whether you might like that sort of thing yourself. - If you take on a team lead role, expect to do very little actual development, or expect to do both badly. Best be OK with this going in or it'll be a shock. - If you take on a product role, expect to lose your dev knowledge. It comes back when you start exercising it again, but it can be a real issue during interviews if you're trying for a senior dev role with interviewers who know their poo poo. - R&D roles in web development are mostly about analytics, fancy prototypes, and negotiating integrations with startups. See "product role" caveats. - Treat early-stage startups like an unexploded bomb, especially if they have a high dev turnover. Beware "meddling founder" syndrome. +1 to all the previous comments about wearing lots of hats. - Treat late-stage unsold unprofitable startups like a sick dog with a shotgun to its head. Investors aren't going to pour much more in before they demand profitability, and that usually means staff cuts. - Ruby is no longer the shiny new thing in web dev, but it is really hitting its stride in terms of getting yourself paid, at least in London. Senior Rails devs are getting regular contracting offers of £450+/day on 12 month contracts. Competent permanent employees are being snapped up within hours of quitting. No idea how many more years this'll last. Could someone in the states chip in on the state of things there? For what it's worth I've stopped working jobs with heavy responsibility. There's more autonomy and a sense of leadership, yes, but it comes with a hell of a lot of stress for no real benefit.
|
|
#
?
Apr 20, 2014 17:05
|
|
|
|
| # ? Apr 19, 2024 00:09 |
|
|
Arachnamus posted:- Ruby is no longer the shiny new thing in web dev, but it is really hitting its stride in terms of getting yourself paid, at least in London. Senior Rails devs are getting regular contracting offers of £450+/day on 12 month contracts. Competent permanent employees are being snapped up within hours of quitting. No idea how many more years this'll last. Could someone in the states chip in on the state of things there? I can't speak for the whole US, but for the western half, Rails is mostly a startup language. If you are not willing to have most of your pay be in stock options, you probably don't want to go that route. Though the contracting bits are accurate, I don't think they're as prevalent here. Most of the contracts I've seen on the likes of Dice for Washington and Utah have been maintenance/integration pieces. Getting picked up quickly though, that's very true if you're in the right area. In Utah valley (around Salt Lake City), there are a LOT of startups, so you can hop quite a bit. +1 on lacking responsibility. I can get paid just as much to dev with expertise as I can get being middle-management or "team lead" or whatever they want to dress it up as. I just want to make awesome stuff, not herd cats and make management feel good about it. I may or may not be a little bitter about that right now. *ahem* But yeah, don't stress unless it's a project you really believe in. It's just not worth it.
|
|
#
?
Apr 21, 2014 14:49
|
|