When a company comes at you with a skills test or a stupid whiteboard interview, while completely disregarding your portfolio/GitHub/other proofs of competence, run far away.

You've just described Amazon. Portfolio doesn't always speak reality. Maybe you did that as a member of a team with a senior on top of you at all times? Or maybe they don't want to read through thousands of lines of code to find a case they'd be interested in?

@AndSoWeCode Who'd want to work for Amazon? I don't. I've had enough of working as a drone for monolithic companies who treat every employee like a "resource" (it's in the name of the department that hires you). I'm focusing on working for good entrepreneurs who don't take people for granted and who have the capacity to appreciate what I can do for them.

@stackodev the problem is that companies like Amazon are successful. You would be part of a successful enterprise. As for good "entrepreneurs", the difference between no entrepreneur, and the best entrepreneur, for the outcome of a business, is smaller than you think. Sure, you get a good attitude, but statistics show that it's more likely to die out, and with it - your entire work.

only 1 in 10 founded companies avoid bankruptcy int he first 2-3 years. And just 1 in 3 companies ever become profitable after the first round of financing by venture capital. When they become profitable, usually, they're big enough to enforce rules on you that you don't like. So, statistically speaking, with your approach, you are very likely to work in vain, just for the experience and money, and none of your products that you ever make will make it past the 3-4 year mark.

@AndSoWeCode All risks I'm happy to be part of if only to not always be treated like just a number. At least I had a better chance to affect the outcome and the lessons I learned can more effectively influence the next entrepreneurial venture I'm part of. In a big company I get to fill out S.M.A.R.T. Goals(tm) about things I have absolutely no influence or control over, just because it's in HR's manual, not because it does or doesn't make sense.

@stackodev yeah, but how effective is that? It's not about risks, but about influence. In stable companies you get to shape the future. At best, 2/3 of all of your work in start-ups fade into oblivion.
In stable companies you get to fight your way to decision making, become a lead, and actually influence the same way you do in startups, except that in startups, it's rarely up to you whether it succeeds.

I would argue that startups offer the illusion of control, and short-term happiness and fulfillment with work. Long term it's a disaster. You look back and have nothing to show for it.

If an applicant comes to me with a portfolio or github profile, I'll try to poll how much of it is original work by asking them how they built it, which challenges they faced. If they don't, I'll pick a challenging task from my own Asana list, ask them to subdivide it in smaller tasks, and discuss how they'd implement parts of it.

I find that just talking about real world projects is often enough to get a sense of experience and skill, and certainly much more useful than "write a function which spits out prime fibonacci numbers"

I didn't work on any bigger "demonstrable" project at home for a long time because my job is too exhausting to build up and maintain something along the work. And I work in teams, no project is entirely made be me. That's why I don't have a portfolio to demonstrate. In the case if I quit this job, the next boss hopefully DON'T think a large portfolio is important.

@AndSoWeCode I strongly agree with you. Startups do offer flexibility to implement the latest technologies earlier than stable companies and we as programmers find it fun to start a new challenging task of design and using a new framework which can end up into a cool feature(best case).But, many should also realise how technologies are evolving now. All big firms are shifting focus to research and many new technologies are developed in such companies.. if u perform well, you get to design, implement and talk to the best senior devs who have 10+ yrs of experience and saw the fast evolving technologies. not only talks, getting code review from them itself when u r a fresher will be awesome in startup, getting a great guide depends on luck. I did an internship in a startup where I was leading a project with around 4-5 devs using Flask and no one was there to guide me n it was first tym using it. So, when u work in big companies, u will b definitely amazed by internal production designs

And regarding white board practice, that's a great way to take interviews.. y to waste time verifying the resume, when the candidate is in front of u. Let him/her talk in terms of codes, which will not need any post verification.. time is precious n if the candidate answers all questions before time, then it's interesting to look his resume.. to know wat he/she has done that he/she is so good.. n sometimes, resume r misleading.. if the candidate was part of a cool project may be like building satellites or ML project but nvr did anything.. in such cases.. it's waste of effort to verify the resume.. instead just throw the problem and see how he/she approaches it..

@timekeeper here's a more detailed take on why whiteboard interviews are not a good way to assess actual skill relative to an actual job.

https://hired.com/blog/employers/...

@stackodev I read d article u mentioned in the link. It's good to conduct real world scenarios and provide full access to ide and stackoverflow to develop. But again it has flaws.. one big factor is time.. each will take at least a full day time, and how are you gonna evaluate if cases like plagarism comes.. In my clg, few companies followed this pattern of software design first, and then software development n duration was 8 hrs wid full internet access. In such case, it's very easy to google out the solution n present to d interviewers. Whereas whiteboard interviews evaluate ur thinking process. It's not only the solution interviewers r looking for. They also c how he is approaching to a problem, how much requirements he asks the interview to define the scope of problem, how is he identifying edge cases, any OOPS implementation,.. when we start developing any thing, at the end of the day, it's the problem solving skill that solves a problem n that is wat being evaluated...