Sometimes it just happens. I literally have flashbacks to an interview I did a few years ago, where just like you, I knew a solution 10 seconds after I left and I've never forgotten it.

These kinds of interviews are bad. I don't know the solution, though.

I used to work at someplace that was very very hard on interviewees, one of the most strict places I'd ever seen, any whiff of a bad mark from an interviewer and you were out. If your pre-interview code sample wasn't perfect you didn't even get an in interview. They were vicious.

I had some people that I'd worked with interview there. People that I'd known and worked with a long time, and that I wanted to work with again. They failed the interview process. I knew that was bull****. That company's motto was essentially better safe than sorry, I guess.

I've also worked at places that were too permissive and hired smooth talkers, and that didn't turn out well either. I don't actually know the answer but these Google-style interviews isn't it, I think.

A friend of mine works at google and really pressures me to apply there. I don't think I want to work there. Like, I want to work at 2000-era google, maybe, but not today-google. Although, their offices are very impressive.

I posted this before but I really liked this approach: https://www.karllhughes.com/posts/rethinking-hiring

One thing is for sure - most tech companies have a massive leak in leaving good devs on the table because they aren't whiteboard wizards.

@suzzer - gl, thanks for posting about, and keep a positive attitude about your search.

FWIW to me it is obvious companies want to hire highly productive developers. Whether or not the companies hiring practices are effective towards that end is open to debate,

Survey on Developer Productivity

Quote:

My, what big drains you have
The biggest drains on productivity are not technical. We can’t even fault the colossal time suck of Reddit, Hacker News, or Twitter.

Turns out, the biggest drains on productivity are waiting on other people and low-engagement meetings.

This confirms a pretty general belief among software developers: the core problem in software engineering productivity is that highly empowered engineers experience a pattern of being stymied by other, non-technical coworkers.
.....
It turns out, the vast majority of developers believe there are good metrics to measure software engineering productivity, and they want to know how they are doing.
This supports the growing consensus among engineering leaders that using metrics in software development is essential part of effectively leading teams, for example using metrics to track engagement.

I wouldn't restrict being stymied to just non-technical workers. Decent metrics are an obviously good way to assess productivity. Wonder if suzzer will be asked or has been asked what makes him a productive developer.

We're approaching a major deadline for the project I'm working on. The guy managing it, I guess, is concerned we'll miss the deadline.

Solution? ****, I think you already know what I'm going to say.

Daily meetings. Of course. At 7am.

Another manager, who's working on another facet of the project is already picking my brain, trying to settle on features for the next version, which will launch in september.

Metrics can help give managers visibility, but you can't ever make too big of a deal about them or devs will start gaming them and wasting time worrying about metrics instead of building the product.

Checkin graphs is always good. A dev who works at home Fridays and never checks in anything between Thursday and Monday is a red flag. But again - never let the devs know you're using this.

By FAR the best way to know about a developer's productivity is to just ask their peers, or even better listen to them. If one dev keeps coming up as a resource that's your keeper. IE - "give it to Sean if you really want it done right", or "Can we get Sean on this project?".

It's not a secret who the most productive devs are - everyone at ground level knows - including PMs and testers. If managers don't know I'd question how connected they are to the teams they manage. Yes some popularity could creep into this, but it's still far and away better than anything else imo.

Also, everyone knows, even if they won't admit it, who the really toxic ones are. The people they won't consult unless they literally are forced to. It's hard to get people to give that information up.

It's been a long time since I worked with a toxic dev. I feel pretty lucky. Useless dev, but not toxic.

Funny thing was everyone tried to push the useless dev off on other team's projects. So the manager completely knew - he was just too lazy to start the year-long process of getting rid of him.

I figured out this one pretty quickly, people were very willing to spill the beans

So this is something that was explained to me but that I haven't experienced personally yet... a lot of our developers live in Spain (our company was initially founded in Spain). Someone told me that spanish devs will not **** on another spanish dev. The way you figure it out is they say "so and so should really work on this project" (i.e. a project the speaker is not working on)

To other devs, sometimes. To management, not so much in my experience.

It is curious to me, but, part of the ****ed up hiring is because we find it very hard in the US to fire developers. So we want to fix this by not hiring people who we might want to fire.

As cutthroat as it is, I once ended up with a pretty good team by hiring N devs and firing 2/3 of them.

I really feel like more companies should offer 3 to 6 month contract to hire, for those exact reasons. I would jump on it – because I’m pretty confident they want to hire me. But also maybe I don’t want to stay

Well the company I hit it off with wants to bring me in tomorrow for a big round of interviews and sounds like they might make me an offer if it goes well. 1 hour of cultural, 1 hour of mock project planning and 1 hour of technical. ****.

I figure I can cram on promises and async/await tonight since those seem to keep coming up, and I'm not as familiar with them as good ol callbacks, async.js or just express middleware. Anyone have a favorite hands on tutorial site for that stuff?

Oh yeah - I better get map, reduce, filter down cold too. I always get super rusty on those if I don't use them for a while.

I like that funfunfunction guy Larry linked a page back

Yeah he's great.

if you write some tests, then it will be ttd.

Torture Tested Development?

lol

ya we had a meeting yesterday for a very strange bug that I have been working on. My manager called the meeting and invited some of the most experienced and smartest people on the project including one of the wizard consultants that we use sometimes. I thought, and I would imagine the rest of the devs thought as well, that we were gonna discuss the bug, my findings, and ideas on how to proceed.

nope. she called the meeting to discuss which team should take the bug, which manager should "manage" it and which board the bug should be on.

the only technical part of the meeting was the question on if 2 other bug cards were duplicates. they were, and I could have told her that after 5 minutes of research.

anyway, so she pretty much bickered with the other manager on who should own the bug and "manage it" (her words) for about 15 minutes. I was kind of embarrassed and very disappointed that I didnt get to engage much with the other devs. I think the other devs were just like wtf.

Yep that's exactly how I output to see if it's correct esp when working with data manipulation.

For some reason a lot of ppl seem intimidated by tdd.

Recently a dev asked me to help her with some data combining I guess you could call it. 2 lists of objects with ids to match up and then put the matching object in the first list. A few other twists but that was essentially it.

When I suggested writing a test to start she looked at me like I had 2 heads. But like, isn't that the easiest way to know if it's correct?

I personally know a dozen shops that either want or claim to use TDD. I know zero that actually do full-blown TDD.

Also bummer on the manager thing. Maybe talk to her after the meeting or try to pull the other devs aside?

New version of the problem using es6 includes - still the potential n^2 problem, but at least none of the ugly string chopping. I wish while() had an implicit index, then I could boil this down to 3 lines of code.

I don't think this can be topped.

we're trying right now, it's not going well.

How would you even enforce tdl3l

It's not a potential - it *is* O(n^2). Searching a list or an array for a value is O(n), and you have to do it n times.

ETA: you also have a bug - you need to exit as soon as you find the first match

all the bosses took the day off and the 2 main toxic people were gone so it was like straight up workaholics at the office today, started drinking at 1 and everyone played video games in the conference room LOL

Amazing what an effect a few crappy people can have on an office morale.