Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
JawnV6
Jul 4, 2004

So hot ...

Dog Jones posted:

I want to get into embedded systems. I think I am qualified. In general I am a very experienced programmer. I know a lot about programming in assembly w/ several different types of instruction sets, low level optimizations, operating systems, concurrent programming. However, I have never actually done anything with embedded systems, and don't know much about electric engineering. Should I bother applying for embedded systems jobs?
Assembly matters a lot less than ADCs? Design patterns less than datasheets. I've never worked on something beefy enough to require a scheduler, much less an OS.

Depends on the job. I went from a low-level coder to an embedded position a year ago and it's been fantastic. I can't say that everyone can make that switch as my circumstances were not typical, but it's not out of the realm of possibility. Knowing 0 EE hurts you, but most team making consumer electronics have a lot more FW than EE, I've heard of ratios like 3:1. You need to be looking at bigger places. Both because you can be more isolated from the EE side and because they can afford some of the senior time to ramp you up in embedded. Make your current position and goals clear on your resume and see who calls you back.

Doctor w-rw-rw- posted:

Agree on the intent section; disagree on two pages. It makes a difference when reading and marking up a resume. It means staplers whenever you print copies out or the risk of mixing up the papers. It's a pain.
I'm not terribly attached to the position, but the two resumes I've reviewed this week were 2 and 5 pages. If you can condense it to one that's great, but don't sacrifice quality just to meet that standard.

Adbot
ADBOT LOVES YOU

Paolomania
Apr 26, 2006

Thanks all. I've decided to flesh it out to 2 pages - in large part to pre-answer questions about the gaping hole between undergrad and grad school. I'll add an intent and keep the clearance info and put the CG artist stuff under a separate "Other Professional Experience" section.

Doctor w-rw-rw-
Jun 24, 2008

JawnV6 posted:

I'm not terribly attached to the position, but the two resumes I've reviewed this week were 2 and 5 pages. If you can condense it to one that's great, but don't sacrifice quality just to meet that standard.
Fair enough, I retract my opinion.

Hiowf
Jun 28, 2013

We don't do .DOC in my cave.

Dog Jones posted:

I want to get into embedded systems. I think I am qualified. In general I am a very experienced programmer. I know a lot about programming in assembly w/ several different types of instruction sets, low level optimizations, operating systems, concurrent programming. However, I have never actually done anything with embedded systems, and don't know much about electric engineering. Should I bother applying for embedded systems jobs?

There's this level nowadays where your hardware is powerful enough to run a full OS (usually Linux) but is weak enough that a strong understanding of all the things you list helps enormously in making good, performant applications, and where you maybe will need to debug some peripheral on an EE level every once in a blue moon. It's often still called embedded but you could also call it mobile.

Sounds like you'd be a decent fit. Should also be obvious how to get some small extra foot-in-the-door experience in that area.

geetee
Feb 2, 2004

>;[
I'm tired of my job. The pay and benefits are fine, but the work is pretty miserable. It's a lot of developing on top of proprietary systems. Challenging for all the wrong reasons. I can screw around for half the day and still make everyone happy with the amount of work I get done. The bar is low.

I feel like I'm in a slump because I am pretty much sick of computers by the time I get home. I try to do "startup" projects on the side to give me a reason to learn new languages and such. Part of me starts to wonder if I don't like my trade anymore, but I have a blast when I work on my own stuff. It's just hard to get started going.

I need to get myself out of this place because it is clearly toxic. I'm really bad at interviewing and I think that's holding me back. I'm not a genius, but I know I'm really good at what I do. I just totally gently caress up the white boarding stuff because I'm horrible at being on the spot. I freeze up, but can solve the problems in no time after the fact under real working conditions. How do I get better at this? Do I need to?

Lastly, how do you approach job postings that don't list salary information? I don't want to waste my time or theirs if we're far apart on expectations.

Cicero
Dec 17, 2003

Jumpjet, melta, jumpjet. Repeat for ten minutes or until victory is assured.

geetee posted:

I need to get myself out of this place because it is clearly toxic. I'm really bad at interviewing and I think that's holding me back. I'm not a genius, but I know I'm really good at what I do. I just totally gently caress up the white boarding stuff because I'm horrible at being on the spot. I freeze up, but can solve the problems in no time after the fact under real working conditions. How do I get better at this? Do I need to?
How much have you practiced at whiteboarding in the past? Like any skill, it takes work. I know a guy who got a job coding at Amazon out of college in spite of his 1.96 GPA (and in EE, not CS), probably because he ran through 200 coding exercises beforehand.

Beyond just coding up lots of problems on your computer, I think it's also important to practice at least some of the time in the right environment: simulate phone interviews with a friend using Skype/collabedit, and in-person interviews with a friend and a whiteboard or piece of paper.

Strong Sauce
Jul 2, 2003

You know I am not really your father.





Download Cracking the coding interview free pdf. (Note there are some errors in the book)
Buy a whiteboard.
Grind it out.

Jaded Burnout
Jul 10, 2004


Is this whiteboarding business really that common over there? The last few jobs I've had have been on the strength of a conversation.

Hiowf
Jun 28, 2013

We don't do .DOC in my cave.

Arachnamus posted:

Is this whiteboarding business really that common over there? The last few jobs I've had have been on the strength of a conversation.

I have no idea what "over there" means but the jobs I had in the US and Europe all involved coding as part of the interview.

There can be exceptions, like if you have public portfolio and the work is consulting (where you won't get paid/get kicked instantly anyway if you don't deliver).

How can you tell from a conversation whether someone can program?

baquerd
Jul 2, 2007

by FactsAreUseless

Arachnamus posted:

Is this whiteboarding business really that common over there? The last few jobs I've had have been on the strength of a conversation.

If we hired everyone that talked a good game, I'm pretty sure we'd quickly turn into a dysfunctional mess.

qntm
Jun 17, 2009

Skuto posted:

I have no idea what "over there" means but the jobs I had in the US and Europe all involved coding as part of the interview.

There can be exceptions, like if you have public portfolio and the work is consulting (where you won't get paid/get kicked instantly anyway if you don't deliver).

How can you tell from a conversation whether someone can program?

I thought "coding as part of the interview" was not exactly the same thing as whiteboarding.

On a white board you have no idea whether what you wrote is correct. If the interviewers are in some fashion looking over your shoulder while you actually write code, that's a different thing because you can try to see what will or won't compile/run before returning your answer.

Hiowf
Jun 28, 2013

We don't do .DOC in my cave.

qntm posted:

I thought "coding as part of the interview" was not exactly the same thing as whiteboarding.

On a white board you have no idea whether what you wrote is correct. If the interviewers are in some fashion looking over your shoulder while you actually write code, that's a different thing because you can try to see what will or won't compile/run before returning your answer.

Sure, but both, even if not exactly the same, are pretty much opposite from "on the strength of a conversation".

I've done both, and although coding on a real PC may make the interviewee more comfortable, it tends to be harder to have a good discussion during the solution. I don't see why you'd care if your stuff runs/compiles - it may make you feel good but I doubt it correlates much to your passing chances.

Sagacity
May 2, 2003
Hopefully my epitaph will be funnier than my custom title.
When we get someone in to do some pair programming we typically don't do a "blank exercise" that they'd be able to do on a whiteboard. Instead, I introduce a bug in our system (typically our frontend website, because that's easy to visualize) and tell them to debug it. The bug can be something simple like flipping the checks on our login page so only invalid credentials are allowed for logging in.

I tell them they shouldn't be shy about asking questions, Googling or whatever they need to find the bug.

Our codebase is pretty big and it's interesting to see what happens next: Some people get overwhelmed and have no idea where to look. They may spend a huge amount of time just poking around. Some of them start talking about interesting design patterns they learnt about while getting their MCSE while failing to fix the bug. Others clam up. The best developers quickly find (or ask!) the main website project, figure out where the controller is, find an AuthenticationService and fix it. Even more bonus points for those that jump straight to the unit tests and run them to find out what's wrong.

It becomes much easier to determine if someone will fit in when you do an exercise like this.

shrughes
Oct 11, 2008

(call/cc call/cc)

qntm posted:

On a white board you have no idea whether what you wrote is correct.

You just prove it correct.

geetee
Feb 2, 2004

>;[

Strong Sauce posted:

Download Cracking the coding interview free pdf. (Note there are some errors in the book)
Buy a whiteboard.
Grind it out.

Thanks, bought a copy on Amazon. I don't like wasting time on this, but it seems like a necessary evil. Hopefully I will really learn some new things along the way.

I have a buddy in a similar situation, so we're going to grab a pizza once in a while and mock white board interview.

Jaded Burnout
Jul 10, 2004


By "this whiteboarding thing" I'm referring to the idea of having the bulk of your hiring decision based on a set of coding problems which can be answered on a whiteboard, and even more worryingly, having them be questions people can or need to study for. I'm not sure what the point is of hiring people on the basis of an exercise which can be passed by reading a PDF and fails people with solid experience.

The conversations I've been in on both sides of the table have centered around architectural decisions, specific areas of expertise, establishing the candidate's level of pragmatism, professionalism, that sort of thing. If you've not got enough interview experience to tell whether you're being bullshitted on the code, bring them in for a pairing session and fix a real bug in your real system for half a day.

"Buy a whiteboard and grind it out" seems like a symptom of a problem, not a solution.

Blinkz0rz
May 27, 2001

MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Arachnamus posted:

By "this whiteboarding thing" I'm referring to the idea of having the bulk of your hiring decision based on a set of coding problems which can be answered on a whiteboard, and even more worryingly, having them be questions people can or need to study for. I'm not sure what the point is of hiring people on the basis of an exercise which can be passed by reading a PDF and fails people with solid experience.

The conversations I've been in on both sides of the table have centered around architectural decisions, specific areas of expertise, establishing the candidate's level of pragmatism, professionalism, that sort of thing. If you've not got enough interview experience to tell whether you're being bullshitted on the code, bring them in for a pairing session and fix a real bug in your real system for half a day.

"Buy a whiteboard and grind it out" seems like a symptom of a problem, not a solution.

I think you're right in principle, but coming from the hiring side it's tough to justify a first round of 3+ interview hours, a second round of another 3+ interview hours and 6 hours of pairing. That's 12 hours of lost productivity at a minimum, not to mention 12+ hours of billable labor that the company eats.

I know that there's a huge cost benefit in making sure that you hire the right candidate, but I've never had management look favorably on that kind of lost productivity.

So the difficulty, then, is to find a way to balance the amount of time that goes into interviewing with the perceived loss of time and money. Sadly the answer is whiteboarding or pre-interview testing.

Paolomania
Apr 26, 2006

Thanks all, the resume work has paid off: I've got a tech screen lined up with big G in four weeks. I am fleshing out my study outline and signed up for one of their coaching sessions as well. Wish me luck.

revmoo
May 25, 2006

#basta

Blinkz0rz posted:

I think you're right in principle, but coming from the hiring side it's tough to justify a first round of 3+ interview hours, a second round of another 3+ interview hours and 6 hours of pairing. That's 12 hours of lost productivity at a minimum, not to mention 12+ hours of billable labor that the company eats.

I'd get up and walk out well before spending 12 hours in an interview.

I realize that may be the norm in Silicon Valley but it wouldn't fly here. Reminds me of the time a company wanted to hire me to build a NodeJS app that did a certain thing and then gave me interview "homework" that was basically "build this thing." I politely declined.

I'm all for doing a small paid contract to demonstrate my skills but gently caress devoting 1+ days to doing 'free' work.

Blinkz0rz
May 27, 2001

MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS
Yeah, that's kind of what I'm getting at. The process for interviewing at Silicon Valley companies is so loving onerous that it's untenable for normal companies to follow the same process.

Anyway, I think whiteboarding has a pretty important place in the interview process, but I think people miss the point. Whiteboarding should be more about watching how the candidate solves problems than about making sure s/he can write code.

I'd never ding a candidate on syntax errors and any company that does sounds like it would be terrible. I've interviewed candidates that have solved problems in pseudocode and because they reasoned through the problem carefully and I saw the code they wrote for the pre-test.

biochemist
Jun 2, 2005

Who says we don't have backbone?

Blinkz0rz posted:

Yeah, that's kind of what I'm getting at. The process for interviewing at Silicon Valley companies is so loving onerous that it's untenable for normal companies to follow the same process.

Anyway, I think whiteboarding has a pretty important place in the interview process, but I think people miss the point. Whiteboarding should be more about watching how the candidate solves problems than about making sure s/he can write code.

I'd never ding a candidate on syntax errors and any company that does sounds like it would be terrible. I've interviewed candidates that have solved problems in pseudocode and because they reasoned through the problem carefully and I saw the code they wrote for the pre-test.

At my last job when we are about to tackle a problem we usually go into a side room and jot stuff down on the whiteboard to help everyone visualize stuff together.

When I'm interviewing/being interviewed I always act like we're already on the same team and we're just going to knock out a problem real quick. It's very conversational and I try to keep it as laid back as I would on a regular day in the office.

If I don't remember the exact syntax for a function I fudge it and tell them what I was going for and if the person isn't a huge rear end in a top hat they'll flat out tell you or admit they don't know either and you both pretend it does what you wanted it to do. If you're going to pass on me because I admit that I would reference a doc real quick then we're not a good match anyway.

revmoo
May 25, 2006

#basta
I've sat in on a number of interviews and I find the conversational style works best. I can always suss out a persons's skills just from talking with them a few minutes. I remember costing a guy a job once because he was getting grilled and handling it really well, but then he mentioned that he was a Git expert and taught 'classes' to his team so I asked him what 'git stash' did and he had no clue. Obviously it's kind of an obscure feature, but if you call yourself an expert you really need to know what that command does.

Overall I think it matters more that the interviewers are competent at interviewing rather than the style.

Also I get why Silicon Valley interviews are so thorough, a entry-level development job out there pays roughly what a C-level exec job pays here, so it makes sense if you're paying someone that much money that you spend a lot of time getting to know them and their skillset.

Hiowf
Jun 28, 2013

We don't do .DOC in my cave.

revmoo posted:

Also I get why Silicon Valley interviews are so thorough, a entry-level development job out there pays roughly what a C-level exec job pays here

These kind of comparisons really ought to take cost of living in account. Rent in the Bay Area is totally nuts.

return0
Apr 11, 2007

revmoo posted:

I'd get up and walk out well before spending 12 hours in an interview.

I realize that may be the norm in Silicon Valley but it wouldn't fly here. Reminds me of the time a company wanted to hire me to build a NodeJS app that did a certain thing and then gave me interview "homework" that was basically "build this thing." I politely declined.

I'm all for doing a small paid contract to demonstrate my skills but gently caress devoting 1+ days to doing 'free' work.

Does this apply to all code problems/tests as part of an interview process? We tend to do a technical skype round to see if the candidate has decent CS fundamentals and we wouldn't be wasting each others time, then we usually do a pretty abstract 'homework' problem. It should really only take an hour or two, and can be done in any language, and obviously isn't some practical work we are trying to scam for free, then if good we do a face to face. Some people on the team worry that the homework problem puts more senior people off, while others swear by it.

Hughlander
May 11, 2005

return0 posted:

Does this apply to all code problems/tests as part of an interview process? We tend to do a technical skype round to see if the candidate has decent CS fundamentals and we wouldn't be wasting each others time, then we usually do a pretty abstract 'homework' problem. It should really only take an hour or two, and can be done in any language, and obviously isn't some practical work we are trying to scam for free, then if good we do a face to face. Some people on the team worry that the homework problem puts more senior people off, while others swear by it.

For me I'd only do it if I wanted to work there. If you are a no named place in an uninteresting field I'd rather spend the time applying to other places. If your name is google or Facebook however I'd do it.

revmoo
May 25, 2006

#basta
I've done "homework" in the past, gotten the job, and regretted it. Had I taken the "homework" as a red flag I would have been better off.

With that said, I certainly see no issue with giving candidates problems to solve and even a little bit of light take-home work is acceptable. I think employers do need to exercise discretion with it though. The job market is stacked way against employers right now and they really don't want to be scaring qualified candidates off. Personally I think it's best to keep interviews under four hours total (including phone screens) and have any logic challenges take place at the interview rather than "homework."

You should really be able to make an informed hiring decision for any job that pays less than six figures in under four hours.

Hiowf
Jun 28, 2013

We don't do .DOC in my cave.

revmoo posted:

I've done "homework" in the past, gotten the job, and regretted it. Had I taken the "homework" as a red flag I would have been better off.

The way you state this means that it should generally be interpreted as a red flag. Why is this so?

From the rest of your post, I infer it's because you think companies that ask for homework cause the best developers to skip them and are hence left with mediocrity or below?

I haven't been in the situation so I don't really know what I'd think about it, but one thing I do know: the faster your company moves in the interview process, the more likely you are to end up hiring.

Cicero
Dec 17, 2003

Jumpjet, melta, jumpjet. Repeat for ten minutes or until victory is assured.

revmoo posted:

You should really be able to make an informed hiring decision for any job that pays less than six figures in under four hours.
Median software engineering salaries are now six figures though (albeit just barely).

hirvox
Sep 8, 2009

Skuto posted:

Homework in recruiting
If the "homework" in question was real work from their backlog, it might imply that the company expects that the people who do get hired do other unpaid work as well.

revmoo
May 25, 2006

#basta

hirvox posted:

If the "homework" in question was real work from their backlog, it might imply that the company expects that the people who do get hired do other unpaid work as well.

Yeah it would. I don't think this is a common thing however. I think companies just want to assess a candidate's skills and some of them simply aren't good at doing that. So they give out a "homework" exercise to evaluate the candidate. Now there are several problems with this approach. The first of which it alienates a portion of your potential hiring pool. It's hard to pin down a percentage but it's safe to say that it will turn away a certain amount of qualified candidates. This problem is compounded by the fact that talented individuals may be turned away by this but desperate jobseekers will not. Furthermore, it shows that a company does not value a candidate's time and does not consider them a professional. This is kind of quixotic because these are the qualities that a hiring manager should be looking for.

Again, there's nothing wrong with grilling a candidate, nothing wrong with sitting them at a whiteboard or laptop, or pair programming. It's just that when the interview process bleeds into what could reasonably be considered "billable hours," it causes more harm that good. I think that if a company really wants to give out "homework" then they need to also pay the candidate for their work.

Jaded Burnout
Jul 10, 2004


revmoo posted:

Yeah it would. I don't think this is a common thing however. I think companies just want to assess a candidate's skills and some of them simply aren't good at doing that. So they give out a "homework" exercise to evaluate the candidate. Now there are several problems with this approach. The first of which it alienates a portion of your potential hiring pool. It's hard to pin down a percentage but it's safe to say that it will turn away a certain amount of qualified candidates. This problem is compounded by the fact that talented individuals may be turned away by this but desperate jobseekers will not. Furthermore, it shows that a company does not value a candidate's time and does not consider them a professional. This is kind of quixotic because these are the qualities that a hiring manager should be looking for.

Again, there's nothing wrong with grilling a candidate, nothing wrong with sitting them at a whiteboard or laptop, or pair programming. It's just that when the interview process bleeds into what could reasonably be considered "billable hours," it causes more harm that good. I think that if a company really wants to give out "homework" then they need to also pay the candidate for their work.

I've worked in a place where the first stage screening after CV sift was "build this toy app but don't spend longer than an hour or two". It worked quite well in terms of getting a rough handle on someone's style and approach to a problem hopefully without eating too much of someone's time. We did get a reputation for being very difficult to get hired at.

Equally I've worked somewhere where they insisted I spend a week working with them before hiring. They paid me for my time and I didn't mind at the time, but if I'd had several offers on the table I'm not sure I'd have been so willing.

Hughlander
May 11, 2005

Arachnamus posted:

I've worked in a place where the first stage screening after CV sift was "build this toy app but don't spend longer than an hour or two". It worked quite well in terms of getting a rough handle on someone's style and approach to a problem hopefully without eating too much of someone's time. We did get a reputation for being very difficult to get hired at.

Equally I've worked somewhere where they insisted I spend a week working with them before hiring. They paid me for my time and I didn't mind at the time, but if I'd had several offers on the table I'm not sure I'd have been so willing.

That last is interesting because it could be rephrased as: We only hire unemployed people with no other options.

Ie: You can't interview during that week, you're not going to take a week vacation from a current job just to "contract" elsewhere etc... I wonder did they offer relocations? If so was hotel included for that week?

JawnV6
Jul 4, 2004

So hot ...

Hughlander posted:

That last is interesting because it could be rephrased as: We only hire unemployed people with no other options.

Ie: You can't interview during that week, you're not going to take a week vacation from a current job just to "contract" elsewhere etc... I wonder did they offer relocations? If so was hotel included for that week?

Uhhh Ever heard of a contractor?

You're picking a coworker. Someone who's going to be around you 8+ hours a day for a while, hopefully. If you can pick someone in <4 hours that's grand, but there's a lot of value in making the right choice.

Hiowf
Jun 28, 2013

We don't do .DOC in my cave.

JawnV6 posted:

Uhhh Ever heard of a contractor?

Yes. Not sure what that has to do with anything. You're still looking for someone that can make himself available for a week. Which isn't going to get you any people that are already regularly employed, and contractors may not be too interested in regular employment, so you're not hiring them in any regular meaning of that word either.

So you're looking at unemployed people or contractors that want to stop contracting, or something.

kitten smoothie
Dec 29, 2001

You've got to have a pretty amazing job on deck if you expect me to burn a week of my vacation time to come into work a week for someone else.

For roles on my team (mobile development), we do a small "build a toy app that does X" problem that we send out after the initial phone screen with HR. We do not explicitly timebox it in any way other than that we ask that it gets sent back within 24 hours. The recruiter works with the candidate to set a convenient time to send over the problem and start the clock. They'll usually give you more time if you ask.

The problem really is pretty simple and if you're even minimally qualified to the job then you're probably finishing this in a couple hours tops. The requisition calls for senior engineers with 2 years' iOS experience. Without sharing too much, the test basically just makes sure you can crack open Xcode and write something that's maybe a little bit beyond hello world.

We get a lot of submissions that do not perform the task as specified, crash instead, or just outright don't compile. So in that regard it acts as a high-pass filter to keep everyone from wasting their time interviewing unqualified folks in-person.

The people we've recently hired have also been really sharp people who have been great to work with. I do wonder if more good people were turned off by the "there will be a test" aspect of things and maybe we'd have been able to fill those positions quicker.

I went through this when I hired on last year and I didn't have a problem with it. My personal viewpoint was that I had nothing to lose by having them send me the test and looking it over. If it was reasonable, then awesome, I'll do it and send it back. If it turned out to be something ludicrous then I can just politely thank them for their time and walk away. Neither of us owes each other anything, and that holds true until offers are extended and signed.

MononcQc
May 29, 2007

My current job inerview required me to be on site for 3 days. They paid all my expenses (pre-paid credit cards), booked the hotels and airplane tickets for me, and added ~2 days of free time to visit around and make it a part vacation.

It's really a huge pain to find the time and reasons to be able to run away for a few days like that and go work for someone else. I ended up getting and taking the job, but I can totally understand why that would be annoying, and I don't think I'd do it again. I don't feel like endangering my current job for a very complex interview.

It's sometimes pretty great though, in that it lets you find flaws in how people work you wouldn't get otherwise. You can be testing remote employees who, you find out, don't know how to communicate the work they've done for a single day nor document it, for example These kinds of things can be deal breakers but won't easily show up in an interview. They can also often highlight deficiencies or strong areas of a candidate and let you figure out what kind of on-boarding they'll need when they actually start working for you, and so on.

As the interviewee, it also lets you figure out what kind of place the office is, who you're gonna work with, and quickly get to see how the sausage is made and what kind of code you'll be working on.

I'm a bit torn on the issue because it's really annoying for the candidates, you cut yourself off from a lot of potentially great people, it's really freaking weird to have people come work on your projects from 1-3 days under whatever condition, but it's very efficient filter and lets you test the interaction between the candidate and the rest of the team better than many other interview processes.

Jaded Burnout
Jul 10, 2004


I was quite junior at the time and they were a very small company, so I understood the reticence. I imagine someone with enough experience for it to be an annoyance wouldn't need that length of time anyway.

I've seen half day pairing sessions work very well from both sides. You get a good feel for a person and a team in that time without burning days and days.

baquerd
Jul 2, 2007

by FactsAreUseless

Hughlander posted:

That last is interesting because it could be rephrased as: We only hire unemployed people with no other options.

Ie: You can't interview during that week, you're not going to take a week vacation from a current job just to "contract" elsewhere etc... I wonder did they offer relocations? If so was hotel included for that week?

If the pay was actually above market rate for that week, it would be an interesting diversion perhaps even worth a vacation week even if it didn't turn out to be a new job. Somehow I don't think that was the case though.

Plorkyeran
Mar 22, 2007

To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed
If you end up getting the job, you could just take a week vacation between jobs to make up for the missed week. Doesn't work out too well if you don't, though.

Adbot
ADBOT LOVES YOU

JawnV6
Jul 4, 2004

So hot ...

Skuto posted:

Yes. Not sure what that has to do with anything. You're still looking for someone that can make himself available for a week. Which isn't going to get you any people that are already regularly employed, and contractors may not be too interested in regular employment, so you're not hiring them in any regular meaning of that word either.

So you're looking at unemployed people or contractors that want to stop contracting, or something.

I agree, it's pretty ridiculous to call it "unemployed people only" when there's this other obvious contingent of folks who make a really good fit. Contracting and contract to hire is much more common for ME's, EE's (layout is $80/hr, can even source it on craigslist), and EE technicians. Sorry if I denigrated super special snowflake CS folks by suggesting this as another totally reasonable option in common use in other fields though.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply