The biggest lesson I learned from it is never taking for granted to what extremes someone will go to get a job, and always doing due dilligence, no matter how busy you are.

We were hiring for a project manager, we interviewed 4-6 people, one of them was John. On his resume, he had a college listed (but not a degree) and when asked about it gave a wishy-washy response that he didnt graduate but was close. Otherwise he seemed to have good experience and fit the budget, but that wishy-washy response was to his potential manager, so with other candidates he back-burnered him. We ended up hiring Jane, who had a great background but at the end of the day was not a small business employee and had zero in the way of self reliance and was probably a net negative in terms of requiring other people's time (was really nice tho, in a big company with a specialized role she would be average/fine).

Fast forward 6 months and we need to hire an engineer and a project manager. I found a friend from college who was at a recruiting company so I got a good deal and gave him the 2 reqs. They found an engineer who has been there for 2+ years now and is great. They also found a guy who was really keen on working with us and that got through their filtering, John.

John had a new resume, and because we were so busy, the CEO ended up doing the first phone screen. John was PMP certified and had a college degree. The phone screen went great. John was forthcoming about having applied before, and given the hire we made didn't work out, we felt a bit sheepish. When the hiring manager spoke with the CEO prior to his call, he remembered John and remembered passing for the other candidate, and not much else.

We felt like this guy was clearly very passionate about working for us, and had a new sparkling resume the recruiting company had touched up for him. Because of need, we fast-tracked him and his in-person went well, he seemed like a solid cultural fit and someone who would be chill and not be stressed with high-pressure clients.

So we got both candidates paperwork and got them started quickly. We told them we would be doing a background check and gave them the paperwork but given timing let them both start right away.

Then John came in 2 hours late on day 1 because he "spilled coffee" on his pants and had to change. We were so busy we mentally noted it but assumed he was embarrassed or something. A girl who worked with him told me after he'd been there a week that she never sees him drink coffee, this was after he was late a few more times. I was coming in pretty extremely late everyday (and it was allowed for me because I worked late nights and weekends) so I didn't really notice but when mentioned to me after his first week I was surprised someone would do that on week 1.

So we do some Google deep diving on his name and address, and find an arrest for theft from wal-mart from 3 months prior, then we search for his PMP and he isn't listed, then we dive into old emails and find his original resume and the new one shows a degree, and hiring manager remembers the first conversation. Literally the next day he says he is running late the morning of a client on-site, we tell him to go straight there, we don't hear from him again until like 3am that he "got into a car accident" and couldn't make it.

Call the lawyer early and had everyone stay home and made the move to sever all ties and terminate his employment that morning.

Being so busy led us to skip important due diligence that I'll never be skipping again.

Great story. I have two questions: when do we get to Shelbyville and why did you tie an onion on your belt again?



But yeah - red flags are called red flags for a reason. We almost hired a guy who failed his weed test. Even though he had a medical MJ card - the company was like no way. Kinda sucked because his interview was spectacular. He seemed like a very sharp dev with string lead experience. One concern though was the # of jobs on his resume - like rarely more than one year in the same role.

The consulting company who brought him in to interview with us ended up hiring him for an in house project. He turned out to be a total flake who missed all kinds of work and would show up a few days later in tears with some weird excuse.

Basically if someone can't quit smoking weed for a few weeks/months when looking for a job - could be a red flag. That + a lot of jobs, which may be the bigger red flag.

Suzzer I vaguely remember that story from when it happened. I seen to recall you were pretty unhappy with that blanket policy for devs. Nice to get the what would have been experiencing without actually getting burned.

There is so much more that goes into bring a successful employee then the process can select for. Do the best you can and move on fast

I have a billion dollar idea:

Build an app that can take a github repo and play it back to you from the start in an easy on the eyes view player that can be paused, fast forwarded etc so you can see the app being written chronologically. make it so that when paused you can filter between controller/model/view etc

Possibly, but its totally possible the process is relatively good. Hiring is hard.

I read a good blog post recently (but damned if I can find it) about a tech company whose solution to scaling their engineering team was to make sure they never hired (or retained) people that increased the communication burden on the company as a whole.

In general adding people linearly to your team increases the communication/management burden on the team exponentially. This blog post talked about how avoiding that was one of their main goals. They wanted people that could just figure out what needed to be done w/o meetings and a lot of formal communication. People that could do things like look at code and see what it does w/o having to ask someone. People that were thorough and released well tested/monitored features to avoid causing downstream problems. That sort of thing.

I don't buy it completely, but its given me a new metric to think about when evaluating people. There are some talented/smart people out there that just still manage to have a relatively high burden on a team. And if you have just a mediocre person like that, it doesn't take long to realize it and they need to be fired pretty quickly. And this is a really hard quality to judge in an interview process.

Reading all you guys' posts gives me some serious impostor syndrome. Is everybody here a 10xer?

In some contexts, I think so. In others, an imposter. The key to success suggests itself.

lol i dont understand the reference

The way you describe "communication burden" in that context is great, that must be an awesome blog post.

That was the biggest reason we had to move away from Jane. Requiring excessive (every team will have a different definition for excessive, acceptable, ideal) communication is a huge issue for productive teams.

It can also be somewhat hard to identify and in practice you can be left thinking "well, once they are more up to speed it will improve" but sometimes it is just how certain people are and you need to identify it and move them to somewhere that better suits them, perhaps outside your company.

jjshabado, can you link to the post? I often feel that there's too much discussion in our team. I mean it probably is beneficial to some people, but I usually don't get any benefits from discussing some implementation details over and over as it's usually pretty clear to me what needs to be done and how.

Just had a coding test where I failed to implement merge sort properly... rip, live and learn I guess

I tried hard to find the blog post last night while dealing with a screaming kid, but I couldn't find it. Turns out there's a bajillion blog posts on how to hire/scale teams.

Somewhat related, but just saw this repo that lists companies that don't whiteboard during interviews.

https://github.com/poteto/hiring-without-whiteboards

On this line of thinking a team member was having a tough time coming up with a name for a new model for a relatively small feature. I suggested that he solicit feedback on slack. This simple feedback request led to someone asking him to draft a technical document describing why the feature is needed, use cases, structure of the table etc.

****.

Who is that monster?

Never use slack for that!

I think its like 3-4 people max for most naming conversations.

At the risk of staring a religous war..

"Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles."

This is bull****, right? Implementing bubble sort isn't a riddle. And its not even testing if you know some obscure, rarely used, algorithm. It's testing that you can turn a simple algorithm into code. That is, translate an abstract algorithm into the language that a computer understands to correctly execute that algorithm.

If you can't take a simple conceptual algorithm like bubble sort and come up with the code for it - you're going to be bad at your day-to-day job.

Edit: I guess with the caveat that the interviewer would be willing to explain the bubble sort algorithm to someone that didn't know what it was.

Atleast he knows that he's a code monkey. I guess if you need a 40k muppet, great.

Yup, lesson learned. That slack channel is only 10 people and only 3 chimed in but **** if we need that much documentation to speech every little change, we're screwed.

Regarding whiteboarding, I always read about people hating these types of interviews and not being any good at them.

But the engineers I know personally that have expressed this sentiment are two people who have glaring communication issues. One of them had this manifest in code and couldn't really be trusted with much of significance. The other has issues that mean a bit longer time explaining a project before getting started but after that fully autonomous.

So... "David" invented Ruby on Rails?

Hah, didn't realize that. I'm just going with he's lying then.

There is like 0 chance he can't code bubblesort on a whiteboard. And again, the question still has nothing to do with riddles or looking up code on the internet.

Found it! https://blog.expensify.com/2016/07/1...ring-strategy/ Looks like I filled in a couple of the blanks about the really productive people and like I said I don't really buy the overall thesis of the blog post, but I think they do a really good job of talking about productivity/overhead and explaining how absolutely toxic some relatively-average people can be to a growing company.

This blog post is also kind of interesting: https://blog.expensify.com/2016/06/1...eview-process/

Although, again, I'm not really drinking that koolaid.