why would you think its bad?


I mean, presumably other pieces of state are changing, otherwise Im not sure if you would need to call the API. like, calling and API to only display a modal doesnt seem optimal.

Seems like overkill to use redux like this. I would rather the button call setState and conditionally render a modal component if true. I try to avoid lifecycle methods used in that way.

Err and even if you do use redux, what is componentwillreceiveprops even doing, calling setState itself? Why? You should conditionally render directly off the props.

Curbside has this pre-application challenge.

https://challenge.curbside.com/

I think that the most interesting questions I have always received were questions with subtle traps built in. This is more common and possibly easier to do with SQL or questions relating specifically to data processing, but in general, these classes of questions revolve more on proving your output is correct under a full set of circumstances. If you aren't used to working with messy data, you will miss many small things.

For interviewing, I'd much rather solve a bug that takes 30 minutes to figure out than take a series of tests. Of course, it is honorable if the employer already solved the bug. I don't like the "what would you do if you saw error 500" or "what would you do if the database is slow" type questions, not because they are bad per se, but the interviewers never want to give more information.

any of ya'll try firefox 57? seems super fast

Not yet, supposed to be a great speed improvement - but rip my extensions!

I think in many cases its tricky because of the really wide variety of languages and tools that people are familiar with and use.

When we ask coding questions we don't specify a language to try to make people as comfortable as possible. You can't really do that with a program with a bug. And even if you're using a language the candidates knows - do you offer the tools they're familiar with? Some people use pdb, some people use pycharm, some people use...

It just quickly gets into a "Do you know this specific tool/language" and not really a "how good at you at finding a problem".

That's not to say there's not a question to be asked, but like almost everything with interviewing its hard.

And you always have to weigh how much of a PITA your willing to make the interview to catch the people who interview well but are not productive. Especially if you aren't a Google or Amazon level company that can always count on people wanting to work there regardless of the process.

What would be the way you render off the props?

My thought is that I know the API call is about to hit redux and then pass props to the component so checking nextProps (and anything else you need to do) in that lifecycle method seems like the way they "want" you to do things?

I'm currently in an attitude of redux-all-the-things. I get why just using local state makes sense a lot of time. But redux seems to make it much easier to consistently debug while building stuff.

How prevalent is the person that interviews well but is non productive? This seems like an urban type myth to me. Maybe tin foil hat type thinking. I am guessing that places that hire "non productive" workers very often have problems in their hiring process. "Non productive" can mean a lot of things to a lot of different companies. How prevalent is the doesn't interview well but would be productive otherwise candidate?

I get that when a person needs to be employed and isn't employed they can and do take jobs that aren't necessarily appealing to them. That doesn't mean they won't be productive though.

You seem to be creating some kind of strawman where there are candidates who have the ability to fool companies by.being really good at engaging people on a personal level (interviewing well) but have little interest in being very productive.

My hiring hot take is that many companies falsely increase the burden on hiring process in the hope it'll weed out these rare sociopath great-interview-no-work applicants, but instead they should just fire them ASAP.

The hiring process for technical hires is already absurdly burdensome at most companies.

I agree people don't fire fast enough in a lot of cases. But there's real damage done to a company when you fire someone (even someone that deserves it) and so I think you do need to be careful of the hire easily / fire easily approach.

Consider a container/component seperation style then. Redux connect and mapstatetoprops will let you conditionally render your modal without needing to check nextprops in the lifecycle method.

Where are you all applying that doesn't have a long interviewing process?

No I'm implying that the "I'd rather see a code problem solved than a process question answered, particularly for something as straightforward as debugging, doesn't make much sense. In 7 years at a start up I saw one guy get hired who turned out to be a dud and he showed up stoned to the office after he was fired and freaked someone out enough that they established a "what to do if you're freaked out policy." Interviewing is hard but shouldn't be made harder because of irrational fears that every interviewer is trying to game the system.

Is using loops and .each slower for algorithms, assuming you are using a Boolean to break the iteration?.. when I see answers submitted on exercism.io very few are using loops...

Due to branching, using breaks is slower than processing the loop in full then evaluating the result.

map, reduce, apply, filter, sum, and so on are loops, and if your language doesn't have lazy evaluation, you are probably creating exponential algorithms when you chain them together.

I have a collegue who dies something similar. He takes a real code sample from his recent work (before refactoring and cleanup) and asks the candidate what it does and asks about potential bugs or problems with the code like thread safety or resource usage. It takes effort to prepare good questions like this and there's rarely enough incentives for Engineers to put so much effort into interviewing. So everyone just falls back to asking coding questions that are pretty damn good at weeding out weak people.

Ok yea we have this.

I guess what I'm confused about is the exact way to pass it.

Do you pass it as props only when it needs to get fired?

I have adopted a strategy that I saw in some interviews that I'd been in. They're not coding questions exactly, they're more like strategy questions. Like you introduce a problem and say "how would you begin to approach this problem" and have them just sketch out sort of a plan - what technologies would they employ (like... web server, database server, maybe a standalone program of some kind), what algorithms might they use, what data structures might be required.

Usually, an obvious weak point will appear, or some part of their "sketch" will not be well thought out or feasible and you can dive a little deeper into that. You keep asking questions and get them to refine their plan. You have to know the problem space really well but I have found it works pretty good.

Also I think it touches on something coding questions really don't. When you have a very well defined problem, it's not too hard to write code to solve it. But when you have a more nebulous problem, and it's up to you to determine from soup to nuts what you'll need to do to get there, a lot of people do not even know where to start.

Basically pass it down as true or false as props and then when it gets down to component, it fires on re-render?

Yeah pass it all the time in the containers mapstatetoprops fn and render it if its true in the component

Rusty, we sort of classify those as design questions and make sure everyone is given at least one of those and one programming question (amongst others). Definitely important.

Hmm yea, I realixe now i do this with other stuff as well. Not sure why I used nextProps this time. I guess I just got confused.

I ask this to. My standard question is design an Instagram like app from requirements to back end and front end. It takes about an hour thing for me to get a complete signal of the candidate.