We've been interviewing a ton this year. I interviewed a guy from Hack Reactor this week. He was super inexperienced, but resume was extremely inflated. Seems like Hack Reactor does group projects so they end up doing 3-4 projects in 12 weeks so the resume looks inflated. Guy could not explain much about the projects, even the parts he claimed to do. Is this standard for bootcamps? We're finding it really tough to find even junior level engineers.

sounds like he learned from a teacher similar to what i'm stuck with at the moment.

Throws you a lot of useful code that you basically just copy to solve the puzzle/project for the day. No learning involved, no learning what stuff does or why. Very frustrating.

It's standard in general.

I usually ask a "Tell me about an interesting project you worked on" question when interviewing and often when drilling into the details it becomes clear the person didn't do half of what they claim.

It's especially true of academic projects since I think its easier to do absolutely nothing for a school project than for a work project.

I'm not sure which feels better:

Closing a huge new client

Terminating a horribly sucky client

slashdot

I doubt I could answer that on the spot. If the interviewee was semi-helpful I could probably reason through it with them though.

Not sure why I need to know it. I understand the importance of encryption so when I need to encrypt something I just look up the right way to do it for my use case.

"Is my job 'sending encrypted files to co-workers'? Cuz if not, it doesn't really affect me."

^ totally disagree with that line of reasoning but having a hard time articulating why.

I don't know what the value of the question is unless the position is working for a company building encryption products. It's not a hard question; Alice uses Bob's public key to encrypt a document, Bob uses his private key to decrypt the document. But anymore it sounds like a question like "suppose you wanted to track changes to a source file how would you go about it?"

GPGTools makes pgp encryption on my mac pretty slick.
Sort of sad that I've never been able to use it other then buying drugs online

No one wants to work with people like this.

An employee, ideally, should be:
-- Willing to help make the company, product, and / or his job better.
-- Willing to grow as a person and learn new things.
-- Willing to help out his fellow coworker. (caveat: withing reason)

That attitude says he is unwilling on all counts and I'd suspect he'd be very difficult to work with (hoping he was just joking).

I get if someone declines to do something because they really don't know what they are doing or they have too much on their plate, but to refuse because it isn't their job, "full stop," is just a jerk.

This was my company's experience with Hack Reactor as well. We actually went to their most recent hiring day.

Before which they send out a really nice packet with project descriptions, pictures, a breakdown of each person's role on the project, and in the back is a copy of everyone's resume. Many of the projects sound great, responsibilities are well broken down, and are ambitious. If you saw the resumes not knowing those were class projects it would seem that they had professional experience.

At hiring day it was a **** show. They couldn't describe coherently what they worked on. It was clear there was a lot of hand holding on those projects.

Full disclosure: I'm an App Academy grad and had largely been self taught before that with a couple of edx and coursera classes thrown in. My company is hiring so I've had the chance to do a good bit of interviewing, and candidates of all experience levels seem weak.

We had one guy with 12 years experience claiming to be a full stack developer who when given three css rules, one on the tag one on the class and one on the id couldn't say which had precedence. He also didn't know the syntax for declaring a function in JavaScript.

Re boot camps, they seem to vary quite a bit in quality and the ones that are sold put out grads with a wide range of skill level. One if my co-workers went to dev boot camp to learn web dev after her CS degree and a few years at Cisco. She's awesome. We interviewed a recent dev boot camp grad who actually had been teaching at dev boot camp part time and out of camp 6 months. He was terrible.

In my class at app academy there were some people that I did not think would make successful junior engineers, the middle people seemed like they would make OK junior engineers if they were put on a team that did active mentoring, and the top of the class was made up of people that were probably closer to intermediate than junior in many respects.

I have no idea about the css precedence.

Geez, if I've learned anything ITT lately it's that I'm bad at my job.

I understand your frustration and I probably would be frustrated too. On your own think about alternative solutions to the puzzles. It may be a way to deal with the situation and at the same time provide more insight.

You can pretty much derive it from principles. The whole idea of CSS is to set general rules for big groups of elements and then augment them for specific subsets. Precendence therefore goes hand in hand with specificity. ID has a higher precedence than any other selector because it's specific to a single element. Classes are more specific than tags because the whole point of a class is to define a specific subset of elements to style.

As someone who is ignorant of CSS and JavaScript. My conclusion from your post is that knowing CSS precedence rules cold and being competent in implementing requirements in JavaScript are absolutely essential for being successful in the role you were interviewing for. Is that right?

CSS sucks!!!


**ducks out the back door**



(I suck at CSS)

CSS precedence memorization is not a requirement though some experience is preferred. I would expect a full stack web developer with that much experience to know that much or at the very least be humble enough to admit he didn't know so we could help him think it through. He didn't admit that he didn't know, he hemmed and hawed and then guessed the body tag. That answer implies not knowing css or html.

And yeah JavaScript basics are a requirement

How is it possible that a full stack dev with 12 years experience can't write a function in Javascript?

blackize/muttiah. What is your location? I've read a number of negative reviews about the students coming out of the NY branch.

CSS does for real suck hard though. I'm undecided on how much of it was incompetence and how much was the fact that web pages very quickly started doing things nobody foresaw. Like, it pretty quickly went from "oh this is like a document thing where we need to format this like it's a newspaper or magazine", at which CSS does an adequate job, to "Oh now we need it to specify the layout of user interfaces for complex applications" at which CSS is terrible.

CSS precedence rules - in particular knowing that ID selectors have precendence over everything else - is sort of like knowing that C-style languages have zero-based arrays. On the one hand, if you need to know that you can look it up, so it's not something essential to know. On the other hand, if you don't know that, it's pretty good evidence you've barely worked in C-style languages at all.

I don't know to answer your question. If it is isn't required how much does it matter? I don't know what the candidate claimed. One could claim to have experience in full stack development over a twelve year period. The claim can be interpreted in a lot of ways no? The candidate may have had some experience with say JavaScript/CSS 10 years ago and hasn't done much with it since because they didn't have to. The interviewer may interpret it to mean that they have complete knowledge of full stack development since they have 12 years of experience. Not sure.

Should we get into problems with what companies post in job requirements when they are looking for developers?

???

Not knowing how to declare a function in Javascript equals literally never having written any Javascript.

I've done full stack development for a relatively long time.

I guess if I thought about it, it's true that you kind of intuitively know them but I'm sure I'd come off looking pretty bad trying to answer that question.