See also the Joel Test point 11.

Well apart the one hour panel and specific defense stuff (which might have its importance), the rest is a duplicate of workplace.stackexchange.com/questions/88847/…. So you might want to check answers there

Did you ask questions about the company standards during the interview process?

@Walfrat, read that post before posting and it gave some great answers. Thanks for sharing!

@lucasgcb I've asked how their build/release procedure and it seemed pretty standard. Have an bug issue tracker with regularly code reviews. This sounds great, but I've seen it go bad when they aren't implemented properly. At the end of the day, it's crucial that the developers understand why such procedures exists and why it needs to be utilized.

Possibly this company uses the probation time of the contract to weed out bad fits.

did you ask enough questions ? you are also interviewing them, unless you are completely desperate or unemployed

Maybe it's a cultural thing, but this describes practically every dev interview I've had going back to the early 00's (I'm in the UK). Interview of 60 - 90 minutes, sometimes preceded by a 30 minute phone call. I've had one interview ever where they wanted to do some coding (they pulled the tech test I submitted and had me modify some stuff), but even that was otherwise the same length/format.

"Offer next day" As a contractor? Above/below rates for your position (Straight out of college? no experience?)? Hourly employee? Salaried employee with benefits? My current company hired me with a single short interview... and "hired" me as a contractor. They then had the freedom to end or extend the contract... or eventually hire me as a salaried employee.

You say "there wasn't really any whiteboard coding problems or problem solving questions". Was there a little, though? Are you concerned because they did not really ask anything technical, or are you concerned because the time span wasn't long enough / it wasn't difficult enough?

Anecdotally, this usually means they already know everything they want to about your skills, and are just testing whether or not you are a fit for their team. There is, IMO nothing to worry about here. The only questions are: are you interested in working for them, and is their offer a good one?

I feel like many companies these days are focusing more on whether a candidate fits into the culture they want the workplace to have than they are on the technical proficiency. It's not necessarily how much you know that matters as it is how willing you are to learn and create a positive working environment for those around you.

@Brandin: I have to disagree with that point #11, and the whole idea of whiteboard coding tests. You can't really test anything significant, and there are a subset of people - I'm one - who simply can't work like that. (I've gotten job offers with no interview at all, or just a "do we like this guy?" one, on the basis of published work or personal recommendations, but failed miserably at the one interview I had with a whiteboard coding test.) Using a whiteboard test seems to automatically eliminate a subset of applicants who might otherwise be good at the job.

To give an example of how an interview can go: I once had an interview with a panel of project leaders. When I entered the room, the started with "we want you" and then each pitched their own project. I just had to choose which project to join.

you might no know this but this was the norm and still is for many companies

Possibly related: workplace.stackexchange.com/questions/137961/…

I've been at my current position for 4 years. I had about a 45-minute phone interview that wrapped up with "we'll get you an official offer tomorrow". I was 6-months contract to hire. It's neither a tech nor a defense company, but it's worked well for me.

I have been on both sides of this equation, and I believe that you can tell more about a person in an hour interview than you can by grilling them with a bunch of white boarding type of questions. You can tell a lot by their confidence level when asking technical questions and you can tell a lot about their personality if you keep the interview relatively informal. Over stressing somebody during an interview at least to me seems to be bad for both parties.

@Affe, that's what happens when a company uses techniques that put burden on the interviewer but not on the company. By contrast, when late-stage interviewees go through a coding test that requires substantial company resources, that shared burden and joint investment makes the expense a lot more reasonable from the interviewee's side.

@Affe, ...(When I joined Indeed, they had an all-day interview process; one of the late stages was a coding test wherein they'd put in the engineering-hours to build a problem requiring skills representative of the narrow, specific position I was hired for; evaluation was via a round-table of the teams' dev leads asking why I'd made the implementation decisions I did, and providing an opportunity to defend the design).

(ugh, should have been "burden on the interviewee"; %@$ edit window).

'Desperate enough' can also mean the job is so awesome that people are desperate enough to get it that they'll participate. Not necessarily desperate in the sense of out of work and running out of money, struggling to fine work, etc. It's up to the company to decide if their jobs seem that awesome to the right audience...! ;)

Same thing happend to me. I have TS//SCI clearance, applied, immediate interview. They just asked if I was a complete moron and I said no. Immediate job offer, I make bold salary offer, they accept immediately. I was told by someone on the inside all this is just because they're desperate for software devs. It's just the market rn.

@jamesqf I really wish they had, based on the quality and practical experience of some contractors I have encountered. Another good test would be to sit a person down at a setup terminal and ask them to do several basic straight forwards common tasks and see if they do it or stuff it up completely showing their ineptitude. The Joel Test is a good standard, but is only a reference or starting point.

"there wasn't really any whiteboard coding problems" - You should be worried if there were. Such tests are worse than useless; they bias the selection process toward the extremely inexperienced. Get hired at a place that gives coding tests, and you will be pulling the dead weight of a bunch of incompetents (if you aren't one yourself.)

“Joel Test” #5: fix bugs before writing new code … and then he claims Microsoft scores ALL the points? That’s obviously not the case!